From julienl@qualcomm.com Mon Oct 4 09:39:53 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B4B3A7036 for ; Mon, 4 Oct 2010 09:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.295 X-Spam-Level: X-Spam-Status: No, score=-106.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-Be6Zdr2tg6 for ; Mon, 4 Oct 2010 09:39:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9BA0E3A703A for ; Mon, 4 Oct 2010 09:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286210369; x=1317746369; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"cjbc@it.uc3m.es"=20,=20"netext@i etf.org"=20|Date:=20Mon,=204=20Oct=20201 0=2009:39:19=20-0700|Subject:=20RE:=20[netext]=20About=20 draft-bernardos-netext-pmipv6-flowmob|Thread-Topic:=20[ne text]=20About=20draft-bernardos-netext-pmipv6-flowmob |Thread-Index:=20ActZ3MIKg/1vXi9+ThaPIC+53GdzAgEpKGiw |Message-ID:=20|References:=20<1285108267. 7749.373.camel@acorde.it.uc3m.es>|In-Reply-To:=20<1285108 267.7749.373.camel@acorde.it.uc3m.es>|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=8EJBXwTTxY2VEl7rsig719KkHUY17TFlkE3IhIi/1QQ=; b=a1B9C9T97U88RFZ0NObf3CV8dZF7bPKAXX/aAfER8/1tGFptu3Evrig5 l+HJDDerb4pc4Bha22hp1iONscjkZrjVMHsm/577pQHZcrCmhcQ7VCYhM 74E/3yuufnFHG+p6hA/Dl+HaFsERz8u5ydUI3gCjIUrZnr1TwC5hkRTZL o=; X-IronPort-AV: E=McAfee;i="5400,1158,6126"; a="56641455" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 04 Oct 2010 09:39:28 -0700 X-IronPort-AV: E=Sophos;i="4.57,278,1283756400"; d="scan'208";a="88756949" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 04 Oct 2010 09:39:28 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Oct 2010 09:39:28 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Mon, 4 Oct 2010 09:39:27 -0700 From: "Laganier, Julien" To: "cjbc@it.uc3m.es" , "netext@ietf.org" Date: Mon, 4 Oct 2010 09:39:19 -0700 Thread-Topic: [netext] About draft-bernardos-netext-pmipv6-flowmob Thread-Index: ActZ3MIKg/1vXi9+ThaPIC+53GdzAgEpKGiw Message-ID: References: <1285108267.7749.373.camel@acorde.it.uc3m.es> In-Reply-To: <1285108267.7749.373.camel@acorde.it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:39:53 -0000 Hi Carlos, Thank you for sharing with the WG the requirements you've been considering = in developing your flow mobility solution. All requirements are non-controv= ersial but this one with which I actually disagree: > - Analyze the different scenarios to be supported. We currently include > the "shared prefix" and "unique prefix" per physical interface models. I disagree that supporting a per-physical interface prefix is a requirement= to support flow mobility, and there also seems to be evidence that support= ing a per-physical interface prefix is actually NOT a requirement for flow = mobility: - Up to version -06 of the PMIPv6 draft it is said that a given mobile node= is allocated a unique set of prefix, that is either stored in the mobile n= ode's policy profile, or dynamically assigned by the local mobility anchor.= =20 - This is changed starting with version -07 with the additional requirement= that "the local mobility anchor MUST allocate a unique home network prefix= for each of the connected interfaces." The departure from the earlier addr= essing model is justified because it is only way to avoid breaking unmodifi= ed hosts which would not support having the same prefix assigned simultaneo= usly on the same interface.=20 - The "unique prefix per interface" requirement is no longer justified for = flow mobility work because all the work we're doing, while stile assuming a= n unmodified IP layer on the mobile nodes, also assumes that a logical inte= rfaces hides the multiple physical interfaces. Thus assigning a single pref= ix set to the mobile node, independently of number of physical interfaces d= oes not risk breaking the IP layer. Additionally, because when flow mobilit= y is in use, packets are required to be routed on a per-flow basis and no l= onger based on a longest prefix match between routing table entries and pac= ket destination IP address, flow mobility cannot be used to justify the nee= d for per-interface prefix. =20 --julien Carlos Jes=FAs Bernardos Cano wrote: >=20 > Hi all, >=20 > Julien and Raj suggested that people working on flow mobility solutions > posted a summary of the requirements of goals of their ongoing work. >=20 > Authors of draft-bernardos-netext-pmipv6-flowmob are working on the > next revision for the consideration of the WG. The draft has the > following goals and requirements: >=20 > - The goal is to define PMIPv6 extensions that allow to move flows > among different simultaneously attaches interfaces of an MN. >=20 > - Analyze the different scenarios to be supported. We currently include > the "shared prefix" and "unique prefix" per physical interface models. >=20 > - The solution defines the LMA as the controlling entity. The solution > defines the signaling between MAG and LMA. The specifics on how the > network nodes obtain the policies is out of scope. >=20 > - The MN is equipped with one logical interface (we don't support flow > mobility across different logical interfaces). >=20 > We are currently working out the details and reaching an agreement > among the authors of the draft. As soon as we come up with a > consolidated document (hopefully within the next couple of weeks) we'll > submit it and ask for feedback to the WG. >=20 > Thanks, >=20 > Carlos >=20 > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From Basavaraj.Patil@nokia.com Mon Oct 4 10:30:45 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366523A6CC5 for ; Mon, 4 Oct 2010 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPk5uibPRCRk for ; Mon, 4 Oct 2010 10:30:40 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 491A63A6FD9 for ; Mon, 4 Oct 2010 10:30:40 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o94HVXUN032698 for ; Mon, 4 Oct 2010 20:31:34 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Oct 2010 20:31:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Oct 2010 20:31:23 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 4 Oct 2010 19:31:23 +0200 From: To: Date: Mon, 4 Oct 2010 19:31:22 +0200 Thread-Topic: Agenda slots for IETF79 Thread-Index: Actj6fY+Y2C44CTF1UW9PotaYvj15Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2010 17:31:24.0017 (UTC) FILETIME=[F7721610:01CB63E9] X-Nokia-AV: Clean Subject: [netext] Agenda slots for IETF79 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 17:30:45 -0000 Hello, The Netext WG will meet at IETF79. If you need an agenda slot, please send a request to the chairs (netext-chairs@tools.ietf.org) with the following information: 1. I-D and title of presentation 2. Time needed 3. How does it relate to the charter and scope of the WG An I-D is required to obtain a timeslot. -Chairs From julienl@qualcomm.com Mon Oct 4 10:37:48 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0CF3A6DDB for ; Mon, 4 Oct 2010 10:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yjbnss-I7lk for ; Mon, 4 Oct 2010 10:37:47 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id AFE603A6FFE for ; Mon, 4 Oct 2010 10:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286213915; x=1317749915; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Tran=20Minh=20Trung=20,=20"net ext@ietf.org"=20|Date:=20Mon,=204=20Oct =202010=2010:38:20=20-0700|Subject:=20RE:=20[netext]=20Th e=20requirements=20for=20supporting=20flow=20mobility=20i n=20PMIPv6|Thread-Topic:=20[netext]=20The=20requirements =20for=20supporting=20flow=20mobility=20in=0D=0A=20PMIPv6 |Thread-Index:=20Actavq0H1vjlgctlSdWtP3op5aki3gJJAc4A |Message-ID:=20|References:=20=0D=0A =20|In-Reply-To:=20|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=JFfk2FMFTX5XoZhg8xaBTTPPjLKhdkkwNb/0nxmGVO4=; b=Sd456k9pH4hL+WHxgg+4xEBeCWZ0UQ6to9dO8cdbL3FrLhm9LI4AGoel xBFI3iC+kHxbsfhAOn1Yl6NvmJasmizb0BUkRnWy7GsutM+UteCAKkTxU Hj3TxodbYZsdbMAdqKmThW63DWQ9awkA+ywiHJGxOz8Hm/EraArqPxspG I=; X-IronPort-AV: E=McAfee;i="5400,1158,6126"; a="56651359" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 04 Oct 2010 10:38:35 -0700 X-IronPort-AV: E=Sophos;i="4.57,279,1283756400"; d="scan'208";a="19565152" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 04 Oct 2010 10:38:34 -0700 Received: from nasanexhc06.na.qualcomm.com (172.30.48.3) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Oct 2010 10:38:35 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhc06.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 4 Oct 2010 10:38:34 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 4 Oct 2010 10:38:27 -0700 From: "Laganier, Julien" To: Tran Minh Trung , "netext@ietf.org" Date: Mon, 4 Oct 2010 10:38:20 -0700 Thread-Topic: [netext] The requirements for supporting flow mobility in PMIPv6 Thread-Index: Actavq0H1vjlgctlSdWtP3op5aki3gJJAc4A 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] The requirements for supporting flow mobility in PMIPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 17:37:48 -0000 Hi Trung, Thank you for sharing the requirements you considered in developing your fl= ow mobility solution. I mostly agree, but I think that your #4 below is not something that you ha= ve to consider as part of developing a flow mobility signaling extension to= PMIPv6. The reason is that the uplink forwarding decision is taken locally= on the mobile node and invisible to the IP layer since it sends all packet= through the logical interface. As such, requirement #4 is internal to the = logical interface and has no bearing on the PMIPv6 signaling between the MA= G and the LMA. --julien > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Tran Minh Trung > Sent: Wednesday, September 22, 2010 6:29 PM > To: netext@ietf.org > Subject: [netext] The requirements for supporting flow mobility in > PMIPv6 >=20 > Hi Julien and all >=20 > I send again the simple requirements for sporting flow mobility stated > in our document: > http://tools.ietf.org/html/draft-trung-netext-flow-mobility-support-00 >=20 > 1. The network should support shared-prefix model (The Mobile Node's > Home Network =A0Prefix should be able to be shared across its > attachments) > 2. The network should support flow-based routing (The Local Mobility > Anchor should be able to bind a particular flow to a Proxy-CoA without > affecting other flow using the same HNP) > 3. The MN should use a single logical interface to hide all existing > physical interfaces. > 4. On receiving a downlink traffic flow, the MN should be able to > select the same path for sending the uplink traffic flow. >=20 > If all of the above requirements are satisfied, then the flow mobility > can be supported. Without one of them, the flow mobility can not be > supported. >=20 > For the requirement #4, if we amuse that the MN has it own flow > policy, then we can just state that: The MN is assumed to be able to > selects the most suitable interface for sending an uplink flow. (In > our next draft version we may add this text) >=20 > I hope that it clears enough for discussing about what are simple > solution requirements. >=20 > Regards, > TrungTM >=20 > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >=20 >=20 >=20 > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute > Standards Research Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From trungtm2909@gmail.com Mon Oct 4 23:14:23 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F1B3A6CC4 for ; Mon, 4 Oct 2010 23:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.94 X-Spam-Level: X-Spam-Status: No, score=-101.94 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86hfwM-cnJ8T for ; Mon, 4 Oct 2010 23:14:21 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7D5C63A6BCA for ; Mon, 4 Oct 2010 23:14:21 -0700 (PDT) Received: by iwn3 with SMTP id 3so9446152iwn.31 for ; Mon, 04 Oct 2010 23:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bUtutuMPXkO5Eq/OirhXzDvR8BZ6DFycqgKIaWoLteE=; b=xCgcntuoED1m96Zm2qDvjhIkjs21nFGDxkUjWKFHpZVVKMecxQ3PP4vLZJrBVfPgJH nsfkBFa9sI+x8qIxmTFhnoSLa/PjGkFNymstwvQIEFLWkeHo5mPt1qZJgXCxtBpe9asd c8q8keCqKAkqzR8tSOQhWA7Wfo+8rqGFQHZo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ft8jVtZ1SubAQRAp0c8uCj6ys/oRaBhuvigDD2KIH+VdBJuG8Yph0k8RXF3Ey0HSdI vcs8IbpQX+lUjKfqr7V2ni9D2COPFiX149JKnigN2jvWETQFdAMUDX1F0Fcid9UJkAw3 SbKvCU1fYmV/OnHPYi1dq4aGLOgVnvSZB4/U4= MIME-Version: 1.0 Received: by 10.231.146.134 with SMTP id h6mr11477452ibv.170.1286259317943; Mon, 04 Oct 2010 23:15:17 -0700 (PDT) Sender: trungtm2909@gmail.com Received: by 10.231.181.19 with HTTP; Mon, 4 Oct 2010 23:15:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Oct 2010 15:15:17 +0900 X-Google-Sender-Auth: ADZmmjb4gyF6PRtB6fYjekg-AqE Message-ID: From: Tran Minh Trung To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] The requirements for supporting flow mobility in PMIPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:14:23 -0000 Hi Julien, On Tue, Oct 5, 2010 at 2:38 AM, Laganier, Julien wro= te: > Hi Trung, > > Thank you for sharing the requirements you considered in developing your = flow mobility solution. > Thank you for your agreement. > I mostly agree, but I think that your #4 below is not something that you = have to consider as part of developing a flow mobility signaling extension = to PMIPv6. The reason is that the uplink forwarding decision is taken local= ly on the mobile node and invisible to the IP layer since it sends all pack= et through the logical interface. As such, requirement #4 is internal to th= e logical interface and has no bearing on the PMIPv6 signaling between the = MAG and the LMA. > I agree. It is out of scope of the PMIPv6's solution document. > --julien > It would be nice if you have time to review our solution and give us commen= ts. Regards, TrungTM >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> Behalf Of Tran Minh Trung >> Sent: Wednesday, September 22, 2010 6:29 PM >> To: netext@ietf.org >> Subject: [netext] The requirements for supporting flow mobility in >> PMIPv6 >> >> Hi Julien and all >> >> I send again the simple requirements for sporting flow mobility stated >> in our document: >> http://tools.ietf.org/html/draft-trung-netext-flow-mobility-support-00 >> >> 1. The network should support shared-prefix model (The Mobile Node's >> Home Network =A0Prefix should be able to be shared across its >> attachments) >> 2. The network should support flow-based routing (The Local Mobility >> Anchor should be able to bind a particular flow to a Proxy-CoA without >> affecting other flow using the same HNP) >> 3. The MN should use a single logical interface to hide all existing >> physical interfaces. >> 4. On receiving a downlink traffic flow, the MN should be able to >> select the same path for sending the uplink traffic flow. >> >> If all of the above requirements are satisfied, then the flow mobility >> can be supported. Without one of them, the flow mobility can not be >> supported. >> >> For the requirement #4, if we amuse that the MN has it own flow >> policy, then we can just state that: The MN is assumed to be able to >> selects the most suitable interface for sending an uplink flow. (In >> our next draft version we may add this text) >> >> I hope that it clears enough for discussing about what are simple >> solution requirements. >> >> Regards, >> TrungTM >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> >> >> >> -- >> Ph.D., Senior Member >> Electronics and Telecommunications Research Institute >> Standards Research Center >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA >> Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132,=A0=A0 Fax : +82-42-861-5404 From cjbc@it.uc3m.es Tue Oct 12 09:44:51 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8953A6931 for ; Tue, 12 Oct 2010 09:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blG19E97P6dk for ; Tue, 12 Oct 2010 09:44:49 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 376303A684F for ; Tue, 12 Oct 2010 09:44:48 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.1.3] (213.37.83.184.dyn.user.ono.com [213.37.83.184]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 74864BEACAD; Tue, 12 Oct 2010 18:46:02 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Laganier, Julien" In-Reply-To: References: <1285108267.7749.373.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VUUORQaLYpZDw7GAGAf9" Organization: Universidad Carlos III de Madrid Date: Tue, 12 Oct 2010 18:46:25 +0200 Message-ID: <1286901985.6959.217.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17700.000 Cc: "netext@ietf.org" Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 16:44:52 -0000 --=-VUUORQaLYpZDw7GAGAf9 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, 2010-10-04 at 09:39 -0700, Laganier, Julien wrote: > Hi Carlos, >=20 > Thank you for sharing with the WG the requirements you've been > considering in developing your flow mobility solution. All > requirements are non-controversial but this one with which I actually > disagree: >=20 > > - Analyze the different scenarios to be supported. We currently > include > > the "shared prefix" and "unique prefix" per physical interface > models. >=20 > I disagree that supporting a per-physical interface prefix is a > requirement to support flow mobility, and there also seems to be > evidence that supporting a per-physical interface prefix is actually > NOT a requirement for flow mobility: At this stage we are just "analyzing the different scenarios to be supported". This does not necessarily mean that at the end we aim at supporting all. Anyway, I think it is in general better not to limit to a single scenario (which is different from current PMIPv6 model), unless there is no (or few) people that want it to be supported (so far some people stated that the "unique prefix" per physical interface is useful and needs to be covered) and considering it adds too much complexity to the solution. Besides, as a side note (as individual, not as editor of draft-bernardos-netext-pmipv6-flowmob), I think that even though we are now assuming the MN implements the logical interface, if we do not limit too much the scenario, the extensions that we develop on the network side could also work for MNs that do not support the logical interface but "flow mobility" in general. Thanks, Carlos >=20 > - Up to version -06 of the PMIPv6 draft it is said that a given mobile > node is allocated a unique set of prefix, that is either stored in the > mobile node's policy profile, or dynamically assigned by the local > mobility anchor.=20 >=20 > - This is changed starting with version -07 with the additional > requirement that "the local mobility anchor MUST allocate a unique > home network prefix for each of the connected interfaces." The > departure from the earlier addressing model is justified because it is > only way to avoid breaking unmodified hosts which would not support > having the same prefix assigned simultaneously on the same interface.=20 >=20 > - The "unique prefix per interface" requirement is no longer justified > for flow mobility work because all the work we're doing, while stile > assuming an unmodified IP layer on the mobile nodes, also assumes that > a logical interfaces hides the multiple physical interfaces. Thus > assigning a single prefix set to the mobile node, independently of > number of physical interfaces does not risk breaking the IP layer. > Additionally, because when flow mobility is in use, packets are > required to be routed on a per-flow basis and no longer based on a > longest prefix match between routing table entries and packet > destination IP address, flow mobility cannot be used to justify the > need for per-interface prefix. =20 >=20 > --julien >=20 > Carlos Jes=FAs Bernardos Cano wrote: > >=20 > > Hi all, > >=20 > > Julien and Raj suggested that people working on flow mobility solutions > > posted a summary of the requirements of goals of their ongoing work. > >=20 > > Authors of draft-bernardos-netext-pmipv6-flowmob are working on the > > next revision for the consideration of the WG. The draft has the > > following goals and requirements: > >=20 > > - The goal is to define PMIPv6 extensions that allow to move flows > > among different simultaneously attaches interfaces of an MN. > >=20 > > - Analyze the different scenarios to be supported. We currently include > > the "shared prefix" and "unique prefix" per physical interface models. > >=20 > > - The solution defines the LMA as the controlling entity. The solution > > defines the signaling between MAG and LMA. The specifics on how the > > network nodes obtain the policies is out of scope. > >=20 > > - The MN is equipped with one logical interface (we don't support flow > > mobility across different logical interfaces). > >=20 > > We are currently working out the details and reaching an agreement > > among the authors of the draft. As soon as we come up with a > > consolidated document (hopefully within the next couple of weeks) we'll > > submit it and ask for feedback to the WG. > >=20 > > Thanks, > >=20 > > Carlos > >=20 > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-VUUORQaLYpZDw7GAGAf9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAky0kOEACgkQNdy6TdFwT2eTyQCgi7AktHlvLeGFdKXzRnNp7to/ kiwAnjMBhpaOpkbPwlzuXdkgxkh/dq5Z =om7X -----END PGP SIGNATURE----- --=-VUUORQaLYpZDw7GAGAf9-- From sgundave@cisco.com Tue Oct 12 12:32:51 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53F43A6A60 for ; Tue, 12 Oct 2010 12:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.393 X-Spam-Level: X-Spam-Status: No, score=-9.393 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xChRoDh3AfbM for ; Tue, 12 Oct 2010 12:32:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 285213A69E9 for ; Tue, 12 Oct 2010 12:32:47 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAdVtEyrRN+J/2dsb2JhbAChCVRxokiceYVIBIRShW+DCQ X-IronPort-AV: E=Sophos;i="4.57,321,1283731200"; d="scan'208";a="370289538" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2010 19:33:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9CJXjd7026441; Tue, 12 Oct 2010 19:33:45 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 12:33:45 -0700 Received: from 10.32.243.111 ([10.32.243.111]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Oct 2010 19:33:45 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 12 Oct 2010 12:34:17 -0700 From: Sri Gundavelli To: , "Laganier, Julien" Message-ID: Thread-Topic: [netext] About draft-bernardos-netext-pmipv6-flowmob Thread-Index: ActqRHVkfboLTf8eWki4McO2n1zEow== In-Reply-To: <1286901985.6959.217.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 12 Oct 2010 19:33:45.0448 (UTC) FILETIME=[62958E80:01CB6A44] Cc: "netext@ietf.org" Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:32:52 -0000 Adding to what Carlos said. On 10/12/10 9:46 AM, "Carlos Jes=FAs Bernardos Cano" wrote: > At this stage we are just "analyzing the different scenarios to be > supported". This does not necessarily mean that at the end we aim at > supporting all. Anyway, I think it is in general better not to limit to > a single scenario (which is different from current PMIPv6 model), unless > there is no (or few) people that want it to be supported (so far some > people stated that the "unique prefix" per physical interface is useful > and needs to be covered) and considering it adds too much complexity to > the solution. I'm not sure, if supporting prefixes per-interfaces is complex, or supporting a single prefix across access networks is complex. One way to look at it is, this is the default behavior of the base specification, the ability to allocate a unique prefix per-interface, the natural multi-homing behavior as per RFC-5213. Now, when we support flow-mobility, that is not taking away this basic capability from the specification, we will continue to support that. Additionally, if we look at this from the perspective of a logical interface, we are truly hosting a set of prefixes for a given interface which is the virtual/logical interface, for the same reason as when we have added multiple prefix support to the base spec for resolving the IESG Discuss, "retain support for the basic IPv6 link property, ability to host multiple prefixes on a given link". The ability to allocate prefixes per-interface, will also give the ability to move that entire prefix as a flow aggregate between interfaces. A prefix which was advertised on interface-1, can simply be hosted on interface-2, with the resulting affect of flow group movement between interfaces. This approach offers the natural ability for the network node to hint the presence of a new prefix simply by sending a RA, with the new PIO option. There is a natural MN-AR trigger, in the form of RA's. The MN has a clear visibility on the hosted prefixes at a physical interface level and hence the forwarding capability. A prefix on interface-1, or on interface-2 is implicit by the RA hints. This approach allows a simply flow mobility approach for deployments to categorize flows based on APN's and move all the flows associated to an APN from interface-1 to interface-2. A policy which states, all these flows bound this APN, when in the presence of WLAN interface, use that interface. Additionally, we can provide more granular approach, at a flow level, but a= t the risk of lack of MN-AR hints and some assumptions. Ignoring the split link issues, we can have a layer-2 based policy which states, any time the MN see's a WLAN interface, flow-1, flow-2, flow-3 move it on to that WLAN interface, irrespective of the source prefix, we can move the flow across. The MN can assume, the network has the same forwarding state as the MN, the MN has the understanding to differentiate between the various states of tha= t WLAN interface, if there is a MAG on the WLAN link, or if access security matters, DHCP state matters, when to start forwarding packets, after the L2 attach, after the address configuration and after access authentication, in the absence of any MN-AR hints, sure this can work with some hard assumptions. All of this in comparison to the natural multi-homing behavior per 5213. So, we will document both and we can discuss what is complex and see the wa= y forward. Sri >=20 > Besides, as a side note (as individual, not as editor of > draft-bernardos-netext-pmipv6-flowmob), I think that even though we are > now assuming the MN implements the logical interface, if we do not limit > too much the scenario, the extensions that we develop on the network > side could also work for MNs that do not support the logical interface > but "flow mobility" in general. >=20 > Thanks, >=20 > Carlos >=20 >>=20 >> - Up to version -06 of the PMIPv6 draft it is said that a given mobile >> node is allocated a unique set of prefix, that is either stored in the >> mobile node's policy profile, or dynamically assigned by the local >> mobility anchor. >>=20 >> - This is changed starting with version -07 with the additional >> requirement that "the local mobility anchor MUST allocate a unique >> home network prefix for each of the connected interfaces." The >> departure from the earlier addressing model is justified because it is >> only way to avoid breaking unmodified hosts which would not support >> having the same prefix assigned simultaneously on the same interface. >>=20 >> - The "unique prefix per interface" requirement is no longer justified >> for flow mobility work because all the work we're doing, while stile >> assuming an unmodified IP layer on the mobile nodes, also assumes that >> a logical interfaces hides the multiple physical interfaces. Thus >> assigning a single prefix set to the mobile node, independently of >> number of physical interfaces does not risk breaking the IP layer. >> Additionally, because when flow mobility is in use, packets are >> required to be routed on a per-flow basis and no longer based on a >> longest prefix match between routing table entries and packet >> destination IP address, flow mobility cannot be used to justify the >> need for per-interface prefix. >>=20 >> --julien >>=20 >> Carlos Jes=FAs Bernardos Cano wrote: >>>=20 >>> Hi all, >>>=20 >>> Julien and Raj suggested that people working on flow mobility solutions >>> posted a summary of the requirements of goals of their ongoing work. >>>=20 >>> Authors of draft-bernardos-netext-pmipv6-flowmob are working on the >>> next revision for the consideration of the WG. The draft has the >>> following goals and requirements: >>>=20 >>> - The goal is to define PMIPv6 extensions that allow to move flows >>> among different simultaneously attaches interfaces of an MN. >>>=20 >>> - Analyze the different scenarios to be supported. We currently include >>> the "shared prefix" and "unique prefix" per physical interface models. >>>=20 >>> - The solution defines the LMA as the controlling entity. The solution >>> defines the signaling between MAG and LMA. The specifics on how the >>> network nodes obtain the policies is out of scope. >>>=20 >>> - The MN is equipped with one logical interface (we don't support flow >>> mobility across different logical interfaces). >>>=20 >>> We are currently working out the details and reaching an agreement >>> among the authors of the draft. As soon as we come up with a >>> consolidated document (hopefully within the next couple of weeks) we'll >>> submit it and ask for feedback to the WG. >>>=20 >>> Thanks, >>>=20 >>> Carlos >>>=20 >>> -- >>> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net >>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From sgundave@cisco.com Tue Oct 12 12:54:54 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1289B3A6A62 for ; Tue, 12 Oct 2010 12:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.369 X-Spam-Level: X-Spam-Status: No, score=-9.369 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlqWJ6ic8okt for ; Tue, 12 Oct 2010 12:54:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 123333A6A5B for ; Tue, 12 Oct 2010 12:54:52 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMFZtEyrR7H+/2dsb2JhbAChClRxojCdAIVIBIRShW+DCQ X-IronPort-AV: E=Sophos;i="4.57,321,1283731200"; d="scan'208";a="370299258" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2010 19:56:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9CJu6Fo009219; Tue, 12 Oct 2010 19:56:07 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 12:56:06 -0700 Received: from 10.32.243.111 ([10.32.243.111]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Oct 2010 19:56:05 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 12 Oct 2010 12:56:36 -0700 From: Sri Gundavelli To: Sri Gundavelli , , "Laganier, Julien" Message-ID: Thread-Topic: [netext] About draft-bernardos-netext-pmipv6-flowmob Thread-Index: ActqRHVkfboLTf8eWki4McO2n1zEowAAx4aH In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 12 Oct 2010 19:56:06.0425 (UTC) FILETIME=[81DE6890:01CB6A47] Cc: "netext@ietf.org" Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:54:54 -0000 Also, I'd like to remind, the use-cases for flow mobility is not like in Hollywood action movies. Flow-1 comes on interface-1, network triggers it dynamically to move the flow to interface-2, the third second, while the MN is still connected to the same set of interfaces, the network tells the MN to move the flow back to Interface-1, because it saw another traffic intensive flow from another MN. So, it pushes the policy to the MN, it also triggers the MAG, which it cant do a thing about it in the absence of MN-AR triggers, but it gets the policy for the heck of it. I don't believe any operator deployments are looking at this level of complexity. Lets be realistic in the the scenarios and solutions. IMO, Most operators are looking at simple policies, such as: - When in the presence of WLAN, move certain type of traffic flows to WLAN, keep my essential flows related to operator value added services to the macro network. - Offload most non essential traffic over WLAN, don't bring it back to EPC. To solve this, I need the simple ability to move a set of flows, as a group= , I can manage them at the granularity of a prefix level/APN level. I don't have to exchange complex flow templates. As part of the address assignment procedures, the LMA can give the set of prefixes, which the MAG can host on the link, that's all I need. I do not require complex policies on the MN, i= t knows when a prefix is on a given link and when it is not, by virtue of RA's, I don't require complex logic on the UE. Any thing more beyond this is a bonus feature addition and that is fine wit= h me, we can keep ourselves busy. If any one wants to challenge me, I want to hear first on some practical and realistic operator input on the most commo= n scenarios that they are interested in. So, lets take an incremental approach, lets not overload this document with every possible scenario, on day-1. Sri On 10/12/10 12:34 PM, "Sri Gundavelli" wrote: > Adding to what Carlos said. >=20 >=20 > On 10/12/10 9:46 AM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >=20 >> At this stage we are just "analyzing the different scenarios to be >> supported". This does not necessarily mean that at the end we aim at >> supporting all. Anyway, I think it is in general better not to limit to >> a single scenario (which is different from current PMIPv6 model), unless >> there is no (or few) people that want it to be supported (so far some >> people stated that the "unique prefix" per physical interface is useful >> and needs to be covered) and considering it adds too much complexity to >> the solution. >=20 > I'm not sure, if supporting prefixes per-interfaces is complex, or > supporting a single prefix across access networks is complex. One way to > look at it is, this is the default behavior of the base specification, th= e > ability to allocate a unique prefix per-interface, the natural multi-homi= ng > behavior as per RFC-5213. Now, when we support flow-mobility, that is not > taking away this basic capability from the specification, we will continu= e > to support that. Additionally, if we look at this from the perspective of= a > logical interface, we are truly hosting a set of prefixes for a given > interface which is the virtual/logical interface, for the same reason as > when we have added multiple prefix support to the base spec for resolving > the IESG Discuss, "retain support for the basic IPv6 link property, abili= ty > to host multiple prefixes on a given link". >=20 > The ability to allocate prefixes per-interface, will also give the abilit= y > to move that entire prefix as a flow aggregate between interfaces. A pref= ix > which was advertised on interface-1, can simply be hosted on interface-2, > with the resulting affect of flow group movement between interfaces. This > approach offers the natural ability for the network node to hint the > presence of a new prefix simply by sending a RA, with the new PIO option. > There is a natural MN-AR trigger, in the form of RA's. The MN has a clear > visibility on the hosted prefixes at a physical interface level and hence > the forwarding capability. A prefix on interface-1, or on interface-2 is > implicit by the RA hints. >=20 > This approach allows a simply flow mobility approach for deployments to > categorize flows based on APN's and move all the flows associated to an A= PN > from interface-1 to interface-2. A policy which states, all these flows > bound this APN, when in the presence of WLAN interface, use that interfac= e. >=20 > Additionally, we can provide more granular approach, at a flow level, but= at > the risk of lack of MN-AR hints and some assumptions. Ignoring the split > link issues, we can have a layer-2 based policy which states, any time th= e > MN see's a WLAN interface, flow-1, flow-2, flow-3 move it on to that WLAN > interface, irrespective of the source prefix, we can move the flow across= . > The MN can assume, the network has the same forwarding state as the MN, t= he > MN has the understanding to differentiate between the various states of t= hat > WLAN interface, if there is a MAG on the WLAN link, or if access security > matters, DHCP state matters, when to start forwarding packets, after the = L2 > attach, after the address configuration and after access authentication, = in > the absence of any MN-AR hints, sure this can work with some hard > assumptions. All of this in comparison to the natural multi-homing behavi= or > per 5213. >=20 > So, we will document both and we can discuss what is complex and see the = way > forward. >=20 >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> Besides, as a side note (as individual, not as editor of >> draft-bernardos-netext-pmipv6-flowmob), I think that even though we are >> now assuming the MN implements the logical interface, if we do not limit >> too much the scenario, the extensions that we develop on the network >> side could also work for MNs that do not support the logical interface >> but "flow mobility" in general. >>=20 >> Thanks, >>=20 >> Carlos >>=20 >>>=20 >>> - Up to version -06 of the PMIPv6 draft it is said that a given mobile >>> node is allocated a unique set of prefix, that is either stored in the >>> mobile node's policy profile, or dynamically assigned by the local >>> mobility anchor. >>>=20 >>> - This is changed starting with version -07 with the additional >>> requirement that "the local mobility anchor MUST allocate a unique >>> home network prefix for each of the connected interfaces." The >>> departure from the earlier addressing model is justified because it is >>> only way to avoid breaking unmodified hosts which would not support >>> having the same prefix assigned simultaneously on the same interface. >>>=20 >>> - The "unique prefix per interface" requirement is no longer justified >>> for flow mobility work because all the work we're doing, while stile >>> assuming an unmodified IP layer on the mobile nodes, also assumes that >>> a logical interfaces hides the multiple physical interfaces. Thus >>> assigning a single prefix set to the mobile node, independently of >>> number of physical interfaces does not risk breaking the IP layer. >>> Additionally, because when flow mobility is in use, packets are >>> required to be routed on a per-flow basis and no longer based on a >>> longest prefix match between routing table entries and packet >>> destination IP address, flow mobility cannot be used to justify the >>> need for per-interface prefix. >>>=20 >>> --julien >>>=20 >>> Carlos Jes=FAs Bernardos Cano wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> Julien and Raj suggested that people working on flow mobility solution= s >>>> posted a summary of the requirements of goals of their ongoing work. >>>>=20 >>>> Authors of draft-bernardos-netext-pmipv6-flowmob are working on the >>>> next revision for the consideration of the WG. The draft has the >>>> following goals and requirements: >>>>=20 >>>> - The goal is to define PMIPv6 extensions that allow to move flows >>>> among different simultaneously attaches interfaces of an MN. >>>>=20 >>>> - Analyze the different scenarios to be supported. We currently includ= e >>>> the "shared prefix" and "unique prefix" per physical interface models. >>>>=20 >>>> - The solution defines the LMA as the controlling entity. The solution >>>> defines the signaling between MAG and LMA. The specifics on how the >>>> network nodes obtain the policies is out of scope. >>>>=20 >>>> - The MN is equipped with one logical interface (we don't support flow >>>> mobility across different logical interfaces). >>>>=20 >>>> We are currently working out the details and reaching an agreement >>>> among the authors of the draft. As soon as we come up with a >>>> consolidated document (hopefully within the next couple of weeks) we'l= l >>>> submit it and ask for feedback to the WG. >>>>=20 >>>> Thanks, >>>>=20 >>>> Carlos >>>>=20 >>>> -- >>>> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net >>>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Tue Oct 12 14:08:22 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219A83A6A8F for ; Tue, 12 Oct 2010 14:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFqcu00Fdos1 for ; Tue, 12 Oct 2010 14:08:20 -0700 (PDT) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by core3.amsl.com (Postfix) with SMTP id 2A5D63A6A87 for ; Tue, 12 Oct 2010 14:08:19 -0700 (PDT) Received: from [98.139.91.69] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 12 Oct 2010 21:09:32 -0000 Received: from [98.139.91.23] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 12 Oct 2010 21:09:31 -0000 Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 12 Oct 2010 21:09:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 372816.19751.bm@omp1023.mail.sp2.yahoo.com Received: (qmail 25227 invoked by uid 60001); 12 Oct 2010 21:09:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1286917770; bh=pdqj2YwwEMEFfP8IFgL2dCP+oDl9NtXxkvnttl/AxEo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0g6AAhBviPmVHrNdHpKs14KvxvI85ErbBnJrGx8z9NMR6PftgWPX+Q3J9DbcRubuzYR12TY3FpVBTXPwos6wgZtUhkJ+A27GqJ2tEDGuBS79RRmyAPk9uEMweLEqww3Mk9LYrNjbUuQ52NviXGhrMACKXecFswilXkwZcVJrmcY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1xROS3/9Z6Kdg39/hbbvdBoMNAlJQxOfHHgP9FUz1ayNKWBIA6J7104YVBgKMvEr07fBq4Re+CxEgy+jMBl1NiY3B4YS9sFVpPVkaRJhL2qXd5ifM6z/ZbohuD/SgUFHuMzmKUGjDjLD8lM6ijHdZrT7QKQIOG3WOiMVPTp0SEQ=; Message-ID: <770597.23926.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: 3Rm2pucVM1l8vKAc5DTJ76Q7a.kOajuwxCnXKpP2pZcRCZJ 3qijDhjUEJgnXn.tlqdD0F7R9Sgh_7N7KYk7f6CPrSZmsCYjA0qRrPMje0gs 6G.jNiIiC.WE7ZdYBTGrfwq_8Gjnjk1vfvdjLH82.ndzWkZWy0byECwktsiZ 9s8Wk3.p2KzD8F8K8TevzBCntAuiELDUYXXZdTWy4Y7xRR0Vgh5hEO5Swq8I vtv7KF8wXDkdwR.Z0HfgukxNyNTK8SWYphLi3iQtuwFyXlK71cle99JzAzVK 8948J6rpXo4QNCgMIY9aQusGA9tKpTTLy1.CTIvgTkbbth75pJBgQU1I3Ot. i23mFIZHuWs4B3JDlkBl6DF6WCg-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 12 Oct 2010 14:09:30 PDT X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.106.282862 References: Date: Tue, 12 Oct 2010 14:09:30 -0700 (PDT) From: Behcet Sarikaya To: Sri Gundavelli In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "netext@ietf.org" Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 21:08:22 -0000 Hi Sri,=0A How does a prefix become a flow description? =0A=0ARegards,=0A= =0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: Sri Gundavelli <= sgundave@cisco.com>=0A> To: Sri Gundavelli ; cjbc@it.uc= 3m.es; "Laganier, Julien" =0A>=0A> Cc: "netext@ietf.o= rg" =0A> Sent: Tue, October 12, 2010 2:56:36 PM=0A> Subjec= t: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob=0A> =0A> Also, = I'd like to remind, the use-cases for flow mobility is not like in=0A> Hol= lywood action movies. Flow-1 comes on interface-1, network triggers it=0A>= dynamically to move the flow to interface-2, the third second, while the = MN=0A> is still connected to the same set of interfaces, the network tells = the MN=0A> to move the flow back to Interface-1, because it saw another t= raffic=0A> intensive flow from another MN. So, it pushes the policy to the = MN, it also=0A> triggers the MAG, which it cant do a thing about it in the= absence of MN-AR=0A> triggers, but it gets the policy for the heck of it.= I don't believe any=0A> operator deployments are looking at this level o= f complexity. Lets be=0A> realistic in the the scenarios and solutions.=0A= > =0A> IMO, Most operators are looking at simple policies, such as:=0A> = =0A> - When in the presence of WLAN, move certain type of traffic flows to= WLAN,=0A> keep my essential flows related to operator value added service= s to the=0A> macro network.=0A> - Offload most non essential traffic over = WLAN, don't bring it back to EPC.=0A> =0A> To solve this, I need the simpl= e ability to move a set of flows, as a group,=0A> I can manage them at the= granularity of a prefix level/APN level. I don't=0A> have to exchange com= plex flow templates. As part of the address assignment=0A> procedures, the= LMA can give the set of prefixes, which the MAG can host on=0A> the link,= that's all I need. I do not require complex policies on the MN, it=0A> kn= ows when a prefix is on a given link and when it is not, by virtue of=0A> = RA's, I don't require complex logic on the UE.=0A> =0A> Any thing more bey= ond this is a bonus feature addition and that is fine with=0A> me, we can = keep ourselves busy. If any one wants to challenge me, I want to=0A> hear f= irst on some practical and realistic operator input on the most common=0A>= scenarios that they are interested in. So, lets take an incremental=0A> a= pproach, lets not overload this document with every possible scenario, on= =0A> day-1.=0A> =0A> =0A> =0A> Sri=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> = =0A> =0A> On 10/12/10 12:34 PM, "Sri Gundavelli" wrot= e:=0A> =0A> > Adding to what Carlos said.=0A> > =0A> > =0A> > On 10/12/10 = 9:46 AM, "Carlos Jes=FAs Bernardos Cano" wrote:=0A> > = =0A> >> At this stage we are just "analyzing the different scenarios to be= =0A> >> supported". This does not necessarily mean that at the end we aim = at=0A> >> supporting all. Anyway, I think it is in general better not to l= imit to=0A> >> a single scenario (which is different from current PMIPv6 m= odel), unless=0A> >> there is no (or few) people that want it to be suppor= ted (so far some=0A> >> people stated that the "unique prefix" per physica= l interface is useful=0A> >> and needs to be covered) and considering it a= dds too much complexity to=0A> >> the solution.=0A> > =0A> > I'm not sure, = if supporting prefixes per-interfaces is complex, or=0A> > supporting a si= ngle prefix across access networks is complex. One way to=0A> > look at it= is, this is the default behavior of the base specification, the=0A> > abi= lity to allocate a unique prefix per-interface, the natural multi-homing= =0A> > behavior as per RFC-5213. Now, when we support flow-mobility, that = is not=0A> > taking away this basic capability from the specification, we = will continue=0A> > to support that. Additionally, if we look at this from= the perspective of a=0A> > logical interface, we are truly hosting a set = of prefixes for a given=0A> > interface which is the virtual/logical inter= face, for the same reason as=0A> > when we have added multiple prefix supp= ort to the base spec for resolving=0A> > the IESG Discuss, "retain support= for the basic IPv6 link property, ability=0A> > to host multiple prefixes= on a given link".=0A> > =0A> > The ability to allocate prefixes per-inter= face, will also give the ability=0A> > to move that entire prefix as a flo= w aggregate between interfaces. A prefix=0A> > which was advertised on int= erface-1, can simply be hosted on interface-2,=0A> > with the resulting af= fect of flow group movement between interfaces. This=0A> > approach offers= the natural ability for the network node to hint the=0A> > presence of a = new prefix simply by sending a RA, with the new PIO option.=0A> > There is= a natural MN-AR trigger, in the form of RA's. The MN has a clear=0A> > vi= sibility on the hosted prefixes at a physical interface level and hence=0A= > > the forwarding capability. A prefix on interface-1, or on interface-2 = is=0A> > implicit by the RA hints.=0A> > =0A> > This approach allows a sim= ply flow mobility approach for deployments to=0A> > categorize flows based= on APN's and move all the flows associated to an =0AAPN=0A> > from interf= ace-1 to interface-2. A policy which states, all these flows=0A> > bound t= his APN, when in the presence of WLAN interface, use that interface.=0A> >= =0A> > Additionally, we can provide more granular approach, at a flow lev= el, but =0Aat=0A> > the risk of lack of MN-AR hints and some assumptions. = Ignoring the split=0A> > link issues, we can have a layer-2 based policy w= hich states, any time the=0A> > MN see's a WLAN interface, flow-1, flow-2,= flow-3 move it on to that WLAN=0A> > interface, irrespective of the sourc= e prefix, we can move the flow across.=0A> > The MN can assume, the networ= k has the same forwarding state as the MN, the=0A> > MN has the understand= ing to differentiate between the various states of =0Athat=0A> > WLAN inte= rface, if there is a MAG on the WLAN link, or if access security=0A> > mat= ters, DHCP state matters, when to start forwarding packets, after the =0AL= 2=0A> > attach, after the address configuration and after access authentic= ation, in=0A> > the absence of any MN-AR hints, sure this can work with so= me hard=0A> > assumptions. All of this in comparison to the natural multi-= homing behavior=0A> > per 5213.=0A> > =0A> > So, we will document both and= we can discuss what is complex and see the =0Away=0A> > forward.=0A> > =0A= > > =0A> > =0A> > Sri=0A> > =0A> > =0A> > =0A> > =0A> > =0A> > =0A> > =0A> = >> =0A> >> Besides, as a side note (as individual, not as editor of=0A> >>= draft-bernardos-netext-pmipv6-flowmob), I think that even though we are= =0A> >> now assuming the MN implements the logical interface, if we do not= limit=0A> >> too much the scenario, the extensions that we develop on the= network=0A> >> side could also work for MNs that do not support the logic= al interface=0A> >> but "flow mobility" in general.=0A> >> =0A> >> Thanks,= =0A> >> =0A> >> Carlos=0A> >> =0A> >>> =0A> >>> - Up to version -06 of the= PMIPv6 draft it is said that a given mobile=0A> >>> node is allocated a = unique set of prefix, that is either stored in the=0A> >>> mobile node's p= olicy profile, or dynamically assigned by the local=0A> >>> mobility ancho= r.=0A> >>> =0A> >>> - This is changed starting with version -07 with the a= dditional=0A> >>> requirement that "the local mobility anchor MUST allocat= e a unique=0A> >>> home network prefix for each of the connected interface= s." The=0A> >>> departure from the earlier addressing model is justified b= ecause it is=0A> >>> only way to avoid breaking unmodified hosts which wou= ld not support=0A> >>> having the same prefix assigned simultaneously on t= he same interface.=0A> >>> =0A> >>> - The "unique prefix per interface" req= uirement is no longer justified=0A> >>> for flow mobility work because all= the work we're doing, while stile=0A> >>> assuming an unmodified IP layer= on the mobile nodes, also assumes that=0A> >>> a logical interfaces hides= the multiple physical interfaces. Thus=0A> >>> assigning a single prefix = set to the mobile node, independently of=0A> >>> number of physical interf= aces does not risk breaking the IP layer.=0A> >>> Additionally, because wh= en flow mobility is in use, packets are=0A> >>> required to be routed on a= per-flow basis and no longer based on a=0A> >>> longest prefix match bet= ween routing table entries and packet=0A> >>> destination IP address, flow= mobility cannot be used to justify the=0A> >>> need for per-interface pre= fix.=0A> >>> =0A> >>> --julien=0A> >>> =0A> >>> Carlos Jes=FAs Bernardos Ca= no wrote:=0A> >>>> =0A> >>>> Hi all,=0A> >>>> =0A> >>>> Julien and Raj sug= gested that people working on flow mobility solutions=0A> >>>> posted a su= mmary of the requirements of goals of their ongoing work.=0A> >>>> =0A> >>= >> Authors of draft-bernardos-netext-pmipv6-flowmob are working on the=0A>= >>>> next revision for the consideration of the WG. The draft has the=0A= > >>>> following goals and requirements:=0A> >>>> =0A> >>>> - The goal is t= o define PMIPv6 extensions that allow to move flows=0A> >>>> among differe= nt simultaneously attaches interfaces of an MN.=0A> >>>> =0A> >>>> - Analy= ze the different scenarios to be supported. We currently include=0A> >>>> = the "shared prefix" and "unique prefix" per physical interface models.=0A= > >>>> =0A> >>>> - The solution defines the LMA as the controlling entity.= The solution=0A> >>>> defines the signaling between MAG and LMA. The spec= ifics on how the=0A> >>>> network nodes obtain the policies is out of scop= e.=0A> >>>> =0A> >>>> - The MN is equipped with one logical interface (we d= on't support flow=0A> >>>> mobility across different logical interfaces).= =0A> >>>> =0A> >>>> We are currently working out the details and reaching = an agreement=0A> >>>> among the authors of the draft. As soon as we come u= p with a=0A> >>>> consolidated document (hopefully within the next couple = of weeks) we'll=0A> >>>> submit it and ask for feedback to the WG.=0A> >>>= > =0A> >>>> Thanks,=0A> >>>> =0A> >>>> Carlos=0A> >>>> =0A> >>>> --=0A> >>= >> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net=0A> >>>> GPG = FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67=0A> > =0A> > ______= _________________________________________=0A> > netext mailing list=0A> > = netext@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/netext=0A> =0A>= _______________________________________________=0A> netext mailing list= =0A> netext@ietf.org=0A> https://www.ietf.org/mailman/listinfo/netext=0A> = =0A=0A=0A From sgundave@cisco.com Tue Oct 12 14:48:19 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EB83A6A72 for ; Tue, 12 Oct 2010 14:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.447 X-Spam-Level: X-Spam-Status: No, score=-8.447 tagged_above=-999 required=5 tests=[AWL=-1.644, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_51=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7zE1U2lXR8s for ; Tue, 12 Oct 2010 14:48:17 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C6A793A6864 for ; Tue, 12 Oct 2010 14:48:17 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKp0tEyrR7Ht/2dsb2JhbACTI41aVHGhOJ0BhUgEhFKFb4MJgmA X-IronPort-AV: E=Sophos;i="4.57,322,1283731200"; d="scan'208";a="199706906" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Oct 2010 21:49:32 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9CLnWp6011436; Tue, 12 Oct 2010 21:49:32 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 14:49:32 -0700 Received: from 10.32.243.111 ([10.32.243.111]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Oct 2010 21:49:32 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 12 Oct 2010 14:50:05 -0700 From: Sri Gundavelli To: Behcet Sarikaya Message-ID: Thread-Topic: [netext] About draft-bernardos-netext-pmipv6-flowmob Thread-Index: ActqV236NJy25nyrOkewaZUC94VZbQ== In-Reply-To: <770597.23926.qm@web111414.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 12 Oct 2010 21:49:32.0621 (UTC) FILETIME=[5AAD7FD0:01CB6A57] Cc: "netext@ietf.org" Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 21:48:20 -0000 YOUTUBE: Flow-1: src: cafe::1, dest: babe::1, sport=3Dx, dport=3Dz APN:INTERNET PANDORA: Flow-2: src: cafe::1, dest: dead::1, sport=3Dy, dport=3Dw APN:INTERNET SIP: Flow-3: src: face::1, dest: cead::1, sport=3Da, dport=3Db APN:IMS VPN: Flow-4: src: face::1, dest: deaf::1, sport=3Dd, dport=3Dc APN:ENT Flow Groups: 1. (Flow-1, Flow-2)---> CAFE::/64 2. (Flow-3, Flow-4)---> FACE::/64 Move Flow Group#1, by moving prefix CAFE::/64, as an aggregate. That's your flow group description. RA with the PIO Option (CAFE::1/64) on the new link= , avoid split link. Sri =20 On 10/12/10 2:09 PM, "Behcet Sarikaya" wrote: > Hi Sri, > How does a prefix become a flow description? >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > ----- Original Message ---- >> From: Sri Gundavelli >> To: Sri Gundavelli ; cjbc@it.uc3m.es; "Laganier, Jul= ien" >> >> Cc: "netext@ietf.org" >> Sent: Tue, October 12, 2010 2:56:36 PM >> Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob >>=20 >> Also, I'd like to remind, the use-cases for flow mobility is not like i= n >> Hollywood action movies. Flow-1 comes on interface-1, network triggers = it >> dynamically to move the flow to interface-2, the third second, while the= MN >> is still connected to the same set of interfaces, the network tells the = MN >> to move the flow back to Interface-1, because it saw another traffic >> intensive flow from another MN. So, it pushes the policy to the MN, it = also >> triggers the MAG, which it cant do a thing about it in the absence of M= N-AR >> triggers, but it gets the policy for the heck of it. I don't believe a= ny >> operator deployments are looking at this level of complexity. Lets be >> realistic in the the scenarios and solutions. >>=20 >> IMO, Most operators are looking at simple policies, such as: >>=20 >> - When in the presence of WLAN, move certain type of traffic flows to W= LAN, >> keep my essential flows related to operator value added services to the >> macro network. >> - Offload most non essential traffic over WLAN, don't bring it back to = EPC. >>=20 >> To solve this, I need the simple ability to move a set of flows, as a g= roup, >> I can manage them at the granularity of a prefix level/APN level. I don= 't >> have to exchange complex flow templates. As part of the address assign= ment >> procedures, the LMA can give the set of prefixes, which the MAG can hos= t on >> the link, that's all I need. I do not require complex policies on the M= N, it >> knows when a prefix is on a given link and when it is not, by virtue of >> RA's, I don't require complex logic on the UE. >>=20 >> Any thing more beyond this is a bonus feature addition and that is fine= with >> me, we can keep ourselves busy. If any one wants to challenge me, I wan= t to >> hear first on some practical and realistic operator input on the most c= ommon >> scenarios that they are interested in. So, lets take an incremental >> approach, lets not overload this document with every possible scenario,= on >> day-1. >>=20 >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 10/12/10 12:34 PM, "Sri Gundavelli" wrote: >>=20 >>> Adding to what Carlos said. >>>=20 >>>=20 >>> On 10/12/10 9:46 AM, "Carlos Jes=FAs Bernardos Cano" w= rote: >>>=20 >>>> At this stage we are just "analyzing the different scenarios to be >>>> supported". This does not necessarily mean that at the end we aim at >>>> supporting all. Anyway, I think it is in general better not to limit = to >>>> a single scenario (which is different from current PMIPv6 model), unl= ess >>>> there is no (or few) people that want it to be supported (so far some >>>> people stated that the "unique prefix" per physical interface is usef= ul >>>> and needs to be covered) and considering it adds too much complexity = to >>>> the solution. >>>=20 >>> I'm not sure, if supporting prefixes per-interfaces is complex, or >>> supporting a single prefix across access networks is complex. One way = to >>> look at it is, this is the default behavior of the base specification,= the >>> ability to allocate a unique prefix per-interface, the natural multi-h= oming >>> behavior as per RFC-5213. Now, when we support flow-mobility, that is = not >>> taking away this basic capability from the specification, we will cont= inue >>> to support that. Additionally, if we look at this from the perspective= of a >>> logical interface, we are truly hosting a set of prefixes for a given >>> interface which is the virtual/logical interface, for the same reason = as >>> when we have added multiple prefix support to the base spec for resolv= ing >>> the IESG Discuss, "retain support for the basic IPv6 link property, ab= ility >>> to host multiple prefixes on a given link". >>>=20 >>> The ability to allocate prefixes per-interface, will also give the abi= lity >>> to move that entire prefix as a flow aggregate between interfaces. A p= refix >>> which was advertised on interface-1, can simply be hosted on interface= -2, >>> with the resulting affect of flow group movement between interfaces. T= his >>> approach offers the natural ability for the network node to hint the >>> presence of a new prefix simply by sending a RA, with the new PIO opt= ion. >>> There is a natural MN-AR trigger, in the form of RA's. The MN has a cl= ear >>> visibility on the hosted prefixes at a physical interface level and he= nce >>> the forwarding capability. A prefix on interface-1, or on interface-2 = is >>> implicit by the RA hints. >>>=20 >>> This approach allows a simply flow mobility approach for deployments t= o >>> categorize flows based on APN's and move all the flows associated to a= n > APN >>> from interface-1 to interface-2. A policy which states, all these flow= s >>> bound this APN, when in the presence of WLAN interface, use that inter= face. >>>=20 >>> Additionally, we can provide more granular approach, at a flow level, = but > at >>> the risk of lack of MN-AR hints and some assumptions. Ignoring the spl= it >>> link issues, we can have a layer-2 based policy which states, any time= the >>> MN see's a WLAN interface, flow-1, flow-2, flow-3 move it on to that W= LAN >>> interface, irrespective of the source prefix, we can move the flow acr= oss. >>> The MN can assume, the network has the same forwarding state as the MN= , the >>> MN has the understanding to differentiate between the various states o= f > that >>> WLAN interface, if there is a MAG on the WLAN link, or if access secur= ity >>> matters, DHCP state matters, when to start forwarding packets, after t= he > L2 >>> attach, after the address configuration and after access authenticatio= n, in >>> the absence of any MN-AR hints, sure this can work with some hard >>> assumptions. All of this in comparison to the natural multi-homing beh= avior >>> per 5213. >>>=20 >>> So, we will document both and we can discuss what is complex and see t= he > way >>> forward. >>>=20 >>>=20 >>>=20 >>> Sri >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Besides, as a side note (as individual, not as editor of >>>> draft-bernardos-netext-pmipv6-flowmob), I think that even though we a= re >>>> now assuming the MN implements the logical interface, if we do not li= mit >>>> too much the scenario, the extensions that we develop on the network >>>> side could also work for MNs that do not support the logical interfac= e >>>> but "flow mobility" in general. >>>>=20 >>>> Thanks, >>>>=20 >>>> Carlos >>>>=20 >>>>>=20 >>>>> - Up to version -06 of the PMIPv6 draft it is said that a given mobi= le >>>>> node is allocated a unique set of prefix, that is either stored in t= he >>>>> mobile node's policy profile, or dynamically assigned by the local >>>>> mobility anchor. >>>>>=20 >>>>> - This is changed starting with version -07 with the additional >>>>> requirement that "the local mobility anchor MUST allocate a unique >>>>> home network prefix for each of the connected interfaces." The >>>>> departure from the earlier addressing model is justified because it = is >>>>> only way to avoid breaking unmodified hosts which would not support >>>>> having the same prefix assigned simultaneously on the same interface= . >>>>>=20 >>>>> - The "unique prefix per interface" requirement is no longer justifi= ed >>>>> for flow mobility work because all the work we're doing, while stile >>>>> assuming an unmodified IP layer on the mobile nodes, also assumes th= at >>>>> a logical interfaces hides the multiple physical interfaces. Thus >>>>> assigning a single prefix set to the mobile node, independently of >>>>> number of physical interfaces does not risk breaking the IP layer. >>>>> Additionally, because when flow mobility is in use, packets are >>>>> required to be routed on a per-flow basis and no longer based on a >>>>> longest prefix match between routing table entries and packet >>>>> destination IP address, flow mobility cannot be used to justify the >>>>> need for per-interface prefix. >>>>>=20 >>>>> --julien >>>>>=20 >>>>> Carlos Jes=FAs Bernardos Cano wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Julien and Raj suggested that people working on flow mobility solut= ions >>>>>> posted a summary of the requirements of goals of their ongoing wor= k. >>>>>>=20 >>>>>> Authors of draft-bernardos-netext-pmipv6-flowmob are working on the >>>>>> next revision for the consideration of the WG. The draft has the >>>>>> following goals and requirements: >>>>>>=20 >>>>>> - The goal is to define PMIPv6 extensions that allow to move flows >>>>>> among different simultaneously attaches interfaces of an MN. >>>>>>=20 >>>>>> - Analyze the different scenarios to be supported. We currently inc= lude >>>>>> the "shared prefix" and "unique prefix" per physical interface mod= els. >>>>>>=20 >>>>>> - The solution defines the LMA as the controlling entity. The solut= ion >>>>>> defines the signaling between MAG and LMA. The specifics on how the >>>>>> network nodes obtain the policies is out of scope. >>>>>>=20 >>>>>> - The MN is equipped with one logical interface (we don't support f= low >>>>>> mobility across different logical interfaces). >>>>>>=20 >>>>>> We are currently working out the details and reaching an agreement >>>>>> among the authors of the draft. As soon as we come up with a >>>>>> consolidated document (hopefully within the next couple of weeks) w= e'll >>>>>> submit it and ask for feedback to the WG. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Carlos >>>>>>=20 >>>>>> -- >>>>>> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net >>>>>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >=20 >=20 >=20 From xiayangsong@huawei.com Tue Oct 12 15:30:17 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291663A6AA2 for ; Tue, 12 Oct 2010 15:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.405 X-Spam-Level: X-Spam-Status: No, score=0.405 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_51=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD6VB8LHavj1 for ; Tue, 12 Oct 2010 15:30:12 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7159F3A6A22 for ; Tue, 12 Oct 2010 15:30:12 -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 <0LA7009CH7W5D7@szxga03-in.huawei.com> for netext@ietf.org; Wed, 13 Oct 2010 06:31:17 +0800 (CST) Received: from 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 <0LA700AV47W5QE@szxga03-in.huawei.com> for netext@ietf.org; Wed, 13 Oct 2010 06:31:17 +0800 (CST) Received: from X24512z ([10.193.34.200]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA700K627W2LS@szxml06-in.huawei.com> for netext@ietf.org; Wed, 13 Oct 2010 06:31:17 +0800 (CST) Date: Tue, 12 Oct 2010 15:31:13 -0700 From: Frank Xia In-reply-to: To: 'Sri Gundavelli' , 'Behcet Sarikaya' Message-id: <009001cb6a5d$2f023e10$c822c10a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: ActqV236NJy25nyrOkewaZUC94VZbQABQk0g References: <770597.23926.qm@web111414.mail.gq1.yahoo.com> Cc: netext@ietf.org Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 22:30:17 -0000 Hi Sri Do you mean different prefixes for different flows ( or applications )? I recalled I had some discussion with Mohana in the mailing list regarding this assumption. BR Frank -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Sri Gundavelli Sent: Tuesday, October 12, 2010 2:50 PM To: Behcet Sarikaya Cc: netext@ietf.org Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob YOUTUBE: Flow-1: src: cafe::1, dest: babe::1, sport=3Dx, dport=3Dz = APN:INTERNET PANDORA: Flow-2: src: cafe::1, dest: dead::1, sport=3Dy, dport=3Dw = APN:INTERNET SIP: Flow-3: src: face::1, dest: cead::1, sport=3Da, dport=3Db = APN:IMS VPN: Flow-4: src: face::1, dest: deaf::1, sport=3Dd, dport=3Dc = APN:ENT Flow Groups: 1. (Flow-1, Flow-2)---> CAFE::/64 2. (Flow-3, Flow-4)---> FACE::/64 Move Flow Group#1, by moving prefix CAFE::/64, as an aggregate. That's = your flow group description. RA with the PIO Option (CAFE::1/64) on the new = link, avoid split link. Sri =20 On 10/12/10 2:09 PM, "Behcet Sarikaya" wrote: > Hi Sri, > How does a prefix become a flow description? >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > ----- Original Message ---- >> From: Sri Gundavelli >> To: Sri Gundavelli ; cjbc@it.uc3m.es; "Laganier, Julien" >> >> Cc: "netext@ietf.org" >> Sent: Tue, October 12, 2010 2:56:36 PM >> Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob >>=20 >> Also, I'd like to remind, the use-cases for flow mobility is not like = in >> Hollywood action movies. Flow-1 comes on interface-1, network = triggers it >> dynamically to move the flow to interface-2, the third second, while = the MN >> is still connected to the same set of interfaces, the network tells = the MN >> to move the flow back to Interface-1, because it saw another traffic >> intensive flow from another MN. So, it pushes the policy to the MN, = it also >> triggers the MAG, which it cant do a thing about it in the absence of MN-AR >> triggers, but it gets the policy for the heck of it. I don't = believe any >> operator deployments are looking at this level of complexity. Lets = be >> realistic in the the scenarios and solutions. >>=20 >> IMO, Most operators are looking at simple policies, such as: >>=20 >> - When in the presence of WLAN, move certain type of traffic flows = to WLAN, >> keep my essential flows related to operator value added services to = the >> macro network. >> - Offload most non essential traffic over WLAN, don't bring it back = to EPC. >>=20 >> To solve this, I need the simple ability to move a set of flows, as = a group, >> I can manage them at the granularity of a prefix level/APN level. I don't >> have to exchange complex flow templates. As part of the address assignment >> procedures, the LMA can give the set of prefixes, which the MAG can = host on >> the link, that's all I need. I do not require complex policies on = the MN, it >> knows when a prefix is on a given link and when it is not, by virtue = of >> RA's, I don't require complex logic on the UE. >>=20 >> Any thing more beyond this is a bonus feature addition and that is = fine with >> me, we can keep ourselves busy. If any one wants to challenge me, I = want to >> hear first on some practical and realistic operator input on the = most common >> scenarios that they are interested in. So, lets take an incremental >> approach, lets not overload this document with every possible = scenario, on >> day-1. >>=20 >>=20 >>=20 >> Sri >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 10/12/10 12:34 PM, "Sri Gundavelli" wrote: >>=20 >>> Adding to what Carlos said. >>>=20 >>>=20 >>> On 10/12/10 9:46 AM, "Carlos Jes=FAs Bernardos Cano" = wrote: >>>=20 >>>> At this stage we are just "analyzing the different scenarios to be >>>> supported". This does not necessarily mean that at the end we aim = at >>>> supporting all. Anyway, I think it is in general better not to = limit to >>>> a single scenario (which is different from current PMIPv6 model), unless >>>> there is no (or few) people that want it to be supported (so far = some >>>> people stated that the "unique prefix" per physical interface is useful >>>> and needs to be covered) and considering it adds too much = complexity to >>>> the solution. >>>=20 >>> I'm not sure, if supporting prefixes per-interfaces is complex, or >>> supporting a single prefix across access networks is complex. One = way to >>> look at it is, this is the default behavior of the base = specification, the >>> ability to allocate a unique prefix per-interface, the natural multi-homing >>> behavior as per RFC-5213. Now, when we support flow-mobility, that = is not >>> taking away this basic capability from the specification, we will continue >>> to support that. Additionally, if we look at this from the = perspective of a >>> logical interface, we are truly hosting a set of prefixes for a = given >>> interface which is the virtual/logical interface, for the same = reason as >>> when we have added multiple prefix support to the base spec for resolving >>> the IESG Discuss, "retain support for the basic IPv6 link property, ability >>> to host multiple prefixes on a given link". >>>=20 >>> The ability to allocate prefixes per-interface, will also give the ability >>> to move that entire prefix as a flow aggregate between interfaces. = A prefix >>> which was advertised on interface-1, can simply be hosted on interface-2, >>> with the resulting affect of flow group movement between = interfaces. This >>> approach offers the natural ability for the network node to hint = the >>> presence of a new prefix simply by sending a RA, with the new PIO option. >>> There is a natural MN-AR trigger, in the form of RA's. The MN has a clear >>> visibility on the hosted prefixes at a physical interface level and hence >>> the forwarding capability. A prefix on interface-1, or on = interface-2 is >>> implicit by the RA hints. >>>=20 >>> This approach allows a simply flow mobility approach for = deployments to >>> categorize flows based on APN's and move all the flows associated = to an > APN >>> from interface-1 to interface-2. A policy which states, all these = flows >>> bound this APN, when in the presence of WLAN interface, use that interface. >>>=20 >>> Additionally, we can provide more granular approach, at a flow = level, but > at >>> the risk of lack of MN-AR hints and some assumptions. Ignoring the split >>> link issues, we can have a layer-2 based policy which states, any = time the >>> MN see's a WLAN interface, flow-1, flow-2, flow-3 move it on to = that WLAN >>> interface, irrespective of the source prefix, we can move the flow across. >>> The MN can assume, the network has the same forwarding state as the = MN, the >>> MN has the understanding to differentiate between the various = states of > that >>> WLAN interface, if there is a MAG on the WLAN link, or if access security >>> matters, DHCP state matters, when to start forwarding packets, = after the > L2 >>> attach, after the address configuration and after access authentication, in >>> the absence of any MN-AR hints, sure this can work with some hard >>> assumptions. All of this in comparison to the natural multi-homing behavior >>> per 5213. >>>=20 >>> So, we will document both and we can discuss what is complex and = see the > way >>> forward. >>>=20 >>>=20 >>>=20 >>> Sri >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Besides, as a side note (as individual, not as editor of >>>> draft-bernardos-netext-pmipv6-flowmob), I think that even though = we are >>>> now assuming the MN implements the logical interface, if we do not limit >>>> too much the scenario, the extensions that we develop on the = network >>>> side could also work for MNs that do not support the logical = interface >>>> but "flow mobility" in general. >>>>=20 >>>> Thanks, >>>>=20 >>>> Carlos >>>>=20 >>>>>=20 >>>>> - Up to version -06 of the PMIPv6 draft it is said that a given mobile >>>>> node is allocated a unique set of prefix, that is either stored = in the >>>>> mobile node's policy profile, or dynamically assigned by the = local >>>>> mobility anchor. >>>>>=20 >>>>> - This is changed starting with version -07 with the additional >>>>> requirement that "the local mobility anchor MUST allocate a = unique >>>>> home network prefix for each of the connected interfaces." The >>>>> departure from the earlier addressing model is justified because = it is >>>>> only way to avoid breaking unmodified hosts which would not = support >>>>> having the same prefix assigned simultaneously on the same = interface. >>>>>=20 >>>>> - The "unique prefix per interface" requirement is no longer justified >>>>> for flow mobility work because all the work we're doing, while = stile >>>>> assuming an unmodified IP layer on the mobile nodes, also assumes that >>>>> a logical interfaces hides the multiple physical interfaces. Thus >>>>> assigning a single prefix set to the mobile node, independently = of >>>>> number of physical interfaces does not risk breaking the IP = layer. >>>>> Additionally, because when flow mobility is in use, packets are >>>>> required to be routed on a per-flow basis and no longer based on = a >>>>> longest prefix match between routing table entries and packet >>>>> destination IP address, flow mobility cannot be used to justify = the >>>>> need for per-interface prefix. >>>>>=20 >>>>> --julien >>>>>=20 >>>>> Carlos Jes=FAs Bernardos Cano wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Julien and Raj suggested that people working on flow mobility solutions >>>>>> posted a summary of the requirements of goals of their ongoing work. >>>>>>=20 >>>>>> Authors of draft-bernardos-netext-pmipv6-flowmob are working on = the >>>>>> next revision for the consideration of the WG. The draft has = the >>>>>> following goals and requirements: >>>>>>=20 >>>>>> - The goal is to define PMIPv6 extensions that allow to move = flows >>>>>> among different simultaneously attaches interfaces of an MN. >>>>>>=20 >>>>>> - Analyze the different scenarios to be supported. We currently include >>>>>> the "shared prefix" and "unique prefix" per physical interface models. >>>>>>=20 >>>>>> - The solution defines the LMA as the controlling entity. The solution >>>>>> defines the signaling between MAG and LMA. The specifics on how = the >>>>>> network nodes obtain the policies is out of scope. >>>>>>=20 >>>>>> - The MN is equipped with one logical interface (we don't = support flow >>>>>> mobility across different logical interfaces). >>>>>>=20 >>>>>> We are currently working out the details and reaching an = agreement >>>>>> among the authors of the draft. As soon as we come up with a >>>>>> consolidated document (hopefully within the next couple of = weeks) we'll >>>>>> submit it and ask for feedback to the WG. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Carlos >>>>>>=20 >>>>>> -- >>>>>> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net >>>>>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>=20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 >=20 >=20 >=20 _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From julienl@qualcomm.com Fri Oct 15 10:40:04 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6ADB3A6B8F for ; Fri, 15 Oct 2010 10:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St4+7lZKsYA6 for ; Fri, 15 Oct 2010 10:40:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 570203A6B77 for ; Fri, 15 Oct 2010 10:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287164483; x=1318700483; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Sri=20Gundavelli=20,=20"cjbc@i t.uc3m.es"=20|CC:=20"netext@ietf.org"=20 |Date:=20Fri,=2015=20Oct=202010=2010:41: 15=20-0700|Subject:=20RE:=20[netext]=20About=20draft-bern ardos-netext-pmipv6-flowmob|Thread-Topic:=20[netext]=20Ab out=20draft-bernardos-netext-pmipv6-flowmob|Thread-Index: =20ActqRHVkfboLTf8eWki4McO2n1zEowCSAPSA|Message-ID:=20|References:=20<1286901985.6959.217.camel@aco rde.it.uc3m.es>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=uJKjT6tEm6uw53tSml+MZ8jhkQqeflxuLh5ZX61hN5U=; b=CEGdxz2F/O1+bsqntHIg8sBGcuuqqcNMc1EM1QFJgbK8Nh5xkqnnGCDt H72n5kYpdzrtVvGftd7CdmVsT3Rq8+L11Y3++msn1RGZOoXReh8Z3MqBn o8wU9wMXlYmW/geL+tioNY65z1rDF+d4kElUYNVhuIBGZeRCIoDlR1WBO E=; X-IronPort-AV: E=McAfee;i="5400,1158,6137"; a="57982736" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 15 Oct 2010 10:41:22 -0700 X-IronPort-AV: E=Sophos;i="4.57,337,1283756400"; d="scan'208";a="20318311" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Oct 2010 10:41:21 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 15 Oct 2010 10:41:21 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 15 Oct 2010 10:41:21 -0700 From: "Laganier, Julien" To: Sri Gundavelli , "cjbc@it.uc3m.es" Date: Fri, 15 Oct 2010 10:41:15 -0700 Thread-Topic: [netext] About draft-bernardos-netext-pmipv6-flowmob Thread-Index: ActqRHVkfboLTf8eWki4McO2n1zEowCSAPSA Message-ID: References: <1286901985.6959.217.camel@acorde.it.uc3m.es> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] About draft-bernardos-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 17:40:04 -0000 Sri, Carlos, Please see some thoughts below: Sri Gundavelli wrote: >=20 > Adding to what Carlos said. >=20 >=20 > On 10/12/10 9:46 AM, "Carlos Jes=FAs Bernardos Cano" > wrote: >=20 > > At this stage we are just "analyzing the different scenarios to be > > supported". This does not necessarily mean that at the end we aim at > > supporting all. Anyway, I think it is in general better not to limit to > > a single scenario (which is different from current PMIPv6 model), unles= s > > there is no (or few) people that want it to be supported (so far some > > people stated that the "unique prefix" per physical interface is useful > > and needs to be covered) and considering it adds too much complexity > > to the solution. >=20 > I'm not sure, if supporting prefixes per-interfaces is complex, or > supporting a single prefix across access networks is complex. One way > to look at it is, this is the default behavior of the base specification, > the ability to allocate a unique prefix per-interface, the natural multi- > homing behavior as per RFC-5213. Detailing what RFC 5213 provides us with: - ability to create and tore down a PMIPv6 session that comprises a common = set of prefixes - a PMIPv6 session can be brought up when a new interface is brought up (HI= set to 1) - a PMIPv6 session can be moved across interface (HI set to 2) - a PMIPv6 session can be moved between MAG for same interface (HI set to 3= ) > Now, when we support flow-mobility, that is > not taking away this basic capability from the specification, we will > continue to support that.=20 I think we're in agreement: The per-interface prefixes set scenario is alre= ady supported in RFC 5213, thus we do not need to provide a new mechanism f= or this within the flow mobility extensions. The only requirement is that w= e do not break working features of RFC 5213 while extending it (which is ki= nd of obvious.) Thus, flow-mobility extension wise, the only thing we need to be concerned = with are: - ability to tie a PMIPv6 session (with a common set of prefixes) to a logi= cal interface hiding one or more physical interfaces - ability to move flows anchored to a PMIPv6 session (and thus to its set o= f prefixes) across the physical interface below the logical interface.=20 As a result, what we have a model with one or more PMIPv6 sessions, each of= them being valid over a subset of the MN physical interfaces (which are hi= den by a logical interface on the MN side.) The fact that some prefixes are= only valid on a per-interface prefix is just a special case within that mo= del. =20 > Additionally, if we look at this from the perspec= tive > of a logical interface, we are truly hosting a set of prefixes for a give= n > interface which is the virtual/logical interface, for the same reason > as when we have added multiple prefix support to the base spec for > resolving the IESG Discuss, "retain support for the basic IPv6 link prope= rty, > ability to host multiple prefixes on a given link". This is aligned with what I wrote above: We are hosting PMIPv6 sessions tha= t correspond to set of prefixes, over logical interfaces, which in turn cor= responds to one or more physical interfaces. =20 > The ability to allocate prefixes per-interface, will also give the > ability to move that entire prefix as a flow aggregate between interfaces= .=20 I'd rather say "the ability to allocate PMIPv6 sessions on a per-interface = basis". This is a special case that is supported with the model we're discu= ssing. > A prefix which was advertised on interface-1, can simply be hosted on int= erface- > 2, with the resulting affect of flow group movement between interfaces. > This approach offers the natural ability for the network node to hint the > presence of a new prefix simply by sending a RA, with the new PIO > option. There is a natural MN-AR trigger, in the form of RA's. The MN has= a > clear visibility on the hosted prefixes at a physical interface level and > hence the forwarding capability. A prefix on interface-1, or on interface= -2 > is implicit by the RA hints. I am not sure I am following you with the notion of RA trigger.=20 In my opinion the RA are something that we shouldn't be concerned with in t= he context of the PMIPv6 protocol extensions. The only thing we have to do = is to document how the logical interface makes sure that the unmodified IP = stack on top of it functions properly and does not enter new failure modes = due to the extensions we're building. =20 > This approach allows a simply flow mobility approach for deployments to > categorize flows based on APN's and move all the flows associated to an > APN from interface-1 to interface-2. A policy which states, all these flo= ws > bound this APN, when in the presence of WLAN interface, use that > interface. Yup. But this APN-based routing is something that is out-of-scope of this W= G and has to be dealt with in 3GPP. =20 > Additionally, we can provide more granular approach, at a flow level, > but at the risk of lack of MN-AR hints and some assumptions. Ignoring the > split link issues, we can have a layer-2 based policy which states, any t= ime > the MN see's a WLAN interface, flow-1, flow-2, flow-3 move it on to that > WLAN interface, irrespective of the source prefix, we can move the flow > across. The MN can assume, the network has the same forwarding state as t= he MN, > the MN has the understanding to differentiate between the various states = of > that WLAN interface, if there is a MAG on the WLAN link, or if access > security matters, DHCP state matters, when to start forwarding packets, a= fter > the L2 attach, after the address configuration and after access authentic= ation, > in the absence of any MN-AR hints, sure this can work with some hard > assumptions. All of this in comparison to the natural multi-homing > behavior per 5213. >=20 > So, we will document both and we can discuss what is complex and see > the way forward. This discussion on the flow mobility model seems productive... --julien=20 From maxpassion@gmail.com Tue Oct 19 01:13:39 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF523A6C24 for ; Tue, 19 Oct 2010 01:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUPjCGbeSXAw for ; Tue, 19 Oct 2010 01:13:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D4E623A6C4D for ; Tue, 19 Oct 2010 01:13:38 -0700 (PDT) Received: by vws12 with SMTP id 12so1140013vws.31 for ; Tue, 19 Oct 2010 01:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TnsGJNVnA/6YI9x2dVdnAPetbrgvouJrO+OD2prume8=; b=QQiM3iNa5kwFU1I+rWvxut7AyPUe6kYb8cWnEL++D9Stz6E7LvN3JSSq+Ibx/65H8L kCIZphbTz+2ZWrBao8Bg2nxeoOgUt0P+j2yoK053Wlfd71ceXgueY5aLaxjAgxzA0s4r rIE2SIBc5lU7xsWy7M+5jnmvyxaqJ0I/WpiUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=iUgfhJDfgGhCMOrEpV4GJnTJelib2jb6cT366WNb/dB1BCgyvVmg9SgYYiGSlL1CzZ +NcbTh3D2EQqVSAnsFcyURsepJMvDgfwcDaz/Uv/ZEKwUat8tLXqQkm9L2JqSissAGPA I5MZAmDkBsfNWvQ9pfJHmcSgJnL6HEX+Z412Q= MIME-Version: 1.0 Received: by 10.220.199.193 with SMTP id et1mr1546735vcb.56.1287476108689; Tue, 19 Oct 2010 01:15:08 -0700 (PDT) Received: by 10.220.10.211 with HTTP; Tue, 19 Oct 2010 01:15:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Oct 2010 16:15:08 +0800 Message-ID: From: liu dapeng To: "netext@ietf.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [netext] Fwd: DMM problem statement and scenario draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 08:13:39 -0000 ---------- Forwarded message ---------- From: liu dapeng Date: Tue, 19 Oct 2010 16:12:30 +0800 Subject: DMM problem statement and scenario draft To: dmm Cc: "charles.perkins" , yokota , MELIA TELEMACO , Wassim Haddad , Anthony Chan , "elena.demaria" , denghui02 , caozhen Hello all, After several weeks and many contributor's hard working, we finished DMM problem statement and scenario draft: http://tools.ietf.org/html/draft-chan-distributed-mobility-ps-00 http://tools.ietf.org/html/draft-yokota-dmm-scenario-00 Besides, we have the following introduction and initial work plan of DMM: ---------------------------------------------------------------------------= -------------------------- Work plan proposal -- Distributed and Dynamic Mobility Management =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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: =95presence of a centralized mobility anchor providing global reachability and an always-on experience =95extensions to optimize handover performance while users roam across wireless cells =95extensions 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 capactity, 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 [1] 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: =95Define the problem statement and associated requirements for distributed mobility management. This work aims at defining the problem space and identifies the key functional requirements. =95Produce a gap analysis mapping the above requirements against existing solutions. =95Give best practices for the deployment of existing mobility protocols in a distributed mobility management and describe limitations of each such approach. =95Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures [1] G. Kirby, "Locating the User", Communication International, 1995 ---------------------------------------------------------------------------= ------------------------- Please feel free to comment. Thanks. Best Regards, Dapeng Liu From sijeon79@gmail.com Tue Oct 19 20:07:11 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EE23A6998 for ; Tue, 19 Oct 2010 20:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-rIbGZMqEpH for ; Tue, 19 Oct 2010 20:07:10 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id A4E833A6997 for ; Tue, 19 Oct 2010 20:07:10 -0700 (PDT) Received: by pxi9 with SMTP id 9so613840pxi.31 for ; Tue, 19 Oct 2010 20:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:subject:date :organization:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:x-mimeole; bh=Pejl+pd+n+T69A2OCbOwc87MO+tIMtLIMJwv0BYXf4g=; b=wKJTA5y7RQTw4XXVSmbEgCnEbb3I4SPv75qHvTeEGEROAJsiBQhAYv0rdi4xIbEEJe pCRjnj9HrYt95Z0RPqdveu+/0YUsLj+UPxPEuywMfPhvkaASFvgS6MLWvh4btdUrJmqJ wqkt0lQHkaVYjw1C+owVkhpglWem3aOChvsWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :x-mimeole; b=freIBUo2LWirfcuXjKMSeeBw9btXVGBw2bcbxz6JMvKe+3lidVfuOKAL/C6tDlQbCr o84wmWIJXMRmyZ81JaleaBDybnp5Koc/pAjUjy062oKa3m3ehzNcrcwzMaFcd/GH2U+K Y6LSkOx56IIhkHrCCyCP51GBIlAyyziEEvQ6o= Received: by 10.142.253.18 with SMTP id a18mr5410213wfi.110.1287544121733; Tue, 19 Oct 2010 20:08:41 -0700 (PDT) Received: from kjwkor ([220.149.84.225]) by mx.google.com with ESMTPS id v19sm24608799wfh.0.2010.10.19.20.08.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Oct 2010 20:08:41 -0700 (PDT) From: "Seil Jeon" To: Date: Wed, 20 Oct 2010 12:09:15 +0900 Organization: dcn Message-ID: <79C8E926D5AA4E6DBC0E0FD9E36A9ABC@kjwkor> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acts6svy4utL1l78S+WyChQH9UnwOQAAN8IgAMYdpCA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: [netext] FW: Manual Post Requested for draft-sijeon-mext-nemo-pmip6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 03:07:11 -0000 Hi, netext folks, Regards, Seil Jeon -----Original Message----- From: Seil Jeon [mailto:sijeon79@gmail.com] Sent: Saturday, October 16, 2010 1:44 PM To: 'mext@ietf.org' Cc: 'netlmm@ietf.org' Subject: FW: Manual Post Requested for draft-sijeon-mext-nemo-pmip6 Hi, mext folks, We just submitted NEMO-enabled PMIPv6 solution by employing proxy router. We actively welcome a variety of opinions. Regards, Seil Jeon -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Saturday, October 16, 2010 1:29 PM To: internet-drafts@ietf.org Cc: sijeon@dcn.ssu.ac.kr; younghak@ssu.ac.kr; jwjang84@dcn.ssu.ac.kr Subject: Manual Post Requested for draft-sijeon-mext-nemo-pmip6 Manual Posting Requested for following Internet-Draft: I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=27192 Filename: draft-sijeon-mext-nemo-pmip6 Version: 00 Staging URL: http://www.ietf.org/staging/draft-sijeon-mext-nemo-pmip6- 00.txt Title: Network Mobility Support in the Proxy Mobile IPv6 Domain Creation_date: 2010-10-16 WG ID: Individual Submission Number_of_pages: 15 Abstract: Network mobility (NEMO) enables all the nodes within a mobile network to provide session continuity without requiring their involvement when the mobile network moves. To provide NEMO support, the NEMO basic support protocol (NEMO-BSP) is specified in [RFC 3963]. With the advances of the network-based mobility management protocol referred to as Proxy Mobile IPv6 (PMIPv6), interest in applicable NEMO support in the PMIPv6 domain is increasing however, the standard PMIPv6, defined in [RFC 5213], handles only a single mobile node. This document presents a NEMO-enabled PMIPv6 using a Proxy Router (PR) rather than the MR defined in [RFC 3963] and describes detailed operations for network/node mobility support in the PMIPv6 domain. Submitter: Seil Jeon (sijeon@dcn.ssu.ac.kr) Author(s): Seil Jeon, sijeon@dcn.ssu.ac.kr Young-Han Kim, younghak@ssu.ac.kr Jiwon Jang, jwjang84@dcn.ssu.ac.kr From root@core3.amsl.com Wed Oct 20 13:30:23 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F2CD73A6947; Wed, 20 Oct 2010 13:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101020203015.F2CD73A6947@core3.amsl.com> Date: Wed, 20 Oct 2010 13:30:02 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip-lr-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:30:23 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Localized Routing for Proxy Mobile IPv6 Author(s) : S. Krishnan, et al. Filename : draft-ietf-netext-pmip-lr-01.txt Pages : 25 Date : 2010-10-20 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing(LR) allows mobile nodes attached to the same or different mobile access gateways to exchange traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes an initiation mechanism for localized routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-pmip-lr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20132058.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 09:15:25 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 559F53A6AB5; Mon, 25 Oct 2010 09:15:20 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025161522.559F53A6AB5@core3.amsl.com> Date: Mon, 25 Oct 2010 09:15:21 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-logical-interface-support-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:15:25 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Logical Interface Support for multi-mode IP Hosts Author(s) : T. Melia, S. Gundavelli Filename : draft-ietf-netext-logical-interface-support-01.txt Pages : 23 Date : 2010-10-25 A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is desirable on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-support-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-logical-interface-support-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25090350.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 10:45:03 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B4A943A6ACE; Mon, 25 Oct 2010 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025174502.B4A943A6ACE@core3.amsl.com> Date: Mon, 25 Oct 2010 10:45:02 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-bulk-re-registration-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Bulk Re-registration for Proxy Mobile IPv6 Author(s) : F. Abinader, et al. Filename : draft-ietf-netext-bulk-re-registration-02.txt Pages : 20 Date : 2010-10-25 Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This document also specifies a new mobility option that can be used by the mobility entities in a Proxy Mobile IPv6 domain for carrying the group affiliation of a mobile node in any of the mobility signaling messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-bulk-re-registration-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25103933.I-D@ietf.org> --NextPart-- From ext-fuad.junior@nokia.com Mon Oct 25 10:53:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66AB3A67EB for ; Mon, 25 Oct 2010 10:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6obgdZVJOZJ for ; Mon, 25 Oct 2010 10:53:35 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3A44F3A67F9 for ; Mon, 25 Oct 2010 10:53:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o9PHtEIu017248; Mon, 25 Oct 2010 20:55:16 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 20:55:14 +0300 Received: from mzebe101.NOE.Nokia.com ([172.18.252.71]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 20:55:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2010 14:54:49 -0300 Message-ID: In-Reply-To: <012501cb3d13$763db6a0$80106f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext]Review/feedback on draft-ietf-netext-bulk-re-registration Thread-Index: Acs9E6z3Ej7gbctuQ7GMsHUfBRCXDQ3Wb0Jg References: <4C67D69A.6060701@kddilabs.jp><007601cb3ce0$10417fe0$80106f0a@china.huawei.com><4C68DD01.1040405@kddilabs.jp> <012501cb3d13$763db6a0$80106f0a@china.huawei.com> From: To: X-OriginalArrivalTime: 25 Oct 2010 17:55:14.0038 (UTC) FILETIME=[C67AB960:01CB746D] X-Nokia-AV: Clean Cc: Xiangsong.Cui@huawei.com Subject: Re: [netext] Review/feedback on draft-ietf-netext-bulk-re-registration X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:53:36 -0000 Hi Hidetoshi and Xiangsong, I've just uploaded a new version of the I-D which tries to accommodate your suggestions. Please feel free to comment back. Regards, Fuad Abinader >-----Original Message----- >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]=20 >On Behalf Of ext Xiangsong Cui >Sent: segunda-feira, 16 de agosto de 2010 03:20 >To: Hidetoshi Yokota >Cc: netext@ietf.org >Subject: Re: [netext]Review/feedback on=20 >draft-ietf-netext-bulk-re-registration > >Hi Hidetoshi, > >My suggestion is also to expand the status code. > >Thanks and regards, >Xiangsong > >----- Original Message ----- >From: "Hidetoshi Yokota" >To: "Xiangsong Cui" >Cc: >Sent: Monday, August 16, 2010 2:38 PM >Subject: Re: [netext] Review/feedback on=20 >draft-ietf-netext-bulk-re-registration > > >> Hi Xiangsong and Fuad, >>=20 >> (2010/08/16 10:12), Xiangsong Cui wrote: >>> Hi Hidetoshi, >>>=20 >>> ----- Original Message ----- From: "Hidetoshi Yokota"=20 > >>> To: >>> Sent: Sunday, August 15, 2010 7:59 PM >>> Subject: Re: [netext] Review/feedback on=20 >>> draft-ietf-netext-bulk-re-registration >>>=20 >>>=20 >>>> Hello Fuad, >>>> >>>> I reviewed the latest draft (-01). Good work, but still needs more >>>> clarifications. >>>> >>>> After reading this document, I found that there are four=20 >operations that >>>> this spec could cover (hope this is correct): >>>> >>>> (1) ADD operation >>>> (2) REMOVE operation >>>> (3) BULK_REREGISTRATION operation >>>> (4) BULK_REVOCATION operation >>>> >>>=20 >>> I just want to make sure, how many operations are there in=20 >the document, >>=20 >> As far as I read the draft, I think there are four=20 >operations like the >> above. >>=20 >>> As I said in my earlier review/feedback on this draft, I=20 >think a PBU=20 >>> message with B flag is set, not only represents the adding-to-group=20 >>> request, but also represents the individual registration=20 >request. This=20 >>> means the LMA may take >>> the MN's registration separately and doesn't add this MN to=20 >any group.=20 >>> (Accepting the individual registration request and=20 >rejecting the adding=20 >>> request) >>=20 >> I think this could happen. >>=20 >>> On the other hand, shall we allow the MAG remove one MN=20 >from the group >>> registration to individual registration (keep the MN=20 >registered without=20 >>> interrupt)? >>=20 >> At least, the MAG can request to remove by setting B=3D0 in=20 >the PBU. But I >> don't know how the LMA can decline it because if B flag in the PBU is >> set to 0, that flag in the PBA cannot be set to 1 according=20 >to Section >> 4.2. I think a new status code should be defined for this=20 >case. Or, the >> LMA blindly accepts this request... >>=20 >>> In my impression, the operations in this document may contain: >>>=20 >>> MAG LMA >>> (1) Add (PBU with B flag, lifetiem > 0) 1.1 accept individual=20 >>> registration, but reject group >>=20 >> In this case, the LMA returns PBA(B=3D0, lifetime >0) >>=20 >>> (1) Add (PBU with B flag, lifetime > 0) 1.2 accept individual=20 >>> registration and add to group >>=20 >> In this case, the LMA returns PBA(B=3D1, lifetime >0) >>=20 >>> (2.1) remove from the group (PBU without B flag, lifetime > 0) 2.1=20 >>> accept/reject >>=20 >> For the accept case, the LMA returns PBA(B=3D0, lifetime >0),=20 >but I don't >> know how to reject it... >>=20 >>> (2.2) remove and de-registration (PBU with B flag, lifetime=20 >=3D 0) 2.2=20 >>> accept/reject >>=20 >> I think the MAG has to set B to 0 for requesting removal, so=20 >my take is >> to send PBU (B=3D0, lifetime =3D0). >>=20 >>> PS: I believe we needn't the operation of MN individual=20 >de-redistration=20 >>> without removing it out of group >>=20 >> Agree. >>=20 >> I think there is still some ambiguity in the draft. A bit more >> clarification could resolve this kind of confusions. >>=20 >> Regards, >> --=20 >> Hidetoshi >>=20 >>> (3) and (4), I agree. >>>=20 >>> Regards, >>> Xiangsong >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext > From Xiangsong.Cui@huawei.com Mon Oct 25 19:46:55 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F0C3A680D for ; Mon, 25 Oct 2010 19:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUM4BkyAllLY for ; Mon, 25 Oct 2010 19:46:53 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7C1773A6C41 for ; Mon, 25 Oct 2010 19:46:53 -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 <0LAV00LQEMF7MI@szxga05-in.huawei.com> for netext@ietf.org; Tue, 26 Oct 2010 10:47:31 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAV0000YMF5Y6@szxga05-in.huawei.com> for netext@ietf.org; Tue, 26 Oct 2010 10:47:31 +0800 (CST) Date: Tue, 26 Oct 2010 10:47:29 +0800 From: Xiangsong Cui In-reply-to: To: ext-fuad.junior@nokia.com, netext@ietf.org Message-id: <00ff01cb74b8$2258cac0$670a6040$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acs9E6z3Ej7gbctuQ7GMsHUfBRCXDQ3Wb0JgABGTC2A= References: <4C67D69A.6060701@kddilabs.jp> <007601cb3ce0$10417fe0$80106f0a@china.huawei.com> <4C68DD01.1040405@kddilabs.jp> <012501cb3d13$763db6a0$80106f0a@china.huawei.com> Subject: Re: [netext] Review/feedback on draft-ietf-netext-bulk-re-registration X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 02:46:55 -0000 Hi Fuad, Thank you for the update, I have some other comments. Section 1, In such cases the MAG or the LMA can perform the binding revocation signaling using the group ID associated with a specific set of mobile nodes. This draft mentions binding revocation, but it is different with the binding revocation mechanism defined in RFC5846. Additionally, in section 3.2.2, this draft uses 0-lifetime PBAck message to MN from group, and in section 3.2.4, this draft uses 0-lifetime PBAck to de-register the group binding. I don't understand these operations, if the PBAck is lost (I think it is very possible in IP layer), how do we guarantee the same status between LMA and MAG? (for example, if a MN is removed from the group in the LMA side, but the PBAck message is lost, and the MAG takes the MN inside the group, so the MAG doesn't separately register the MN again, and the MN would lost service.) There is no further acknowledgement to the PBAck, and the draft doesn't introduce any timer or retransmission in LMA side. Why not utilize the mechanism defined in RFC5846 here? Section 4.3, Length 8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. The value for this field MUST be set to 6 in the case where the PBU message is requesting the binding refresh, both for the situation where the Mobile Node Group Identifier specifies a single bulk registration set and for the situation where this field specifies all the MNs attached to the MAG that are members of any bulk set. The length value "MUST be set to 6 in case ...", does this imply that there is other possible length value? The mandatory options in PBU/PBA message, or maybe this is related to the group policy. RFC5213 specifies, Mobility Options - Mobile Node Identifier option (mandatory) - Home Network Prefix option(s) (mandatory) - Handoff Indicator option (mandatory) - Access Technology Type option (mandatory) In this draft, MN ID MAY be optional, this is OK, but how about other options? Handoff indicator is simple, we can use "Handoff state not changed" (or ignore it), If home network prefix option and access technology type option are still mandatory, this means we (or LMA) can not assign MNs with different prefix or access type to one group, and multiple group IDs may not be included in one PBU message. I don't mean we should keep these options mandatory, I just want to say we should claim these options more clear, to me, all of these options MAY be changed to optional. Regards, Xiangsong > -----Original Message----- > From: ext-fuad.junior@nokia.com [mailto:ext-fuad.junior@nokia.com] > Sent: Tuesday, October 26, 2010 1:55 AM > To: netext@ietf.org > Cc: yokota@kddilabs.jp; Xiangsong.Cui@huawei.com > Subject: RE: [netext]Review/feedback on draft-ietf-netext-bulk-re-registration > > Hi Hidetoshi and Xiangsong, > > I've just uploaded a new version of the I-D which tries to > accommodate your suggestions. Please feel free to comment back. > > Regards, > > Fuad Abinader > > >-----Original Message----- > >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > >On Behalf Of ext Xiangsong Cui > >Sent: segunda-feira, 16 de agosto de 2010 03:20 > >To: Hidetoshi Yokota > >Cc: netext@ietf.org > >Subject: Re: [netext]Review/feedback on > >draft-ietf-netext-bulk-re-registration > > > >Hi Hidetoshi, > > > >My suggestion is also to expand the status code. > > > >Thanks and regards, > >Xiangsong > > > >----- Original Message ----- > >From: "Hidetoshi Yokota" > >To: "Xiangsong Cui" > >Cc: > >Sent: Monday, August 16, 2010 2:38 PM > >Subject: Re: [netext] Review/feedback on > >draft-ietf-netext-bulk-re-registration > > > > > >> Hi Xiangsong and Fuad, > >> > >> (2010/08/16 10:12), Xiangsong Cui wrote: > >>> Hi Hidetoshi, > >>> > >>> ----- Original Message ----- From: "Hidetoshi Yokota" > > > >>> To: > >>> Sent: Sunday, August 15, 2010 7:59 PM > >>> Subject: Re: [netext] Review/feedback on > >>> draft-ietf-netext-bulk-re-registration > >>> > >>> > >>>> Hello Fuad, > >>>> > >>>> I reviewed the latest draft (-01). Good work, but still needs more > >>>> clarifications. > >>>> > >>>> After reading this document, I found that there are four > >operations that > >>>> this spec could cover (hope this is correct): > >>>> > >>>> (1) ADD operation > >>>> (2) REMOVE operation > >>>> (3) BULK_REREGISTRATION operation > >>>> (4) BULK_REVOCATION operation > >>>> > >>> > >>> I just want to make sure, how many operations are there in > >the document, > >> > >> As far as I read the draft, I think there are four > >operations like the > >> above. > >> > >>> As I said in my earlier review/feedback on this draft, I > >think a PBU > >>> message with B flag is set, not only represents the adding-to-group > >>> request, but also represents the individual registration > >request. This > >>> means the LMA may take > >>> the MN's registration separately and doesn't add this MN to > >any group. > >>> (Accepting the individual registration request and > >rejecting the adding > >>> request) > >> > >> I think this could happen. > >> > >>> On the other hand, shall we allow the MAG remove one MN > >from the group > >>> registration to individual registration (keep the MN > >registered without > >>> interrupt)? > >> > >> At least, the MAG can request to remove by setting B=0 in > >the PBU. But I > >> don't know how the LMA can decline it because if B flag in the PBU is > >> set to 0, that flag in the PBA cannot be set to 1 according > >to Section > >> 4.2. I think a new status code should be defined for this > >case. Or, the > >> LMA blindly accepts this request... > >> > >>> In my impression, the operations in this document may contain: > >>> > >>> MAG LMA > >>> (1) Add (PBU with B flag, lifetiem > 0) 1.1 accept individual > >>> registration, but reject group > >> > >> In this case, the LMA returns PBA(B=0, lifetime >0) > >> > >>> (1) Add (PBU with B flag, lifetime > 0) 1.2 accept individual > >>> registration and add to group > >> > >> In this case, the LMA returns PBA(B=1, lifetime >0) > >> > >>> (2.1) remove from the group (PBU without B flag, lifetime > 0) 2.1 > >>> accept/reject > >> > >> For the accept case, the LMA returns PBA(B=0, lifetime >0), > >but I don't > >> know how to reject it... > >> > >>> (2.2) remove and de-registration (PBU with B flag, lifetime > >= 0) 2.2 > >>> accept/reject > >> > >> I think the MAG has to set B to 0 for requesting removal, so > >my take is > >> to send PBU (B=0, lifetime =0). > >> > >>> PS: I believe we needn't the operation of MN individual > >de-redistration > >>> without removing it out of group > >> > >> Agree. > >> > >> I think there is still some ambiguity in the draft. A bit more > >> clarification could resolve this kind of confusions. > >> > >> Regards, > >> -- > >> Hidetoshi > >> > >>> (3) and (4), I agree. > >>> > >>> Regards, > >>> Xiangsong > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >_______________________________________________ > >netext mailing list > >netext@ietf.org > >https://www.ietf.org/mailman/listinfo/netext > > From Basavaraj.Patil@nokia.com Mon Oct 25 20:39:14 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30723A68F6 for ; Mon, 25 Oct 2010 20:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBeQ5lh22lQ8 for ; Mon, 25 Oct 2010 20:39:13 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9D5673A68EF for ; Mon, 25 Oct 2010 20:39:13 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o9Q3ev2h003427 for ; Mon, 25 Oct 2010 22:40:59 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Oct 2010 06:40:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Oct 2010 06:40:51 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 26 Oct 2010 05:40:50 +0200 From: To: Date: Tue, 26 Oct 2010 05:40:48 +0200 Thread-Topic: Draft agenda for WG meeting at IETF79 Thread-Index: Act0v5Pz9eQaTiB4YkqPLr2ZujLsRw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2010 03:40:51.0362 (UTC) FILETIME=[95F4E020:01CB74BF] X-Nokia-AV: Clean Subject: [netext] Draft agenda for WG meeting at IETF79 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 03:39:14 -0000 If I have missed your request for a slot, please send me a note. -Raj ------------------------------- Agenda (Rev 1) Network-Based Mobility Extensions WG meeting Tuesday, November 9th, 2010 1520-1700 Afternoon Session II and 1710-1810 Afternoon Session III (Emerald) -------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG status update Chairs 5 Mins 3. Logical Interface Support for multi-mode IP Hosts Telemaco Melia 15 Mins I-D: draft-ietf-netext-logical-interface-support-01 4. Proxy Mobile IPv6 Extensions to Support Flow Mobility Carlos Bernardos 25 Mins I-D: draft-bernardos-netext-pmipv6-flowmob-01 5. Flow mobility support in PMIPv6 Tran Minh Trung 20 Mins I-D: draft-trung-netext-flow-mobility-support-00 6. PMIPv6 inter-working with WiFi access authentication Marco L./Sri Gundavelli 10 Mins I-D: draft-liebsch-netext-pmip6-authiwk-00 7. Multi-access Indicator for Flow Mobility Rajeev Koodli 5 Mins I-D: draft-koodli-netext-multiaccess-indicator-00.txt 8. Next steps Chairs 5 Mins -------