From rkoodli@cisco.com Tue Jul 6 14:25:35 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 6B4F53A69F1 for ; Tue, 6 Jul 2010 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 C1Bf0X6MhQEB for ; Tue, 6 Jul 2010 14:25:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6EBD03A69DE for ; Tue, 6 Jul 2010 14:25:34 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYQAEc8M0ytJV2Z/2dsb2JhbACBQ5ZdhwRdAmsGpgmaWYUlBIN4hEKCLINq X-IronPort-AV: E=Sophos;i="4.53,548,1272844800"; d="scan'208,217";a="129315019" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2010 21:25:36 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o66LPaT4031512 for ; Tue, 6 Jul 2010 21:25:36 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jul 2010 17:24:26 -0400 Received: from 171.70.249.97 ([171.70.249.97]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Jul 2010 21:25:35 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 06 Jul 2010 14:31:51 -0700 From: Rajeev Koodli To: "netext@ietf.org" Message-ID: Thread-Topic: WG LC on draft-ietf-netext-redirect-03 Thread-Index: AcsdUqVrO8fBUqLvpkmK+HWtlsKSHg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3361271512_22673544" X-OriginalArrivalTime: 06 Jul 2010 21:24:26.0952 (UTC) FILETIME=[9CBF2480:01CB1D51] Subject: [netext] WG LC on draft-ietf-netext-redirect-03 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, 06 Jul 2010 21:25:35 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3361271512_22673544 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello folks, We would like to progress this draft. This is a three week LC on the draft. Please provide your input by July 27. Hopefully, we can discuss the input during the meeting on the 28th. Look forward to your reviews. ID URL: http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt Thanks, -Rajeev (for chairs) --B_3361271512_22673544 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable WG LC on draft-ietf-netext-redirect-03
Hello folks,

We would like to progress this draft. This is a three week LC on the draft.=
Please provide your input by July 27. Hopefully, we can discuss the input d= uring the meeting on the 28th.

Look forward to your reviews.

ID URL: = http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt

Thanks,

-Rajeev (for chairs)


  --B_3361271512_22673544-- From gsnaa.v2@163.com Wed Jul 7 20:29:49 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 B61793A6954 for ; Wed, 7 Jul 2010 20:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.205 X-Spam-Level: **** X-Spam-Status: No, score=4.205 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 qMVbJ7375-gN for ; Wed, 7 Jul 2010 20:29:48 -0700 (PDT) Received: from m50-133.163.com (m50-133.163.com [123.125.50.133]) by core3.amsl.com (Postfix) with ESMTP id 1486E3A68CB for ; Wed, 7 Jul 2010 20:29:45 -0700 (PDT) Received: from iplab-yzw (unknown [60.247.46.135]) by smtp3 (Coremail) with SMTP id DdGowKC735suRjVMpknmAA--.25513S2; Thu, 08 Jul 2010 11:29:50 +0800 (CST) Date: Thu, 8 Jul 2010 11:29:47 +0800 From: "gsnaa.v2" To: "netext" References: Message-ID: <201007081129470626009@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon273544777686_=====" X-CM-TRANSID: DdGowKC735suRjVMpknmAA--.25513S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxZr1kWF4fWrykKr48Wr4kJFb_yoW5ZrWUpF W3Kr12934kGr1DJw1xCw18u3WYv348Xa1DGrn8Xr18Aa43uFWUKa4Syr1rZFWUGryrXF4U Zr17CryUXw18XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j7739UUUUU= X-CM-SenderInfo: 5jvqttsoysqiywtou0bp/1tbiJRIIQkCeJSQETgABsp Subject: Re: [netext] netext Digest, Vol 14, Issue 1 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: Thu, 08 Jul 2010 03:29:50 -0000 This is a multi-part message in MIME format. --=====003_Dragon273544777686_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIHJlZGlyZWN0aW9uIG9mIExNQSBjYW4gZGVmaW5pdGVseSBpbXByb3ZlIHRoZSBvdmVyYWxs IHBlcmZvcm1hbmNlIG9mIHRoZSBQTUlQdjYgZG9tYWluLCBmb3IgZXhhbXBsZSBpdCBjYW4gYmFs YW5jZSB0aGUgbG9hZCBiZXR3ZWVuIExNQXMgYXMgUmFqZWV2IG1lbnRpb25lZCBpbiB0aGUgZHJh ZnQuIA0KSG93ZXZlciwgc29tZXRpbWVzIG9uZSBNQUcgbWF5IGNvbW11bmljYXRlIHdpdGggdHdv IExNQXMgYXQgdGhlIHNhbWUgdGltZSB0byBwcm92aWRlIGJldHRlciBzZXJ2aWNlIGZvciBhIE1O LiBGb3IgZXhhbXBsZSwgdGhlIGRpZmZlcmVudCBzZXNzaW9ucyBvZiB0aGUgTU4gY2FuIGJlIHNl cGFyYXRlbHkgZXN0YWJsaXNoZWQgdGhyb3VnaCB0d28gZGlmZmVyZW50IExNQXMuDQpBbHRob3Vn aCB0aGUgZHJhZnQgc3BlY2lmaWVkIHRoYXQgobBkdXJpbmcgdGhlIHJlZGlyZWN0aW9uIHByb2Nl c3MsIHRoZSByZkxNQSBNQVkgbmVlZCB0byBtYWludGFpbiBhIHRlbXBvcmFyeSBNQUctcmZMTUEt cjJMTUEgc3RhdGUgYW5kIG1heSBldmVuIGFjdCBhcyBhICJwcm94eSBNQUciIHRvIHRoZSByMkxN QaGxLiBJIHRoaW5rIHlvdSBjYW4gc2V0IGEgZmxhZyBpbiB0aGUgUmVkaXJlY3QgTW9iaWxpdHkg T3B0aW9uIHRvIGluZGljYXRlIHRoZSBNQUcgd2hldGhlciB0d28gQlVMIHNob3VsZCBiZSBtYWlu dGFpbmVkIGZvciB0aGUgTU4gb3Igb25seSBvbmUgQlVMIGNhbiBiZSBlc3RhYmxpc2hlZCBhdCB0 aGUgc2FtZSB0aW1lLiANCg0KDQoyMDEwLTA3LTA4IA0KDQoNCg0KWmhpd2VpIFlhbg0KDQoNCg0K t6K8/sjLo7ogbmV0ZXh0LXJlcXVlc3QgDQq3osvNyrG85KO6IDIwMTAtMDctMDggIDAzOjAxOjUy IA0KytW8/sjLo7ogbmV0ZXh0IA0Ks63LzaO6IA0K1vfM4qO6IG5ldGV4dCBEaWdlc3QsIFZvbCAx NCwgSXNzdWUgMSANCiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZGlnZXN0IHdpdGhvdXQg YWxsIHRoZSBpbmRpdmlkdWFsIG1lc3NhZ2UNCmF0dGFjaG1lbnRzIHlvdSB3aWxsIG5lZWQgdG8g dXBkYXRlIHlvdXIgZGlnZXN0IG9wdGlvbnMgaW4geW91ciBsaXN0DQpzdWJzY3JpcHRpb24uICBU byBkbyBzbywgZ28gdG8gDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGV4dA0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9n IGluLCBhbmQgc2V0ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyIgdG8gTUlNRS4g IFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2Vz dHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4NClNlbmQgbmV0ZXh0IG1haWxpbmcgbGlzdCBz dWJtaXNzaW9ucyB0bw0KbmV0ZXh0QGlldGYub3JnDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3Jp YmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0ZXh0DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRo IHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCm5ldGV4dC1yZXF1ZXN0QGlldGYub3JnDQpZb3Ug Y2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCm5ldGV4dC1vd25lckBp ZXRmLm9yZw0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28g aXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIG5ldGV4dCBkaWdlc3Qu Li4iDQpfX19fX19fX19fIEluZm9ybWF0aW9uIGZyb20gRVNFVCBOT0QzMiBBbnRpdmlydXMsIHZl cnNpb24gb2YgdmlydXMgc2lnbmF0dXJlIGRhdGFiYXNlIDUwOTMgKDIwMTAwNTA2KSBfX19fX19f X19fDQpUaGUgbWVzc2FnZSB3YXMgY2hlY2tlZCBieSBFU0VUIE5PRDMyIEFudGl2aXJ1cy4NCmh0 dHA6Ly93d3cuZXNldC5jb20NClRvZGF5J3MgVG9waWNzOg0KICAgMS4gV0cgTEMgb24gZHJhZnQt aWV0Zi1uZXRleHQtcmVkaXJlY3QtMDMgKFJhamVldiBLb29kbGkpDQpfX19fX19fX19fIEluZm9y bWF0aW9uIGZyb20gRVNFVCBOT0QzMiBBbnRpdmlydXMsIHZlcnNpb24gb2YgdmlydXMgc2lnbmF0 dXJlIGRhdGFiYXNlIDUwOTMgKDIwMTAwNTA2KSBfX19fX19fX19fDQpUaGUgbWVzc2FnZSB3YXMg Y2hlY2tlZCBieSBFU0VUIE5PRDMyIEFudGl2aXJ1cy4NCmh0dHA6Ly93d3cuZXNldC5jb20NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KRnJvbTogIFJhamVldiBLb29kbGkgPHJrb29kbGlAY2lzY28uY29tPg0KVG86ICAibmV0ZXh0 QGlldGYub3JnIiA8bmV0ZXh0QGlldGYub3JnPg0KU3ViamVjdDogIFtuZXRleHRdIFdHIExDIG9u IGRyYWZ0LWlldGYtbmV0ZXh0LXJlZGlyZWN0LTAzDQpEYXRlOiAgVHVlMDYgSnVsIDIwMTAgMTQ6 MzE6NTEgLTA3MDANCkhlbGxvIGZvbGtzLA0KV2Ugd291bGQgbGlrZSB0byBwcm9ncmVzcyB0aGlz IGRyYWZ0LiBUaGlzIGlzIGEgdGhyZWUgd2VlayBMQyBvbiB0aGUgZHJhZnQuDQpQbGVhc2UgcHJv dmlkZSB5b3VyIGlucHV0IGJ5IEp1bHkgMjcuIEhvcGVmdWxseSwgd2UgY2FuIGRpc2N1c3MgdGhl IGlucHV0DQpkdXJpbmcgdGhlIG1lZXRpbmcgb24gdGhlIDI4dGguDQpMb29rIGZvcndhcmQgdG8g eW91ciByZXZpZXdzLg0KSUQgVVJMOiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYt bmV0ZXh0LXJlZGlyZWN0LTAzLnR4dA0KVGhhbmtzLA0KLVJhamVldiAoZm9yIGNoYWlycykNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 ZXh0IG1haWxpbmcgbGlzdA0KbmV0ZXh0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KX19fX19fX19fXyBJbmZvcm1hdGlvbiBmcm9tIEVTRVQg Tk9EMzIgQW50aXZpcnVzLCB2ZXJzaW9uIG9mIHZpcnVzIHNpZ25hdHVyZSBkYXRhYmFzZSA1MDkz ICgyMDEwMDUwNikgX19fX19fX19fXw0KVGhlIG1lc3NhZ2Ugd2FzIGNoZWNrZWQgYnkgRVNFVCBO T0QzMiBBbnRpdmlydXMuDQpodHRwOi8vd3d3LmVzZXQuY29tDQo= --=====003_Dragon273544777686_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU5NjkiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGNvbG9yPSMwMDAwMDA+ VGhlIA0KcmVkaXJlY3Rpb24gb2YgTE1BIGNhbiBkZWZpbml0ZWx5IGltcHJvdmUgdGhlIG92ZXJh bGwgcGVyZm9ybWFuY2Ugb2YgdGhlIFBNSVB2NiANCmRvbWFpbiwgZm9yIGV4YW1wbGUgaXQgY2Fu IGJhbGFuY2UgdGhlIGxvYWQgYmV0d2VlbiBMTUFzIGFzIFJhamVldiBtZW50aW9uZWQgaW4gDQp0 aGUgZHJhZnQuIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU46IDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwMDA+SG93ZXZl ciwgc29tZXRpbWVzIG9uZSBNQUcgbWF5IGNvbW11bmljYXRlIHdpdGggdHdvIExNQXMgYXQgdGhl IA0Kc2FtZSB0aW1lIHRvIHByb3ZpZGUgYmV0dGVyIHNlcnZpY2UgZm9yIGEgTU4uIEZvciBleGFt cGxlLCB0aGUgZGlmZmVyZW50IA0Kc2Vzc2lvbnMgb2YgdGhlIE1OIGNhbiBiZSBzZXBhcmF0ZWx5 IGVzdGFibGlzaGVkIHRocm91Z2ggdHdvIGRpZmZlcmVudCANCkxNQXMuPC9GT05UPjwvU1BBTj48 L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMHB0Ij48U1BBTiBsYW5nPUVO LVVTPjxGT05UIA0KY29sb3I9IzAwMDAwMD5BbHRob3VnaCB0aGUgZHJhZnQgc3BlY2lmaWVkIHRo YXQgobBkdXJpbmcgdGhlIHJlZGlyZWN0aW9uIHByb2Nlc3MsIA0KdGhlIHJmTE1BIE1BWSBuZWVk IHRvIG1haW50YWluIGEgdGVtcG9yYXJ5IE1BRy1yZkxNQS1yMkxNQSBzdGF0ZSBhbmQgbWF5IGV2 ZW4gDQphY3QgYXMgYSAicHJveHkgTUFHIiB0byB0aGUgcjJMTUGhsS4gSSB0aGluayB5b3UgY2Fu IHNldCBhIGZsYWcgaW4gdGhlIFJlZGlyZWN0IA0KTW9iaWxpdHkgT3B0aW9uIHRvIGluZGljYXRl IHRoZSBNQUcgd2hldGhlciB0d28gQlVMIHNob3VsZCBiZSBtYWludGFpbmVkIGZvciB0aGUgDQpN TiBvciBvbmx5IG9uZSBCVUwgY2FuIGJlIGVzdGFibGlzaGVkIGF0IHRoZSBzYW1lIHRpbWUuIA0K PC9GT05UPjwvU1BBTj48L1A+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEg Y29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAxMC0wNy0wOCA8L0ZPTlQ+ PC9ESVY+PEZPTlQgDQpmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFIgc3R5 bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0KPC9GT05U Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+PFNQQU4+Wmhp d2VpIA0KWWFuPC9TUEFOPjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAw MDA4MCBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PFNUUk9ORz63orz+yMujujwvU1RST05HPiBuZXRleHQtcmVxdWVzdCANCjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPreiy83Ksbzko7o8L1NU Uk9ORz4gMjAxMC0wNy0wOCZuYnNwOyAwMzowMTo1MiANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IG5ldGV4dCA8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz6zrcvN o7o8L1NUUk9ORz4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IG5ldGV4dCBEaWdlc3QsIFZvbCAxNCwgSXNzdWUgDQox IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+IDwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPERJVj5JZiZuYnNwO3lvdSZu YnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtkaWdlc3QmbmJzcDt3aXRob3V0 Jm5ic3A7YWxsJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO21lc3NhZ2U8L0RJVj4NCjxE SVY+YXR0YWNobWVudHMmbmJzcDt5b3UmbmJzcDt3aWxsJm5ic3A7bmVlZCZuYnNwO3RvJm5ic3A7 dXBkYXRlJm5ic3A7eW91ciZuYnNwO2RpZ2VzdCZuYnNwO29wdGlvbnMmbmJzcDtpbiZuYnNwO3lv dXImbmJzcDtsaXN0PC9ESVY+DQo8RElWPnN1YnNjcmlwdGlvbi4mbmJzcDsmbmJzcDtUbyZuYnNw O2RvJm5ic3A7c28sJm5ic3A7Z28mbmJzcDt0byZuYnNwOzwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPkNsaWNrJm5ic3A7dGhlJm5ic3A7J1Vuc3Vic2NyaWJlJm5ic3A7b3Im bmJzcDtlZGl0Jm5ic3A7b3B0aW9ucycmbmJzcDtidXR0b24sJm5ic3A7bG9nJm5ic3A7aW4sJm5i c3A7YW5kJm5ic3A7c2V0Jm5ic3A7IkdldDwvRElWPg0KPERJVj5NSU1FJm5ic3A7b3ImbmJzcDtQ bGFpbiZuYnNwO1RleHQmbmJzcDtEaWdlc3RzPyImbmJzcDt0byZuYnNwO01JTUUuJm5ic3A7Jm5i c3A7WW91Jm5ic3A7Y2FuJm5ic3A7c2V0Jm5ic3A7dGhpcyZuYnNwO29wdGlvbjwvRElWPg0KPERJ Vj5nbG9iYWxseSZuYnNwO2ZvciZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO2xpc3QmbmJzcDtkaWdl c3RzJm5ic3A7eW91Jm5ic3A7cmVjZWl2ZSZuYnNwO2F0Jm5ic3A7dGhpcyZuYnNwO3BvaW50Ljwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5TZW5kJm5i c3A7bmV0ZXh0Jm5ic3A7bWFpbGluZyZuYnNwO2xpc3QmbmJzcDtzdWJtaXNzaW9ucyZuYnNwO3Rv PC9ESVY+DQo8RElWPm5ldGV4dEBpZXRmLm9yZzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VG8m bmJzcDtzdWJzY3JpYmUmbmJzcDtvciZuYnNwO3Vuc3Vic2NyaWJlJm5ic3A7dmlhJm5ic3A7dGhl Jm5ic3A7V29ybGQmbmJzcDtXaWRlJm5ic3A7V2ViLCZuYnNwO3Zpc2l0PC9ESVY+DQo8RElWPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0PC9ESVY+DQo8RElWPm9y LCZuYnNwO3ZpYSZuYnNwO2VtYWlsLCZuYnNwO3NlbmQmbmJzcDthJm5ic3A7bWVzc2FnZSZuYnNw O3dpdGgmbmJzcDtzdWJqZWN0Jm5ic3A7b3ImbmJzcDtib2R5Jm5ic3A7J2hlbHAnJm5ic3A7dG88 L0RJVj4NCjxESVY+bmV0ZXh0LXJlcXVlc3RAaWV0Zi5vcmc8L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPllvdSZuYnNwO2NhbiZuYnNwO3JlYWNoJm5ic3A7dGhlJm5ic3A7cGVyc29uJm5ic3A7bWFu YWdpbmcmbmJzcDt0aGUmbmJzcDtsaXN0Jm5ic3A7YXQ8L0RJVj4NCjxESVY+bmV0ZXh0LW93bmVy QGlldGYub3JnPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5XaGVuJm5ic3A7cmVwbHlpbmcsJm5i c3A7cGxlYXNlJm5ic3A7ZWRpdCZuYnNwO3lvdXImbmJzcDtTdWJqZWN0Jm5ic3A7bGluZSZuYnNw O3NvJm5ic3A7aXQmbmJzcDtpcyZuYnNwO21vcmUmbmJzcDtzcGVjaWZpYzwvRElWPg0KPERJVj50 aGFuJm5ic3A7IlJlOiZuYnNwO0NvbnRlbnRzJm5ic3A7b2YmbmJzcDtuZXRleHQmbmJzcDtkaWdl c3QuLi4iPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElW Pl9fX19fX19fX18mbmJzcDtJbmZvcm1hdGlvbiZuYnNwO2Zyb20mbmJzcDtFU0VUJm5ic3A7Tk9E MzImbmJzcDtBbnRpdmlydXMsJm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7dmlydXMmbmJzcDtz aWduYXR1cmUmbmJzcDtkYXRhYmFzZSZuYnNwOzUwOTMmbmJzcDsoMjAxMDA1MDYpJm5ic3A7X19f X19fX19fXzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhlJm5ic3A7bWVzc2FnZSZuYnNwO3dh cyZuYnNwO2NoZWNrZWQmbmJzcDtieSZuYnNwO0VTRVQmbmJzcDtOT0QzMiZuYnNwO0FudGl2aXJ1 cy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPmh0dHA6Ly93d3cuZXNldC5jb208L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5Ub2RheSdzJm5ic3A7VG9waWNzOjwvRElWPg0K PERJVj48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7MS4mbmJzcDtXRyZuYnNwO0xDJm5i c3A7b24mbmJzcDtkcmFmdC1pZXRmLW5ldGV4dC1yZWRpcmVjdC0wMyZuYnNwOyhSYWplZXYmbmJz cDtLb29kbGkpPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPl9fX19fX19fX18mbmJzcDtJbmZvcm1hdGlvbiZuYnNwO2Zyb20mbmJzcDtFU0VUJm5ic3A7 Tk9EMzImbmJzcDtBbnRpdmlydXMsJm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7dmlydXMmbmJz cDtzaWduYXR1cmUmbmJzcDtkYXRhYmFzZSZuYnNwOzUwOTMmbmJzcDsoMjAxMDA1MDYpJm5ic3A7 X19fX19fX19fXzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhlJm5ic3A7bWVzc2FnZSZuYnNw O3dhcyZuYnNwO2NoZWNrZWQmbmJzcDtieSZuYnNwO0VTRVQmbmJzcDtOT0QzMiZuYnNwO0FudGl2 aXJ1cy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPmh0dHA6Ly93d3cuZXNldC5jb208L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+RnJvbTombmJz cDsmbmJzcDtSYWplZXYmbmJzcDtLb29kbGkmbmJzcDsmbHQ7cmtvb2RsaUBjaXNjby5jb20mZ3Q7 PC9ESVY+DQo8RElWPlRvOiZuYnNwOyZuYnNwOyJuZXRleHRAaWV0Zi5vcmciJm5ic3A7Jmx0O25l dGV4dEBpZXRmLm9yZyZndDs8L0RJVj4NCjxESVY+U3ViamVjdDombmJzcDsmbmJzcDtbbmV0ZXh0 XSZuYnNwO1dHJm5ic3A7TEMmbmJzcDtvbiZuYnNwO2RyYWZ0LWlldGYtbmV0ZXh0LXJlZGlyZWN0 LTAzPC9ESVY+DQo8RElWPkRhdGU6Jm5ic3A7Jm5ic3A7VHVlMDYmbmJzcDtKdWwmbmJzcDsyMDEw Jm5ic3A7MTQ6MzE6NTEmbmJzcDstMDcwMDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+ DQo8RElWPkhlbGxvJm5ic3A7Zm9sa3MsPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5XZSZuYnNw O3dvdWxkJm5ic3A7bGlrZSZuYnNwO3RvJm5ic3A7cHJvZ3Jlc3MmbmJzcDt0aGlzJm5ic3A7ZHJh ZnQuJm5ic3A7VGhpcyZuYnNwO2lzJm5ic3A7YSZuYnNwO3RocmVlJm5ic3A7d2VlayZuYnNwO0xD Jm5ic3A7b24mbmJzcDt0aGUmbmJzcDtkcmFmdC48L0RJVj4NCjxESVY+UGxlYXNlJm5ic3A7cHJv dmlkZSZuYnNwO3lvdXImbmJzcDtpbnB1dCZuYnNwO2J5Jm5ic3A7SnVseSZuYnNwOzI3LiZuYnNw O0hvcGVmdWxseSwmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2Rpc2N1c3MmbmJzcDt0aGUmbmJzcDtp bnB1dDwvRElWPg0KPERJVj5kdXJpbmcmbmJzcDt0aGUmbmJzcDttZWV0aW5nJm5ic3A7b24mbmJz cDt0aGUmbmJzcDsyOHRoLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+TG9vayZuYnNwO2Zvcndh cmQmbmJzcDt0byZuYnNwO3lvdXImbmJzcDtyZXZpZXdzLjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+SUQmbmJzcDtVUkw6Jm5ic3A7aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW5l dGV4dC1yZWRpcmVjdC0wMy50eHQ8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoYW5rcyw8L0RJ Vj4NCjxESVY+PC9ESVY+DQo8RElWPi1SYWplZXYmbmJzcDsoZm9yJm5ic3A7Y2hhaXJzKTwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48L0RJ Vj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9ESVY+DQo8RElWPm5ldGV4dCZuYnNwO21haWxpbmcmbmJzcDtsaXN0 PC9ESVY+DQo8RElWPm5ldGV4dEBpZXRmLm9yZzwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj5fX19fX19fX19fJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtm cm9tJm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLCZuYnNwO3ZlcnNpb24mbmJz cDtvZiZuYnNwO3ZpcnVzJm5ic3A7c2lnbmF0dXJlJm5ic3A7ZGF0YWJhc2UmbmJzcDs1MDkzJm5i c3A7KDIwMTAwNTA2KSZuYnNwO19fX19fX19fX188L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRo ZSZuYnNwO21lc3NhZ2UmbmJzcDt3YXMmbmJzcDtjaGVja2VkJm5ic3A7YnkmbmJzcDtFU0VUJm5i c3A7Tk9EMzImbmJzcDtBbnRpdmlydXMuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5odHRwOi8v d3d3LmVzZXQuY29tPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj48L0ZPTlQ+PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon273544777686_=====-- From Xiangsong.Cui@huawei.com Wed Jul 7 20:54:32 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 053723A67B6 for ; Wed, 7 Jul 2010 20:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.108 X-Spam-Level: ** X-Spam-Status: No, score=2.108 tagged_above=-999 required=5 tests=[AWL=-2.448, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 S+WHggsoEiIs for ; Wed, 7 Jul 2010 20:54:30 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B28893A6359 for ; Wed, 7 Jul 2010 20:54:30 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5800GEF06NC2@szxga04-in.huawei.com> for netext@ietf.org; Thu, 08 Jul 2010 11:54:24 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L580082106NE5@szxga04-in.huawei.com> for netext@ietf.org; Thu, 08 Jul 2010 11:54:23 +0800 (CST) Date: Thu, 08 Jul 2010 11:54:24 +0800 From: Xiangsong Cui To: "gsnaa.v2" , netext Message-id: <00c801cb1e51$4176a570$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <201007081129470626009@163.com> Subject: Re: [netext] netext Digest, Vol 14, Issue 1 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: Thu, 08 Jul 2010 03:54:32 -0000 Hi, I think that would be very difficult. For the outgoing traffic of MN, the MAG may use traffic filter to split MN's traffic to the separate LMAs, but for the incoming traffic, how can the network entities send the packets (for different sessions) to the corresponding LMA? Regards, Xiangsong ----- Original Message ----- From: "gsnaa.v2" To: "netext" Sent: Thursday, July 08, 2010 11:29 AM Subject: Re: [netext] netext Digest, Vol 14, Issue 1 > The redirection of LMA can definitely improve the overall performance of the PMIPv6 domain, for example it can balance the load > between LMAs as Rajeev mentioned in the draft. > However, sometimes one MAG may communicate with two LMAs at the same time to provide better service for a MN. For example, the > different sessions of the MN can be separately established through two different LMAs. > Although the draft specified that “during the redirection process, the rfLMA MAY need to maintain a temporary MAG-rfLMA-r2LMA > state and may even act as a "proxy MAG" to the r2LMA”. I think you can set a flag in the Redirect Mobility Option to indicate the > MAG whether two BUL should be maintained for the MN or only one BUL can be established at the same time. > > > 2010-07-08 > > > > Zhiwei Yan > > > > 发件人： netext-request > 发送时间： 2010-07-08 03:01:52 > 收件人： netext > 抄送： > 主题： netext Digest, Vol 14, Issue 1 > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > https://www.ietf.org/mailman/listinfo/netext > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > Send netext mailing list submissions to > netext@ietf.org > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/netext > or, via email, send a message with subject or body 'help' to > netext-request@ietf.org > You can reach the person managing the list at > netext-owner@ietf.org > When replying, please edit your Subject line so it is more specific > than "Re: Contents of netext digest..." > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com > Today's Topics: > 1. WG LC on draft-ietf-netext-redirect-03 (Rajeev Koodli) > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com > ------------------------------------------------------------ > From: Rajeev Koodli > To: "netext@ietf.org" > Subject: [netext] WG LC on draft-ietf-netext-redirect-03 > Date: Tue06 Jul 2010 14:31:51 -0700 > Hello folks, > We would like to progress this draft. This is a three week LC on the draft. > Please provide your input by July 27. Hopefully, we can discuss the input > during the meeting on the 28th. > Look forward to your reviews. > ID URL: http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt > Thanks, > -Rajeev (for chairs) > > ------------------------------------------------------------ > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com > -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From gsnaa.v2@163.com Wed Jul 7 23:03: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 55BB43A69F8 for ; Wed, 7 Jul 2010 23:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.205 X-Spam-Level: **** X-Spam-Status: No, score=4.205 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 ZDaBBGZZUvn5 for ; Wed, 7 Jul 2010 23:03:02 -0700 (PDT) Received: from m50-133.163.com (m50-133.163.com [123.125.50.133]) by core3.amsl.com (Postfix) with ESMTP id 795EA3A6902 for ; Wed, 7 Jul 2010 23:03:01 -0700 (PDT) Received: from iplab-yzw (unknown [60.247.46.135]) by smtp3 (Coremail) with SMTP id DdGowKALvpIXajVMmGboAA--.62390S2; Thu, 08 Jul 2010 14:03:03 +0800 (CST) Date: Thu, 8 Jul 2010 14:03:00 +0800 From: "gsnaa.v2" To: "Xiangsong Cui" References: , <201007081129470626009@163.com> Message-ID: <201007081402594841109@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon743654570823_=====" X-CM-TRANSID: DdGowKALvpIXajVMmGboAA--.62390S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxCrWDKF1rAw18tw4DWw1xKrg_yoWruFW7pF W3Kr17Krn5GrnrJw1xAw1xZ3WYvw18Ja1UGrn8Jr18Aa43CFyUKFyrtr1rZrWDGry5Xr4U Zr4UCr1UJw18JrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jz4E_UUUUU= X-CM-SenderInfo: 5jvqttsoysqiywtou0bp/1tbiGR8IQklzaS11wAABsG Cc: netext Subject: Re: [netext] netext Digest, Vol 14, Issue 1 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: Thu, 08 Jul 2010 06:03:04 -0000 This is a multi-part message in MIME format. --=====003_Dragon743654570823_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQpBcyBhIG1ldGhvZCwgdGhlIHJmTE1BIGNhbiBhY3QgYXMgYSChsHByb3h5IE1BR6GxLiBB ZnRlciB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MsIHRoZSByZkxNQSBjYW4ga25vdyB0aGF0IHdo aWNoIGZsb3dzIHNob3VsZCBiZSByZWRpcmVjdGVkIHRvIHRoZSByMkxNQSBhbmQgd2hpY2ggZmxv d3Mgc2hvdWxkIGJlIHRyYW5zbWl0dGVkIGJ5IGl0c2VsZi4NCkJSLA0KWmhpd2VpIFlhbg0KDQoy MDEwLTA3LTA4IA0KDQoNCg0KWmhpd2VpDQoNCg0KDQq3orz+yMujuiBYaWFuZ3NvbmcgQ3VpIA0K t6LLzcqxvOSjuiAyMDEwLTA3LTA4ICAxMTo1NDoyMyANCsrVvP7Iy6O6IGdzbmFhLnYyOyBuZXRl eHQgDQqzrcvNo7ogDQrW98zio7ogUmU6IFtuZXRleHRdIG5ldGV4dCBEaWdlc3QsIFZvbCAxNCwg SXNzdWUgMSANCiANCkhpLA0KSSB0aGluayB0aGF0IHdvdWxkIGJlIHZlcnkgZGlmZmljdWx0Lg0K Rm9yIHRoZSBvdXRnb2luZyB0cmFmZmljIG9mIE1OLCB0aGUgTUFHIG1heSB1c2UgdHJhZmZpYyBm aWx0ZXIgdG8gc3BsaXQgTU4ncyB0cmFmZmljIHRvIHRoZSBzZXBhcmF0ZSBMTUFzLCBidXQgZm9y IHRoZSBpbmNvbWluZyANCnRyYWZmaWMsIGhvdyBjYW4gdGhlIG5ldHdvcmsgZW50aXRpZXMgc2Vu ZCB0aGUgcGFja2V0cyAoZm9yIGRpZmZlcmVudCBzZXNzaW9ucykgdG8gdGhlIGNvcnJlc3BvbmRp bmcgTE1BPw0KUmVnYXJkcywNClhpYW5nc29uZw0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCkZyb206ICJnc25hYS52MiIgPGdzbmFhLnYyQDE2My5jb20+DQpUbzogIm5ldGV4dCIgPG5l dGV4dEBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDExOjI5IEFNDQpT dWJqZWN0OiBSZTogW25ldGV4dF0gbmV0ZXh0IERpZ2VzdCwgVm9sIDE0LCBJc3N1ZSAxDQo+IFRo ZSByZWRpcmVjdGlvbiBvZiBMTUEgY2FuIGRlZmluaXRlbHkgaW1wcm92ZSB0aGUgb3ZlcmFsbCBw ZXJmb3JtYW5jZSBvZiB0aGUgUE1JUHY2IGRvbWFpbiwgZm9yIGV4YW1wbGUgaXQgY2FuIGJhbGFu Y2UgdGhlIGxvYWQgDQo+IGJldHdlZW4gTE1BcyBhcyBSYWplZXYgbWVudGlvbmVkIGluIHRoZSBk cmFmdC4NCj4gSG93ZXZlciwgc29tZXRpbWVzIG9uZSBNQUcgbWF5IGNvbW11bmljYXRlIHdpdGgg dHdvIExNQXMgYXQgdGhlIHNhbWUgdGltZSB0byBwcm92aWRlIGJldHRlciBzZXJ2aWNlIGZvciBh IE1OLiBGb3IgZXhhbXBsZSwgdGhlIA0KPiBkaWZmZXJlbnQgc2Vzc2lvbnMgb2YgdGhlIE1OIGNh biBiZSBzZXBhcmF0ZWx5IGVzdGFibGlzaGVkIHRocm91Z2ggdHdvIGRpZmZlcmVudCBMTUFzLg0K PiBBbHRob3VnaCB0aGUgZHJhZnQgc3BlY2lmaWVkIHRoYXQgobBkdXJpbmcgdGhlIHJlZGlyZWN0 aW9uIHByb2Nlc3MsIHRoZSByZkxNQSBNQVkgbmVlZCB0byBtYWludGFpbiBhIHRlbXBvcmFyeSBN QUctcmZMTUEtcjJMTUEgDQo+IHN0YXRlIGFuZCBtYXkgZXZlbiBhY3QgYXMgYSAicHJveHkgTUFH IiB0byB0aGUgcjJMTUGhsS4gSSB0aGluayB5b3UgY2FuIHNldCBhIGZsYWcgaW4gdGhlIFJlZGly ZWN0IE1vYmlsaXR5IE9wdGlvbiB0byBpbmRpY2F0ZSB0aGUgDQo+IE1BRyB3aGV0aGVyIHR3byBC VUwgc2hvdWxkIGJlIG1haW50YWluZWQgZm9yIHRoZSBNTiBvciBvbmx5IG9uZSBCVUwgY2FuIGJl IGVzdGFibGlzaGVkIGF0IHRoZSBzYW1lIHRpbWUuDQo+DQo+DQo+IDIwMTAtMDctMDgNCj4NCj4N Cj4NCj4gWmhpd2VpIFlhbg0KPg0KPg0KPg0KPiC3orz+yMujuiBuZXRleHQtcmVxdWVzdA0KPiC3 osvNyrG85KO6IDIwMTAtMDctMDggIDAzOjAxOjUyDQo+IMrVvP7Iy6O6IG5ldGV4dA0KPiCzrcvN o7oNCj4g1vfM4qO6IG5ldGV4dCBEaWdlc3QsIFZvbCAxNCwgSXNzdWUgMQ0KPg0KPiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGRpZ2VzdCB3aXRob3V0IGFsbCB0aGUgaW5kaXZpZHVhbCBtZXNz YWdlDQo+IGF0dGFjaG1lbnRzIHlvdSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGlnZXN0IG9w dGlvbnMgaW4geW91ciBsaXN0DQo+IHN1YnNjcmlwdGlvbi4gIFRvIGRvIHNvLCBnbyB0bw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiBDbGljayB0aGUg J1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dG9uLCBsb2cgaW4sIGFuZCBzZXQgIkdl dA0KPiBNSU1FIG9yIFBsYWluIFRleHQgRGlnZXN0cz8iIHRvIE1JTUUuICBZb3UgY2FuIHNldCB0 aGlzIG9wdGlvbg0KPiBnbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2Vp dmUgYXQgdGhpcyBwb2ludC4NCj4gU2VuZCBuZXRleHQgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25z IHRvDQo+IG5ldGV4dEBpZXRmLm9yZw0KPiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlh IHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRleHQNCj4gb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBz dWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQo+IG5ldGV4dC1yZXF1ZXN0QGlldGYub3JnDQo+IFlv dSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KPiBuZXRleHQtb3du ZXJAaWV0Zi5vcmcNCj4gV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxp bmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KPiB0aGFuICJSZTogQ29udGVudHMgb2YgbmV0ZXh0 IGRpZ2VzdC4uLiINCj4gX19fX19fX19fXyBJbmZvcm1hdGlvbiBmcm9tIEVTRVQgTk9EMzIgQW50 aXZpcnVzLCB2ZXJzaW9uIG9mIHZpcnVzIHNpZ25hdHVyZSBkYXRhYmFzZSA1MDkzICgyMDEwMDUw NikgX19fX19fX19fXw0KPiBUaGUgbWVzc2FnZSB3YXMgY2hlY2tlZCBieSBFU0VUIE5PRDMyIEFu dGl2aXJ1cy4NCj4gaHR0cDovL3d3dy5lc2V0LmNvbQ0KPiBUb2RheSdzIFRvcGljczoNCj4gICAx LiBXRyBMQyBvbiBkcmFmdC1pZXRmLW5ldGV4dC1yZWRpcmVjdC0wMyAoUmFqZWV2IEtvb2RsaSkN Cj4gX19fX19fX19fXyBJbmZvcm1hdGlvbiBmcm9tIEVTRVQgTk9EMzIgQW50aXZpcnVzLCB2ZXJz aW9uIG9mIHZpcnVzIHNpZ25hdHVyZSBkYXRhYmFzZSA1MDkzICgyMDEwMDUwNikgX19fX19fX19f Xw0KPiBUaGUgbWVzc2FnZSB3YXMgY2hlY2tlZCBieSBFU0VUIE5PRDMyIEFudGl2aXJ1cy4NCj4g aHR0cDovL3d3dy5lc2V0LmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRnJvbTogIFJhamVldiBLb29kbGkgPHJrb29k bGlAY2lzY28uY29tPg0KPiBUbzogICJuZXRleHRAaWV0Zi5vcmciIDxuZXRleHRAaWV0Zi5vcmc+ DQo+IFN1YmplY3Q6ICBbbmV0ZXh0XSBXRyBMQyBvbiBkcmFmdC1pZXRmLW5ldGV4dC1yZWRpcmVj dC0wMw0KPiBEYXRlOiAgVHVlMDYgSnVsIDIwMTAgMTQ6MzE6NTEgLTA3MDANCj4gSGVsbG8gZm9s a3MsDQo+IFdlIHdvdWxkIGxpa2UgdG8gcHJvZ3Jlc3MgdGhpcyBkcmFmdC4gVGhpcyBpcyBhIHRo cmVlIHdlZWsgTEMgb24gdGhlIGRyYWZ0Lg0KPiBQbGVhc2UgcHJvdmlkZSB5b3VyIGlucHV0IGJ5 IEp1bHkgMjcuIEhvcGVmdWxseSwgd2UgY2FuIGRpc2N1c3MgdGhlIGlucHV0DQo+IGR1cmluZyB0 aGUgbWVldGluZyBvbiB0aGUgMjh0aC4NCj4gTG9vayBmb3J3YXJkIHRvIHlvdXIgcmV2aWV3cy4N Cj4gSUQgVVJMOiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbmV0ZXh0LXJlZGly ZWN0LTAzLnR4dA0KPiBUaGFua3MsDQo+IC1SYWplZXYgKGZvciBjaGFpcnMpDQo+DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRl eHQgbWFpbGluZyBsaXN0DQo+IG5ldGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiBfX19fX19fX19fIEluZm9ybWF0aW9uIGZyb20g RVNFVCBOT0QzMiBBbnRpdmlydXMsIHZlcnNpb24gb2YgdmlydXMgc2lnbmF0dXJlIGRhdGFiYXNl IDUwOTMgKDIwMTAwNTA2KSBfX19fX19fX19fDQo+IFRoZSBtZXNzYWdlIHdhcyBjaGVja2VkIGJ5 IEVTRVQgTk9EMzIgQW50aXZpcnVzLg0KPiBodHRwOi8vd3d3LmVzZXQuY29tDQo+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBuZXRleHQgbWFpbGluZyBsaXN0DQo+IG5ldGV4dEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiANCl9fX19fX19f X18gSW5mb3JtYXRpb24gZnJvbSBFU0VUIE5PRDMyIEFudGl2aXJ1cywgdmVyc2lvbiBvZiB2aXJ1 cyBzaWduYXR1cmUgZGF0YWJhc2UgNTA5MyAoMjAxMDA1MDYpIF9fX19fX19fX18NClRoZSBtZXNz YWdlIHdhcyBjaGVja2VkIGJ5IEVTRVQgTk9EMzIgQW50aXZpcnVzLg0KaHR0cDovL3d3dy5lc2V0 LmNvbQ0K --=====003_Dragon743654570823_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU5NjkiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KY29sb3I9IzAwMDAw MD5IaSw8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgY29sb3I9IzAwMDAwMD5BcyBhIA0KbWV0aG9k LCB0aGUgcmZMTUEgY2FuIGFjdCBhcyBhIKGwcHJveHkgTUFHobEuIEFmdGVyIHRoZSByZWdpc3Ry YXRpb24gcHJvY2VzcywgdGhlIA0KcmZMTUEgY2FuIGtub3cgdGhhdCB3aGljaCBmbG93cyBzaG91 bGQgYmUgcmVkaXJlY3RlZCB0byB0aGUgcjJMTUEgYW5kIHdoaWNoIA0KZmxvd3Mgc2hvdWxkIGJl IHRyYW5zbWl0dGVkIGJ5IGl0c2VsZi48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iTUFSR0lOOiAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpjb2xvcj0j MDAwMDAwPkJSLDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU46IDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwMDA+Wmhpd2Vp IFlhbjwvRk9OVD48L1NQQU4+PC9QPjwvRk9OVD48Rk9OVCBmYWNlPVZlcmRhbmEgDQpjb2xvcj0j MDAwMDgwIHNpemU9Mj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xv cj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj4yMDEwLTA3LTA4IDwvRk9OVD48L0RJVj48Rk9OVCAN CmZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEy MnB4OyBIRUlHSFQ6IDJweCIgYWxpZ249bGVmdCBTSVpFPTI+DQo8L0ZPTlQ+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwIA0Kc2l6ZT0yPjxTUEFOPlpoaXdlaTwvU1BBTj48 L0ZPTlQ+PC9ESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhS Pg0KPC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+t6K8/sjL o7o8L1NUUk9ORz4gWGlhbmdzb25nIEN1aSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYSBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IDIwMTAtMDctMDgmbmJz cDsgMTE6NTQ6MjMgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiBnc25hYS52MjsgbmV0ZXh0IA0KPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9TVFJP Tkc+IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05H Ptb3zOKjujwvU1RST05HPiBSZTogW25ldGV4dF0gbmV0ZXh0IERpZ2VzdCwgDQpWb2wgMTQsIElz c3VlIDEgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9O VD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPkhpLDwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+SSZuYnNwO3RoaW5rJm5ic3A7dGhhdCZuYnNwO3dvdWxkJm5i c3A7YmUmbmJzcDt2ZXJ5Jm5ic3A7ZGlmZmljdWx0LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+ Rm9yJm5ic3A7dGhlJm5ic3A7b3V0Z29pbmcmbmJzcDt0cmFmZmljJm5ic3A7b2YmbmJzcDtNTiwm bmJzcDt0aGUmbmJzcDtNQUcmbmJzcDttYXkmbmJzcDt1c2UmbmJzcDt0cmFmZmljJm5ic3A7Zmls dGVyJm5ic3A7dG8mbmJzcDtzcGxpdCZuYnNwO01OJ3MmbmJzcDt0cmFmZmljJm5ic3A7dG8mbmJz cDt0aGUmbmJzcDtzZXBhcmF0ZSZuYnNwO0xNQXMsJm5ic3A7YnV0Jm5ic3A7Zm9yJm5ic3A7dGhl Jm5ic3A7aW5jb21pbmcmbmJzcDs8L0RJVj4NCjxESVY+dHJhZmZpYywmbmJzcDtob3cmbmJzcDtj YW4mbmJzcDt0aGUmbmJzcDtuZXR3b3JrJm5ic3A7ZW50aXRpZXMmbmJzcDtzZW5kJm5ic3A7dGhl Jm5ic3A7cGFja2V0cyZuYnNwOyhmb3ImbmJzcDtkaWZmZXJlbnQmbmJzcDtzZXNzaW9ucykmbmJz cDt0byZuYnNwO3RoZSZuYnNwO2NvcnJlc3BvbmRpbmcmbmJzcDtMTUE/PC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj5SZWdhcmRzLDwvRElWPg0KPERJVj5YaWFuZ3Nvbmc8L0RJVj4NCjxESVY+PC9E SVY+DQo8RElWPi0tLS0tJm5ic3A7T3JpZ2luYWwmbmJzcDtNZXNzYWdlJm5ic3A7LS0tLS0mbmJz cDs8L0RJVj4NCjxESVY+RnJvbTombmJzcDsiZ3NuYWEudjIiJm5ic3A7Jmx0O2dzbmFhLnYyQDE2 My5jb20mZ3Q7PC9ESVY+DQo8RElWPlRvOiZuYnNwOyJuZXRleHQiJm5ic3A7Jmx0O25ldGV4dEBp ZXRmLm9yZyZndDs8L0RJVj4NCjxESVY+U2VudDombmJzcDtUaHVyc2RheSwmbmJzcDtKdWx5Jm5i c3A7MDgsJm5ic3A7MjAxMCZuYnNwOzExOjI5Jm5ic3A7QU08L0RJVj4NCjxESVY+U3ViamVjdDom bmJzcDtSZTombmJzcDtbbmV0ZXh0XSZuYnNwO25ldGV4dCZuYnNwO0RpZ2VzdCwmbmJzcDtWb2wm bmJzcDsxNCwmbmJzcDtJc3N1ZSZuYnNwOzE8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7VGhlJm5ic3A7cmVkaXJlY3Rpb24mbmJzcDtvZiZuYnNwO0xNQSZu YnNwO2NhbiZuYnNwO2RlZmluaXRlbHkmbmJzcDtpbXByb3ZlJm5ic3A7dGhlJm5ic3A7b3ZlcmFs bCZuYnNwO3BlcmZvcm1hbmNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtQTUlQdjYmbmJzcDtkb21h aW4sJm5ic3A7Zm9yJm5ic3A7ZXhhbXBsZSZuYnNwO2l0Jm5ic3A7Y2FuJm5ic3A7YmFsYW5jZSZu YnNwO3RoZSZuYnNwO2xvYWQmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2JldHdlZW4mbmJz cDtMTUFzJm5ic3A7YXMmbmJzcDtSYWplZXYmbmJzcDttZW50aW9uZWQmbmJzcDtpbiZuYnNwO3Ro ZSZuYnNwO2RyYWZ0LjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SG93ZXZlciwmbmJzcDtzb21ldGlt ZXMmbmJzcDtvbmUmbmJzcDtNQUcmbmJzcDttYXkmbmJzcDtjb21tdW5pY2F0ZSZuYnNwO3dpdGgm bmJzcDt0d28mbmJzcDtMTUFzJm5ic3A7YXQmbmJzcDt0aGUmbmJzcDtzYW1lJm5ic3A7dGltZSZu YnNwO3RvJm5ic3A7cHJvdmlkZSZuYnNwO2JldHRlciZuYnNwO3NlcnZpY2UmbmJzcDtmb3ImbmJz cDthJm5ic3A7TU4uJm5ic3A7Rm9yJm5ic3A7ZXhhbXBsZSwmbmJzcDt0aGUmbmJzcDs8L0RJVj4N CjxESVY+Jmd0OyZuYnNwO2RpZmZlcmVudCZuYnNwO3Nlc3Npb25zJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtNTiZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7c2VwYXJhdGVseSZuYnNwO2VzdGFibGlzaGVk Jm5ic3A7dGhyb3VnaCZuYnNwO3R3byZuYnNwO2RpZmZlcmVudCZuYnNwO0xNQXMuPC9ESVY+DQo8 RElWPiZndDsmbmJzcDtBbHRob3VnaCZuYnNwO3RoZSZuYnNwO2RyYWZ0Jm5ic3A7c3BlY2lmaWVk Jm5ic3A7dGhhdCZuYnNwO6GwZHVyaW5nJm5ic3A7dGhlJm5ic3A7cmVkaXJlY3Rpb24mbmJzcDtw cm9jZXNzLCZuYnNwO3RoZSZuYnNwO3JmTE1BJm5ic3A7TUFZJm5ic3A7bmVlZCZuYnNwO3RvJm5i c3A7bWFpbnRhaW4mbmJzcDthJm5ic3A7dGVtcG9yYXJ5Jm5ic3A7TUFHLXJmTE1BLXIyTE1BJm5i c3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtzdGF0ZSZuYnNwO2FuZCZuYnNwO21heSZuYnNwO2V2 ZW4mbmJzcDthY3QmbmJzcDthcyZuYnNwO2EmbmJzcDsicHJveHkmbmJzcDtNQUciJm5ic3A7dG8m bmJzcDt0aGUmbmJzcDtyMkxNQaGxLiZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3lvdSZuYnNwO2Nh biZuYnNwO3NldCZuYnNwO2EmbmJzcDtmbGFnJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtSZWRpcmVj dCZuYnNwO01vYmlsaXR5Jm5ic3A7T3B0aW9uJm5ic3A7dG8mbmJzcDtpbmRpY2F0ZSZuYnNwO3Ro ZSZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7TUFHJm5ic3A7d2hldGhlciZuYnNwO3R3byZu YnNwO0JVTCZuYnNwO3Nob3VsZCZuYnNwO2JlJm5ic3A7bWFpbnRhaW5lZCZuYnNwO2ZvciZuYnNw O3RoZSZuYnNwO01OJm5ic3A7b3ImbmJzcDtvbmx5Jm5ic3A7b25lJm5ic3A7QlVMJm5ic3A7Y2Fu Jm5ic3A7YmUmbmJzcDtlc3RhYmxpc2hlZCZuYnNwO2F0Jm5ic3A7dGhlJm5ic3A7c2FtZSZuYnNw O3RpbWUuPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7MjAxMC0wNy0wODwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJVj4N CjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Wmhpd2VpJm5ic3A7WWFuPC9ESVY+DQo8 RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZn dDsmbmJzcDu3orz+yMujuiZuYnNwO25ldGV4dC1yZXF1ZXN0PC9ESVY+DQo8RElWPiZndDsmbmJz cDu3osvNyrG85KO6Jm5ic3A7MjAxMC0wNy0wOCZuYnNwOyZuYnNwOzAzOjAxOjUyPC9ESVY+DQo8 RElWPiZndDsmbmJzcDvK1bz+yMujuiZuYnNwO25ldGV4dDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 s63LzaO6PC9ESVY+DQo8RElWPiZndDsmbmJzcDvW98zio7ombmJzcDtuZXRleHQmbmJzcDtEaWdl c3QsJm5ic3A7Vm9sJm5ic3A7MTQsJm5ic3A7SXNzdWUmbmJzcDsxPC9ESVY+DQo8RElWPiZndDs8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVk Jm5ic3A7dGhpcyZuYnNwO2RpZ2VzdCZuYnNwO3dpdGhvdXQmbmJzcDthbGwmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7bWVzc2FnZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7YXR0YWNobWVu dHMmbmJzcDt5b3UmbmJzcDt3aWxsJm5ic3A7bmVlZCZuYnNwO3RvJm5ic3A7dXBkYXRlJm5ic3A7 eW91ciZuYnNwO2RpZ2VzdCZuYnNwO29wdGlvbnMmbmJzcDtpbiZuYnNwO3lvdXImbmJzcDtsaXN0 PC9ESVY+DQo8RElWPiZndDsmbmJzcDtzdWJzY3JpcHRpb24uJm5ic3A7Jm5ic3A7VG8mbmJzcDtk byZuYnNwO3NvLCZuYnNwO2dvJm5ic3A7dG88L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2h0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0PC9ESVY+DQo8RElWPiZndDsmbmJz cDtDbGljayZuYnNwO3RoZSZuYnNwOydVbnN1YnNjcmliZSZuYnNwO29yJm5ic3A7ZWRpdCZuYnNw O29wdGlvbnMnJm5ic3A7YnV0dG9uLCZuYnNwO2xvZyZuYnNwO2luLCZuYnNwO2FuZCZuYnNwO3Nl dCZuYnNwOyJHZXQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO01JTUUmbmJzcDtvciZuYnNwO1BsYWlu Jm5ic3A7VGV4dCZuYnNwO0RpZ2VzdHM/IiZuYnNwO3RvJm5ic3A7TUlNRS4mbmJzcDsmbmJzcDtZ b3UmbmJzcDtjYW4mbmJzcDtzZXQmbmJzcDt0aGlzJm5ic3A7b3B0aW9uPC9ESVY+DQo8RElWPiZn dDsmbmJzcDtnbG9iYWxseSZuYnNwO2ZvciZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO2xpc3QmbmJz cDtkaWdlc3RzJm5ic3A7eW91Jm5ic3A7cmVjZWl2ZSZuYnNwO2F0Jm5ic3A7dGhpcyZuYnNwO3Bv aW50LjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7U2VuZCZuYnNwO25ldGV4dCZuYnNwO21haWxpbmcm bmJzcDtsaXN0Jm5ic3A7c3VibWlzc2lvbnMmbmJzcDt0bzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 bmV0ZXh0QGlldGYub3JnPC9ESVY+DQo8RElWPiZndDsmbmJzcDtUbyZuYnNwO3N1YnNjcmliZSZu YnNwO29yJm5ic3A7dW5zdWJzY3JpYmUmbmJzcDt2aWEmbmJzcDt0aGUmbmJzcDtXb3JsZCZuYnNw O1dpZGUmbmJzcDtXZWIsJm5ic3A7dmlzaXQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2h0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0PC9ESVY+DQo8RElWPiZndDsmbmJz cDtvciwmbmJzcDt2aWEmbmJzcDtlbWFpbCwmbmJzcDtzZW5kJm5ic3A7YSZuYnNwO21lc3NhZ2Um bmJzcDt3aXRoJm5ic3A7c3ViamVjdCZuYnNwO29yJm5ic3A7Ym9keSZuYnNwOydoZWxwJyZuYnNw O3RvPC9ESVY+DQo8RElWPiZndDsmbmJzcDtuZXRleHQtcmVxdWVzdEBpZXRmLm9yZzwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7WW91Jm5ic3A7Y2FuJm5ic3A7cmVhY2gmbmJzcDt0aGUmbmJzcDtwZXJz b24mbmJzcDttYW5hZ2luZyZuYnNwO3RoZSZuYnNwO2xpc3QmbmJzcDthdDwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7bmV0ZXh0LW93bmVyQGlldGYub3JnPC9ESVY+DQo8RElWPiZndDsmbmJzcDtXaGVu Jm5ic3A7cmVwbHlpbmcsJm5ic3A7cGxlYXNlJm5ic3A7ZWRpdCZuYnNwO3lvdXImbmJzcDtTdWJq ZWN0Jm5ic3A7bGluZSZuYnNwO3NvJm5ic3A7aXQmbmJzcDtpcyZuYnNwO21vcmUmbmJzcDtzcGVj aWZpYzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dGhhbiZuYnNwOyJSZTombmJzcDtDb250ZW50cyZu YnNwO29mJm5ic3A7bmV0ZXh0Jm5ic3A7ZGlnZXN0Li4uIjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 X19fX19fX19fXyZuYnNwO0luZm9ybWF0aW9uJm5ic3A7ZnJvbSZuYnNwO0VTRVQmbmJzcDtOT0Qz MiZuYnNwO0FudGl2aXJ1cywmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDt2aXJ1cyZuYnNwO3Np Z25hdHVyZSZuYnNwO2RhdGFiYXNlJm5ic3A7NTA5MyZuYnNwOygyMDEwMDUwNikmbmJzcDtfX19f X19fX19fPC9ESVY+DQo8RElWPiZndDsmbmJzcDtUaGUmbmJzcDttZXNzYWdlJm5ic3A7d2FzJm5i c3A7Y2hlY2tlZCZuYnNwO2J5Jm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLjwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7aHR0cDovL3d3dy5lc2V0LmNvbTwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7VG9kYXkncyZuYnNwO1RvcGljczo8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOzEuJm5ic3A7V0cmbmJzcDtMQyZuYnNwO29uJm5ic3A7ZHJhZnQtaWV0Zi1uZXRleHQtcmVk aXJlY3QtMDMmbmJzcDsoUmFqZWV2Jm5ic3A7S29vZGxpKTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 X19fX19fX19fXyZuYnNwO0luZm9ybWF0aW9uJm5ic3A7ZnJvbSZuYnNwO0VTRVQmbmJzcDtOT0Qz MiZuYnNwO0FudGl2aXJ1cywmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDt2aXJ1cyZuYnNwO3Np Z25hdHVyZSZuYnNwO2RhdGFiYXNlJm5ic3A7NTA5MyZuYnNwOygyMDEwMDUwNikmbmJzcDtfX19f X19fX19fPC9ESVY+DQo8RElWPiZndDsmbmJzcDtUaGUmbmJzcDttZXNzYWdlJm5ic3A7d2FzJm5i c3A7Y2hlY2tlZCZuYnNwO2J5Jm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLjwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7aHR0cDovL3d3dy5lc2V0LmNvbTwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDtGcm9tOiZuYnNwOyZuYnNwO1JhamVldiZu YnNwO0tvb2RsaSZuYnNwOyZsdDtya29vZGxpQGNpc2NvLmNvbSZndDs8L0RJVj4NCjxESVY+Jmd0 OyZuYnNwO1RvOiZuYnNwOyZuYnNwOyJuZXRleHRAaWV0Zi5vcmciJm5ic3A7Jmx0O25ldGV4dEBp ZXRmLm9yZyZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1N1YmplY3Q6Jm5ic3A7Jm5ic3A7W25l dGV4dF0mbmJzcDtXRyZuYnNwO0xDJm5ic3A7b24mbmJzcDtkcmFmdC1pZXRmLW5ldGV4dC1yZWRp cmVjdC0wMzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RGF0ZTombmJzcDsmbmJzcDtUdWUwNiZuYnNw O0p1bCZuYnNwOzIwMTAmbmJzcDsxNDozMTo1MSZuYnNwOy0wNzAwPC9ESVY+DQo8RElWPiZndDsm bmJzcDtIZWxsbyZuYnNwO2ZvbGtzLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7V2UmbmJzcDt3b3Vs ZCZuYnNwO2xpa2UmbmJzcDt0byZuYnNwO3Byb2dyZXNzJm5ic3A7dGhpcyZuYnNwO2RyYWZ0LiZu YnNwO1RoaXMmbmJzcDtpcyZuYnNwO2EmbmJzcDt0aHJlZSZuYnNwO3dlZWsmbmJzcDtMQyZuYnNw O29uJm5ic3A7dGhlJm5ic3A7ZHJhZnQuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtQbGVhc2UmbmJz cDtwcm92aWRlJm5ic3A7eW91ciZuYnNwO2lucHV0Jm5ic3A7YnkmbmJzcDtKdWx5Jm5ic3A7Mjcu Jm5ic3A7SG9wZWZ1bGx5LCZuYnNwO3dlJm5ic3A7Y2FuJm5ic3A7ZGlzY3VzcyZuYnNwO3RoZSZu YnNwO2lucHV0PC9ESVY+DQo8RElWPiZndDsmbmJzcDtkdXJpbmcmbmJzcDt0aGUmbmJzcDttZWV0 aW5nJm5ic3A7b24mbmJzcDt0aGUmbmJzcDsyOHRoLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7TG9v ayZuYnNwO2ZvcndhcmQmbmJzcDt0byZuYnNwO3lvdXImbmJzcDtyZXZpZXdzLjwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7SUQmbmJzcDtVUkw6Jm5ic3A7aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFm dC1pZXRmLW5ldGV4dC1yZWRpcmVjdC0wMy50eHQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1RoYW5r cyw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOy1SYWplZXYmbmJzcDsoZm9yJm5ic3A7Y2hhaXJzKTwv RElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+Jmd0 OyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9E SVY+DQo8RElWPiZndDsmbmJzcDtuZXRleHQmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7bmV0ZXh0QGlldGYub3JnPC9ESVY+DQo8RElWPiZndDsmbmJzcDtodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7X19fX19fX19fXyZuYnNwO0luZm9ybWF0aW9uJm5ic3A7ZnJvbSZuYnNwO0VTRVQmbmJz cDtOT0QzMiZuYnNwO0FudGl2aXJ1cywmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDt2aXJ1cyZu YnNwO3NpZ25hdHVyZSZuYnNwO2RhdGFiYXNlJm5ic3A7NTA5MyZuYnNwOygyMDEwMDUwNikmbmJz cDtfX19fX19fX19fPC9ESVY+DQo8RElWPiZndDsmbmJzcDtUaGUmbmJzcDttZXNzYWdlJm5ic3A7 d2FzJm5ic3A7Y2hlY2tlZCZuYnNwO2J5Jm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZp cnVzLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aHR0cDovL3d3dy5lc2V0LmNvbTwvRElWPg0KPERJ Vj4mZ3Q7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4N CjxESVY+Jmd0OyZuYnNwO25ldGV4dCZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9ESVY+DQo8RElW PiZndDsmbmJzcDtuZXRleHRAaWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2h0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0PC9ESVY+DQo8RElWPiZndDsmbmJz cDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5fX19fX19fX19fJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtmcm9tJm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVz LCZuYnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNwO3ZpcnVzJm5ic3A7c2lnbmF0dXJlJm5ic3A7ZGF0 YWJhc2UmbmJzcDs1MDkzJm5ic3A7KDIwMTAwNTA2KSZuYnNwO19fX19fX19fX188L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO21lc3NhZ2UmbmJzcDt3YXMmbmJzcDtjaGVja2VkJm5i c3A7YnkmbmJzcDtFU0VUJm5ic3A7Tk9EMzImbmJzcDtBbnRpdmlydXMuPC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj5odHRwOi8vd3d3LmVzZXQuY29tPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon743654570823_=====-- From Xiangsong.Cui@huawei.com Wed Jul 7 23:17: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 E34983A6898 for ; Wed, 7 Jul 2010 23:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.924 X-Spam-Level: ** X-Spam-Status: No, score=2.924 tagged_above=-999 required=5 tests=[AWL=-1.632, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 lqWtNKAsr-rV for ; Wed, 7 Jul 2010 23:17:22 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 66F9B3A6809 for ; Wed, 7 Jul 2010 23:17:22 -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 <0L5800JUS6SR8L@szxga03-in.huawei.com> for netext@ietf.org; Thu, 08 Jul 2010 14:17:15 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5800FZB6SR0S@szxga03-in.huawei.com> for netext@ietf.org; Thu, 08 Jul 2010 14:17:15 +0800 (CST) Date: Thu, 08 Jul 2010 14:17:15 +0800 From: Xiangsong Cui To: "gsnaa.v2" Message-id: <00f701cb1e65$35ebff20$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <201007081129470626009@163.com> <201007081402594841109@163.com> Cc: netext Subject: Re: [netext] netext Digest, Vol 14, Issue 1 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: Thu, 08 Jul 2010 06:17:24 -0000 Do you mean cascade connection? The packets go through one LMA and later another one? Xiangsong ----- Original Message ----- From: "gsnaa.v2" To: "Xiangsong Cui" Cc: "netext" Sent: Thursday, July 08, 2010 2:03 PM Subject: Re: [netext] netext Digest, Vol 14, Issue 1 > Hi, > As a method, the rfLMA can act as a “proxy MAG”. After the registration process, the rfLMA can know that which flows should be > redirected to the r2LMA and which flows should be transmitted by itself. > BR, > Zhiwei Yan > > 2010-07-08 > > > > Zhiwei > > > > 发件人： Xiangsong Cui > 发送时间： 2010-07-08 11:54:23 > 收件人： gsnaa.v2; netext > 抄送： > 主题： Re: [netext] netext Digest, Vol 14, Issue 1 > > Hi, > I think that would be very difficult. > For the outgoing traffic of MN, the MAG may use traffic filter to split MN's traffic to the separate LMAs, but for the incoming > traffic, how can the network entities send the packets (for different sessions) to the corresponding LMA? > Regards, > Xiangsong > ----- Original Message ----- > From: "gsnaa.v2" > To: "netext" > Sent: Thursday, July 08, 2010 11:29 AM > Subject: Re: [netext] netext Digest, Vol 14, Issue 1 >> The redirection of LMA can definitely improve the overall performance of the PMIPv6 domain, for example it can balance the load >> between LMAs as Rajeev mentioned in the draft. >> However, sometimes one MAG may communicate with two LMAs at the same time to provide better service for a MN. For example, the >> different sessions of the MN can be separately established through two different LMAs. >> Although the draft specified that “during the redirection process, the rfLMA MAY need to maintain a temporary MAG-rfLMA-r2LMA >> state and may even act as a "proxy MAG" to the r2LMA”. I think you can set a flag in the Redirect Mobility Option to indicate >> the >> MAG whether two BUL should be maintained for the MN or only one BUL can be established at the same time. >> >> >> 2010-07-08 >> >> >> >> Zhiwei Yan >> >> >> >> 发件人： netext-request >> 发送时间： 2010-07-08 03:01:52 >> 收件人： netext >> 抄送： >> 主题： netext Digest, Vol 14, Issue 1 >> >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> https://www.ietf.org/mailman/listinfo/netext >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> Send netext mailing list submissions to >> netext@ietf.org >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/netext >> or, via email, send a message with subject or body 'help' to >> netext-request@ietf.org >> You can reach the person managing the list at >> netext-owner@ietf.org >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of netext digest..." >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ >> The message was checked by ESET NOD32 Antivirus. >> http://www.eset.com >> Today's Topics: >> 1. WG LC on draft-ietf-netext-redirect-03 (Rajeev Koodli) >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ >> The message was checked by ESET NOD32 Antivirus. >> http://www.eset.com >> ------------------------------------------------------------ >> From: Rajeev Koodli >> To: "netext@ietf.org" >> Subject: [netext] WG LC on draft-ietf-netext-redirect-03 >> Date: Tue06 Jul 2010 14:31:51 -0700 >> Hello folks, >> We would like to progress this draft. This is a three week LC on the draft. >> Please provide your input by July 27. Hopefully, we can discuss the input >> during the meeting on the 28th. >> Look forward to your reviews. >> ID URL: http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt >> Thanks, >> -Rajeev (for chairs) >> >> ------------------------------------------------------------ >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ >> The message was checked by ESET NOD32 Antivirus. >> http://www.eset.com >> > -------------------------------------------------------------------------------- >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com > -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From gsnaa.v2@163.com Thu Jul 8 00:02:18 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 F30223A6967 for ; Thu, 8 Jul 2010 00:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.205 X-Spam-Level: **** X-Spam-Status: No, score=4.205 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 8kVjyCYnXqCz for ; Thu, 8 Jul 2010 00:02:16 -0700 (PDT) Received: from m50-133.163.com (m50-133.163.com [123.125.50.133]) by core3.amsl.com (Postfix) with ESMTP id 889083A694E for ; Thu, 8 Jul 2010 00:02:14 -0700 (PDT) Received: from iplab-yzw (unknown [60.247.46.135]) by smtp3 (Coremail) with SMTP id DdGowKCLaY3xdzVMfIbpAA--.35068S2; Thu, 08 Jul 2010 15:02:09 +0800 (CST) Date: Thu, 8 Jul 2010 15:02:05 +0800 From: "gsnaa.v2" To: "Xiangsong Cui" References: , <201007081129470626009@163.com>, <201007081402594841109@163.com>, <00f701cb1e65$35ebff20$96106f0a@china.huawei.com> Message-ID: <201007081502049378775@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon827811816704_=====" X-CM-TRANSID: DdGowKCLaY3xdzVMfIbpAA--.35068S2 X-Coremail-Antispam: 1Uf129KBjvJXoW3JF1kurW5tF45GF1DJFWUArb_yoW7tF18pF W3KF17Krn8Gr1DAw1Iy3WxZF1jvw18Jw4UGrn8Jr18Aa4a9Fy5tFyrtr1rZrWDGry5Xr4U Zr1UCr1UJw18ArDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jxZ2-UUUUU= X-CM-SenderInfo: 5jvqttsoysqiywtou0bp/1tbiJRoIQkCeJSZayQAAs7 Cc: netext Subject: Re: [netext] netext Digest, Vol 14, Issue 1 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: Thu, 08 Jul 2010 07:02:18 -0000 This is a multi-part message in MIME format. --=====003_Dragon827811816704_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQpFeGFjdGx5LCB0aGUgY2FzY2FkZSBjb25uZWN0aW9uIGJldHdlZW4gcmZMTUEgYW5kIHIy TE1BIGNhbiBiZSB1c2VkIHRvIHNlcGFyYXRlIHRoZSBwYWNrZXQgdHJhbnNtaXNzaW9uIHBhdGhz LiBUaGF0IGlzIGZlYXNpYmxlIGJlY2F1c2UgdGhlIExNQXMgYXJlIGFsbCBsaW1pdGVkIGludG8g dGhlIKGwUmVkaXJlY3Rpb24gRG9tYWluobEuIA0KQlIsDQpaaGl3ZWkgWWFuDQoNCg0KMjAxMC0w Ny0wOCANCg0KDQoNClpoaXdlaQ0KDQoNCg0Kt6K8/sjLo7ogWGlhbmdzb25nIEN1aSANCreiy83K sbzko7ogMjAxMC0wNy0wOCAgMTQ6MTc6MTYgDQrK1bz+yMujuiBnc25hYS52MiANCrOty82juiBu ZXRleHQgDQrW98zio7ogUmU6IFtuZXRleHRdIG5ldGV4dCBEaWdlc3QsIFZvbCAxNCwgSXNzdWUg MSANCiANCkRvIHlvdSBtZWFuIGNhc2NhZGUgY29ubmVjdGlvbj8NClRoZSBwYWNrZXRzIGdvIHRo cm91Z2ggb25lIExNQSBhbmQgbGF0ZXIgYW5vdGhlciBvbmU/DQpYaWFuZ3NvbmcNCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiZ3NuYWEudjIiIDxnc25hYS52MkAxNjMuY29t Pg0KVG86ICJYaWFuZ3NvbmcgQ3VpIiA8WGlhbmdzb25nLkN1aUBodWF3ZWkuY29tPg0KQ2M6ICJu ZXRleHQiIDxuZXRleHRAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCAy OjAzIFBNDQpTdWJqZWN0OiBSZTogW25ldGV4dF0gbmV0ZXh0IERpZ2VzdCwgVm9sIDE0LCBJc3N1 ZSAxDQo+IEhpLA0KPiBBcyBhIG1ldGhvZCwgdGhlIHJmTE1BIGNhbiBhY3QgYXMgYSChsHByb3h5 IE1BR6GxLiBBZnRlciB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MsIHRoZSByZkxNQSBjYW4ga25v dyB0aGF0IHdoaWNoIGZsb3dzIHNob3VsZCBiZSANCj4gcmVkaXJlY3RlZCB0byB0aGUgcjJMTUEg YW5kIHdoaWNoIGZsb3dzIHNob3VsZCBiZSB0cmFuc21pdHRlZCBieSBpdHNlbGYuDQo+IEJSLA0K PiBaaGl3ZWkgWWFuDQo+DQo+IDIwMTAtMDctMDgNCj4NCj4NCj4NCj4gWmhpd2VpDQo+DQo+DQo+ DQo+ILeivP7Iy6O6IFhpYW5nc29uZyBDdWkNCj4gt6LLzcqxvOSjuiAyMDEwLTA3LTA4ICAxMTo1 NDoyMw0KPiDK1bz+yMujuiBnc25hYS52MjsgbmV0ZXh0DQo+ILOty82jug0KPiDW98zio7ogUmU6 IFtuZXRleHRdIG5ldGV4dCBEaWdlc3QsIFZvbCAxNCwgSXNzdWUgMQ0KPg0KPiBIaSwNCj4gSSB0 aGluayB0aGF0IHdvdWxkIGJlIHZlcnkgZGlmZmljdWx0Lg0KPiBGb3IgdGhlIG91dGdvaW5nIHRy YWZmaWMgb2YgTU4sIHRoZSBNQUcgbWF5IHVzZSB0cmFmZmljIGZpbHRlciB0byBzcGxpdCBNTidz IHRyYWZmaWMgdG8gdGhlIHNlcGFyYXRlIExNQXMsIGJ1dCBmb3IgdGhlIGluY29taW5nDQo+IHRy YWZmaWMsIGhvdyBjYW4gdGhlIG5ldHdvcmsgZW50aXRpZXMgc2VuZCB0aGUgcGFja2V0cyAoZm9y IGRpZmZlcmVudCBzZXNzaW9ucykgdG8gdGhlIGNvcnJlc3BvbmRpbmcgTE1BPw0KPiBSZWdhcmRz LA0KPiBYaWFuZ3NvbmcNCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4gRnJvbTog ImdzbmFhLnYyIiA8Z3NuYWEudjJAMTYzLmNvbT4NCj4gVG86ICJuZXRleHQiIDxuZXRleHRAaWV0 Zi5vcmc+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDExOjI5IEFNDQo+IFN1Ympl Y3Q6IFJlOiBbbmV0ZXh0XSBuZXRleHQgRGlnZXN0LCBWb2wgMTQsIElzc3VlIDENCj4+IFRoZSBy ZWRpcmVjdGlvbiBvZiBMTUEgY2FuIGRlZmluaXRlbHkgaW1wcm92ZSB0aGUgb3ZlcmFsbCBwZXJm b3JtYW5jZSBvZiB0aGUgUE1JUHY2IGRvbWFpbiwgZm9yIGV4YW1wbGUgaXQgY2FuIGJhbGFuY2Ug dGhlIGxvYWQNCj4+IGJldHdlZW4gTE1BcyBhcyBSYWplZXYgbWVudGlvbmVkIGluIHRoZSBkcmFm dC4NCj4+IEhvd2V2ZXIsIHNvbWV0aW1lcyBvbmUgTUFHIG1heSBjb21tdW5pY2F0ZSB3aXRoIHR3 byBMTUFzIGF0IHRoZSBzYW1lIHRpbWUgdG8gcHJvdmlkZSBiZXR0ZXIgc2VydmljZSBmb3IgYSBN Ti4gRm9yIGV4YW1wbGUsIHRoZQ0KPj4gZGlmZmVyZW50IHNlc3Npb25zIG9mIHRoZSBNTiBjYW4g YmUgc2VwYXJhdGVseSBlc3RhYmxpc2hlZCB0aHJvdWdoIHR3byBkaWZmZXJlbnQgTE1Bcy4NCj4+ IEFsdGhvdWdoIHRoZSBkcmFmdCBzcGVjaWZpZWQgdGhhdCChsGR1cmluZyB0aGUgcmVkaXJlY3Rp b24gcHJvY2VzcywgdGhlIHJmTE1BIE1BWSBuZWVkIHRvIG1haW50YWluIGEgdGVtcG9yYXJ5IE1B Ry1yZkxNQS1yMkxNQQ0KPj4gc3RhdGUgYW5kIG1heSBldmVuIGFjdCBhcyBhICJwcm94eSBNQUci IHRvIHRoZSByMkxNQaGxLiBJIHRoaW5rIHlvdSBjYW4gc2V0IGEgZmxhZyBpbiB0aGUgUmVkaXJl Y3QgTW9iaWxpdHkgT3B0aW9uIHRvIGluZGljYXRlIA0KPj4gdGhlDQo+PiBNQUcgd2hldGhlciB0 d28gQlVMIHNob3VsZCBiZSBtYWludGFpbmVkIGZvciB0aGUgTU4gb3Igb25seSBvbmUgQlVMIGNh biBiZSBlc3RhYmxpc2hlZCBhdCB0aGUgc2FtZSB0aW1lLg0KPj4NCj4+DQo+PiAyMDEwLTA3LTA4 DQo+Pg0KPj4NCj4+DQo+PiBaaGl3ZWkgWWFuDQo+Pg0KPj4NCj4+DQo+PiC3orz+yMujuiBuZXRl eHQtcmVxdWVzdA0KPj4gt6LLzcqxvOSjuiAyMDEwLTA3LTA4ICAwMzowMTo1Mg0KPj4gytW8/sjL o7ogbmV0ZXh0DQo+PiCzrcvNo7oNCj4+INb3zOKjuiBuZXRleHQgRGlnZXN0LCBWb2wgMTQsIElz c3VlIDENCj4+DQo+PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGRpZ2VzdCB3aXRob3V0IGFs bCB0aGUgaW5kaXZpZHVhbCBtZXNzYWdlDQo+PiBhdHRhY2htZW50cyB5b3Ugd2lsbCBuZWVkIHRv IHVwZGF0ZSB5b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlvdXIgbGlzdA0KPj4gc3Vic2NyaXB0aW9u LiAgVG8gZG8gc28sIGdvIHRvDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGV4dA0KPj4gQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1 dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQNCj4+IE1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3Rz PyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uDQo+PiBnbG9iYWxseSBmb3IgYWxs IHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4NCj4+IFNlbmQgbmV0 ZXh0IG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KPj4gbmV0ZXh0QGlldGYub3JnDQo+PiBU byBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQo+PiBvciwg dmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8N Cj4+IG5ldGV4dC1yZXF1ZXN0QGlldGYub3JnDQo+PiBZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24g bWFuYWdpbmcgdGhlIGxpc3QgYXQNCj4+IG5ldGV4dC1vd25lckBpZXRmLm9yZw0KPj4gV2hlbiBy ZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVj aWZpYw0KPj4gdGhhbiAiUmU6IENvbnRlbnRzIG9mIG5ldGV4dCBkaWdlc3QuLi4iDQo+PiBfX19f X19fX19fIEluZm9ybWF0aW9uIGZyb20gRVNFVCBOT0QzMiBBbnRpdmlydXMsIHZlcnNpb24gb2Yg dmlydXMgc2lnbmF0dXJlIGRhdGFiYXNlIDUwOTMgKDIwMTAwNTA2KSBfX19fX19fX19fDQo+PiBU aGUgbWVzc2FnZSB3YXMgY2hlY2tlZCBieSBFU0VUIE5PRDMyIEFudGl2aXJ1cy4NCj4+IGh0dHA6 Ly93d3cuZXNldC5jb20NCj4+IFRvZGF5J3MgVG9waWNzOg0KPj4gICAxLiBXRyBMQyBvbiBkcmFm dC1pZXRmLW5ldGV4dC1yZWRpcmVjdC0wMyAoUmFqZWV2IEtvb2RsaSkNCj4+IF9fX19fX19fX18g SW5mb3JtYXRpb24gZnJvbSBFU0VUIE5PRDMyIEFudGl2aXJ1cywgdmVyc2lvbiBvZiB2aXJ1cyBz aWduYXR1cmUgZGF0YWJhc2UgNTA5MyAoMjAxMDA1MDYpIF9fX19fX19fX18NCj4+IFRoZSBtZXNz YWdlIHdhcyBjaGVja2VkIGJ5IEVTRVQgTk9EMzIgQW50aXZpcnVzLg0KPj4gaHR0cDovL3d3dy5l c2V0LmNvbQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+PiBGcm9tOiAgUmFqZWV2IEtvb2RsaSA8cmtvb2RsaUBjaXNjby5j b20+DQo+PiBUbzogICJuZXRleHRAaWV0Zi5vcmciIDxuZXRleHRAaWV0Zi5vcmc+DQo+PiBTdWJq ZWN0OiAgW25ldGV4dF0gV0cgTEMgb24gZHJhZnQtaWV0Zi1uZXRleHQtcmVkaXJlY3QtMDMNCj4+ IERhdGU6ICBUdWUwNiBKdWwgMjAxMCAxNDozMTo1MSAtMDcwMA0KPj4gSGVsbG8gZm9sa3MsDQo+ PiBXZSB3b3VsZCBsaWtlIHRvIHByb2dyZXNzIHRoaXMgZHJhZnQuIFRoaXMgaXMgYSB0aHJlZSB3 ZWVrIExDIG9uIHRoZSBkcmFmdC4NCj4+IFBsZWFzZSBwcm92aWRlIHlvdXIgaW5wdXQgYnkgSnVs eSAyNy4gSG9wZWZ1bGx5LCB3ZSBjYW4gZGlzY3VzcyB0aGUgaW5wdXQNCj4+IGR1cmluZyB0aGUg bWVldGluZyBvbiB0aGUgMjh0aC4NCj4+IExvb2sgZm9yd2FyZCB0byB5b3VyIHJldmlld3MuDQo+ PiBJRCBVUkw6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1uZXRleHQtcmVkaXJl Y3QtMDMudHh0DQo+PiBUaGFua3MsDQo+PiAtUmFqZWV2IChmb3IgY2hhaXJzKQ0KPj4NCj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4+IG5ldGV4dEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4+IF9fX19fX19fX18gSW5mb3JtYXRp b24gZnJvbSBFU0VUIE5PRDMyIEFudGl2aXJ1cywgdmVyc2lvbiBvZiB2aXJ1cyBzaWduYXR1cmUg ZGF0YWJhc2UgNTA5MyAoMjAxMDA1MDYpIF9fX19fX19fX18NCj4+IFRoZSBtZXNzYWdlIHdhcyBj aGVja2VkIGJ5IEVTRVQgTk9EMzIgQW50aXZpcnVzLg0KPj4gaHR0cDovL3d3dy5lc2V0LmNvbQ0K Pj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRleHQgbWFpbGluZyBsaXN0DQo+PiBuZXRl eHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 ZXh0DQo+Pg0KPiBfX19fX19fX19fIEluZm9ybWF0aW9uIGZyb20gRVNFVCBOT0QzMiBBbnRpdmly dXMsIHZlcnNpb24gb2YgdmlydXMgc2lnbmF0dXJlIGRhdGFiYXNlIDUwOTMgKDIwMTAwNTA2KSBf X19fX19fX19fDQo+IFRoZSBtZXNzYWdlIHdhcyBjaGVja2VkIGJ5IEVTRVQgTk9EMzIgQW50aXZp cnVzLg0KPiBodHRwOi8vd3d3LmVzZXQuY29tDQo+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRl eHQgbWFpbGluZyBsaXN0DQo+IG5ldGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiANCl9fX19fX19fX18gSW5mb3JtYXRpb24gZnJv bSBFU0VUIE5PRDMyIEFudGl2aXJ1cywgdmVyc2lvbiBvZiB2aXJ1cyBzaWduYXR1cmUgZGF0YWJh c2UgNTA5MyAoMjAxMDA1MDYpIF9fX19fX19fX18NClRoZSBtZXNzYWdlIHdhcyBjaGVja2VkIGJ5 IEVTRVQgTk9EMzIgQW50aXZpcnVzLg0KaHR0cDovL3d3dy5lc2V0LmNvbQ0K --=====003_Dragon827811816704_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU5NjkiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KY29sb3I9IzAwMDAw MD5IaSw8P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9IA0KInVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0K PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48 Rk9OVCANCmNvbG9yPSMwMDAwMDA+RXhhY3RseSwgdGhlIGNhc2NhZGUgY29ubmVjdGlvbiBiZXR3 ZWVuIHJmTE1BIGFuZCByMkxNQSBjYW4gYmUgDQp1c2VkIHRvIHNlcGFyYXRlIHRoZSBwYWNrZXQg dHJhbnNtaXNzaW9uIHBhdGhzLiBUaGF0IGlzIGZlYXNpYmxlIGJlY2F1c2UgdGhlIA0KTE1BcyBh cmUgYWxsIGxpbWl0ZWQgaW50byB0aGUgobBSZWRpcmVjdGlvbiBEb21haW6hsS4gPC9GT05UPjwv U1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMHB0Ij48U1BBTiBs YW5nPUVOLVVTPjxGT05UIA0KY29sb3I9IzAwMDAwMD5CUiw8bzpwPjwvbzpwPjwvRk9OVD48L1NQ QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBwdCI+PFNQQU4gbGFu Zz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwMDA+Wmhpd2VpIFlhbjwvRk9OVD48L1NQQU4+PC9Q PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMw MDAwODAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h IGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjIwMTAtMDctMDggPC9GT05UPjwvRElWPjxGT05UIA0KZmFj ZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7 IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCjwvRk9OVD4NCjxESVY+PEZPTlQgZmFj ZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgDQpzaXplPTI+PFNQQU4+Wmhpd2VpPC9TUEFOPjwvRk9O VD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFI+DQo8 L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz63orz+yMujujwv U1RST05HPiBYaWFuZ3NvbmcgQ3VpIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hIHNpemU9Mj48U1RST05HPreiy83Ksbzko7o8L1NUUk9ORz4gMjAxMC0wNy0wOCZuYnNwOyAx NDoxNzoxNiANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48 U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IGdzbmFhLnYyIDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPrOty82jujwvU1RST05HPiBuZXRleHQgPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6 PC9TVFJPTkc+IFJlOiBbbmV0ZXh0XSBuZXRleHQgRGlnZXN0LCANClZvbCAxNCwgSXNzdWUgMSA8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPiA8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxESVY+RG8mbmJzcDt5b3UmbmJz cDttZWFuJm5ic3A7Y2FzY2FkZSZuYnNwO2Nvbm5lY3Rpb24/PC9ESVY+DQo8RElWPlRoZSZuYnNw O3BhY2tldHMmbmJzcDtnbyZuYnNwO3Rocm91Z2gmbmJzcDtvbmUmbmJzcDtMTUEmbmJzcDthbmQm bmJzcDtsYXRlciZuYnNwO2Fub3RoZXImbmJzcDtvbmU/PC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj5YaWFuZ3Nvbmc8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPi0tLS0tJm5ic3A7T3JpZ2luYWwm bmJzcDtNZXNzYWdlJm5ic3A7LS0tLS0mbmJzcDs8L0RJVj4NCjxESVY+RnJvbTombmJzcDsiZ3Nu YWEudjIiJm5ic3A7Jmx0O2dzbmFhLnYyQDE2My5jb20mZ3Q7PC9ESVY+DQo8RElWPlRvOiZuYnNw OyJYaWFuZ3NvbmcmbmJzcDtDdWkiJm5ic3A7Jmx0O1hpYW5nc29uZy5DdWlAaHVhd2VpLmNvbSZn dDs8L0RJVj4NCjxESVY+Q2M6Jm5ic3A7Im5ldGV4dCImbmJzcDsmbHQ7bmV0ZXh0QGlldGYub3Jn Jmd0OzwvRElWPg0KPERJVj5TZW50OiZuYnNwO1RodXJzZGF5LCZuYnNwO0p1bHkmbmJzcDswOCwm bmJzcDsyMDEwJm5ic3A7MjowMyZuYnNwO1BNPC9ESVY+DQo8RElWPlN1YmplY3Q6Jm5ic3A7UmU6 Jm5ic3A7W25ldGV4dF0mbmJzcDtuZXRleHQmbmJzcDtEaWdlc3QsJm5ic3A7Vm9sJm5ic3A7MTQs Jm5ic3A7SXNzdWUmbmJzcDsxPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+ Jmd0OyZuYnNwO0hpLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7QXMmbmJzcDthJm5ic3A7bWV0aG9k LCZuYnNwO3RoZSZuYnNwO3JmTE1BJm5ic3A7Y2FuJm5ic3A7YWN0Jm5ic3A7YXMmbmJzcDthJm5i c3A7obBwcm94eSZuYnNwO01BR6GxLiZuYnNwO0FmdGVyJm5ic3A7dGhlJm5ic3A7cmVnaXN0cmF0 aW9uJm5ic3A7cHJvY2VzcywmbmJzcDt0aGUmbmJzcDtyZkxNQSZuYnNwO2NhbiZuYnNwO2tub3cm bmJzcDt0aGF0Jm5ic3A7d2hpY2gmbmJzcDtmbG93cyZuYnNwO3Nob3VsZCZuYnNwO2JlJm5ic3A7 PC9ESVY+DQo8RElWPiZndDsmbmJzcDtyZWRpcmVjdGVkJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDty MkxNQSZuYnNwO2FuZCZuYnNwO3doaWNoJm5ic3A7Zmxvd3MmbmJzcDtzaG91bGQmbmJzcDtiZSZu YnNwO3RyYW5zbWl0dGVkJm5ic3A7YnkmbmJzcDtpdHNlbGYuPC9ESVY+DQo8RElWPiZndDsmbmJz cDtCUiw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1poaXdlaSZuYnNwO1lhbjwvRElWPg0KPERJVj4m Z3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsyMDEwLTA3LTA4PC9ESVY+DQo8RElWPiZndDs8L0RJ Vj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtaaGl3 ZWk8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwO7eivP7Iy6O6Jm5ic3A7WGlhbmdzb25nJm5ic3A7Q3VpPC9ESVY+ DQo8RElWPiZndDsmbmJzcDu3osvNyrG85KO6Jm5ic3A7MjAxMC0wNy0wOCZuYnNwOyZuYnNwOzEx OjU0OjIzPC9ESVY+DQo8RElWPiZndDsmbmJzcDvK1bz+yMujuiZuYnNwO2dzbmFhLnYyOyZuYnNw O25ldGV4dDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7s63LzaO6PC9ESVY+DQo8RElWPiZndDsmbmJz cDvW98zio7ombmJzcDtSZTombmJzcDtbbmV0ZXh0XSZuYnNwO25ldGV4dCZuYnNwO0RpZ2VzdCwm bmJzcDtWb2wmbmJzcDsxNCwmbmJzcDtJc3N1ZSZuYnNwOzE8L0RJVj4NCjxESVY+Jmd0OzwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7SGksPC9ESVY+DQo8RElWPiZndDsmbmJzcDtJJm5ic3A7dGhpbmsm bmJzcDt0aGF0Jm5ic3A7d291bGQmbmJzcDtiZSZuYnNwO3ZlcnkmbmJzcDtkaWZmaWN1bHQuPC9E SVY+DQo8RElWPiZndDsmbmJzcDtGb3ImbmJzcDt0aGUmbmJzcDtvdXRnb2luZyZuYnNwO3RyYWZm aWMmbmJzcDtvZiZuYnNwO01OLCZuYnNwO3RoZSZuYnNwO01BRyZuYnNwO21heSZuYnNwO3VzZSZu YnNwO3RyYWZmaWMmbmJzcDtmaWx0ZXImbmJzcDt0byZuYnNwO3NwbGl0Jm5ic3A7TU4ncyZuYnNw O3RyYWZmaWMmbmJzcDt0byZuYnNwO3RoZSZuYnNwO3NlcGFyYXRlJm5ic3A7TE1BcywmbmJzcDti dXQmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtpbmNvbWluZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 dHJhZmZpYywmbmJzcDtob3cmbmJzcDtjYW4mbmJzcDt0aGUmbmJzcDtuZXR3b3JrJm5ic3A7ZW50 aXRpZXMmbmJzcDtzZW5kJm5ic3A7dGhlJm5ic3A7cGFja2V0cyZuYnNwOyhmb3ImbmJzcDtkaWZm ZXJlbnQmbmJzcDtzZXNzaW9ucykmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2NvcnJlc3BvbmRpbmcm bmJzcDtMTUE/PC9ESVY+DQo8RElWPiZndDsmbmJzcDtSZWdhcmRzLDwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7WGlhbmdzb25nPC9ESVY+DQo8RElWPiZndDsmbmJzcDstLS0tLSZuYnNwO09yaWdpbmFs Jm5ic3A7TWVzc2FnZSZuYnNwOy0tLS0tJm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtGcm9t OiZuYnNwOyJnc25hYS52MiImbmJzcDsmbHQ7Z3NuYWEudjJAMTYzLmNvbSZndDs8L0RJVj4NCjxE SVY+Jmd0OyZuYnNwO1RvOiZuYnNwOyJuZXRleHQiJm5ic3A7Jmx0O25ldGV4dEBpZXRmLm9yZyZn dDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1NlbnQ6Jm5ic3A7VGh1cnNkYXksJm5ic3A7SnVseSZu YnNwOzA4LCZuYnNwOzIwMTAmbmJzcDsxMToyOSZuYnNwO0FNPC9ESVY+DQo8RElWPiZndDsmbmJz cDtTdWJqZWN0OiZuYnNwO1JlOiZuYnNwO1tuZXRleHRdJm5ic3A7bmV0ZXh0Jm5ic3A7RGlnZXN0 LCZuYnNwO1ZvbCZuYnNwOzE0LCZuYnNwO0lzc3VlJm5ic3A7MTwvRElWPg0KPERJVj4mZ3Q7Jmd0 OyZuYnNwO1RoZSZuYnNwO3JlZGlyZWN0aW9uJm5ic3A7b2YmbmJzcDtMTUEmbmJzcDtjYW4mbmJz cDtkZWZpbml0ZWx5Jm5ic3A7aW1wcm92ZSZuYnNwO3RoZSZuYnNwO292ZXJhbGwmbmJzcDtwZXJm b3JtYW5jZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7UE1JUHY2Jm5ic3A7ZG9tYWluLCZuYnNwO2Zv ciZuYnNwO2V4YW1wbGUmbmJzcDtpdCZuYnNwO2NhbiZuYnNwO2JhbGFuY2UmbmJzcDt0aGUmbmJz cDtsb2FkPC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7YmV0d2VlbiZuYnNwO0xNQXMmbmJzcDth cyZuYnNwO1JhamVldiZuYnNwO21lbnRpb25lZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7ZHJhZnQu PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7SG93ZXZlciwmbmJzcDtzb21ldGltZXMmbmJzcDtv bmUmbmJzcDtNQUcmbmJzcDttYXkmbmJzcDtjb21tdW5pY2F0ZSZuYnNwO3dpdGgmbmJzcDt0d28m bmJzcDtMTUFzJm5ic3A7YXQmbmJzcDt0aGUmbmJzcDtzYW1lJm5ic3A7dGltZSZuYnNwO3RvJm5i c3A7cHJvdmlkZSZuYnNwO2JldHRlciZuYnNwO3NlcnZpY2UmbmJzcDtmb3ImbmJzcDthJm5ic3A7 TU4uJm5ic3A7Rm9yJm5ic3A7ZXhhbXBsZSwmbmJzcDt0aGU8L0RJVj4NCjxESVY+Jmd0OyZndDsm bmJzcDtkaWZmZXJlbnQmbmJzcDtzZXNzaW9ucyZuYnNwO29mJm5ic3A7dGhlJm5ic3A7TU4mbmJz cDtjYW4mbmJzcDtiZSZuYnNwO3NlcGFyYXRlbHkmbmJzcDtlc3RhYmxpc2hlZCZuYnNwO3Rocm91 Z2gmbmJzcDt0d28mbmJzcDtkaWZmZXJlbnQmbmJzcDtMTUFzLjwvRElWPg0KPERJVj4mZ3Q7Jmd0 OyZuYnNwO0FsdGhvdWdoJm5ic3A7dGhlJm5ic3A7ZHJhZnQmbmJzcDtzcGVjaWZpZWQmbmJzcDt0 aGF0Jm5ic3A7obBkdXJpbmcmbmJzcDt0aGUmbmJzcDtyZWRpcmVjdGlvbiZuYnNwO3Byb2Nlc3Ms Jm5ic3A7dGhlJm5ic3A7cmZMTUEmbmJzcDtNQVkmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDttYWlu dGFpbiZuYnNwO2EmbmJzcDt0ZW1wb3JhcnkmbmJzcDtNQUctcmZMTUEtcjJMTUE8L0RJVj4NCjxE SVY+Jmd0OyZndDsmbmJzcDtzdGF0ZSZuYnNwO2FuZCZuYnNwO21heSZuYnNwO2V2ZW4mbmJzcDth Y3QmbmJzcDthcyZuYnNwO2EmbmJzcDsicHJveHkmbmJzcDtNQUciJm5ic3A7dG8mbmJzcDt0aGUm bmJzcDtyMkxNQaGxLiZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3lvdSZuYnNwO2NhbiZuYnNwO3Nl dCZuYnNwO2EmbmJzcDtmbGFnJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtSZWRpcmVjdCZuYnNwO01v YmlsaXR5Jm5ic3A7T3B0aW9uJm5ic3A7dG8mbmJzcDtpbmRpY2F0ZSZuYnNwOzwvRElWPg0KPERJ Vj4mZ3Q7Jmd0OyZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO01BRyZuYnNwO3do ZXRoZXImbmJzcDt0d28mbmJzcDtCVUwmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO21haW50YWlu ZWQmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtNTiZuYnNwO29yJm5ic3A7b25seSZuYnNwO29uZSZu YnNwO0JVTCZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7ZXN0YWJsaXNoZWQmbmJzcDthdCZuYnNwO3Ro ZSZuYnNwO3NhbWUmbmJzcDt0aW1lLjwvRElWPg0KPERJVj4mZ3Q7Jmd0OzwvRElWPg0KPERJVj4m Z3Q7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwOzIwMTAtMDctMDg8L0RJVj4NCjxESVY+ Jmd0OyZndDs8L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4N CjxESVY+Jmd0OyZndDsmbmJzcDtaaGl3ZWkmbmJzcDtZYW48L0RJVj4NCjxESVY+Jmd0OyZndDs8 L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4NCjxESVY+Jmd0 OyZndDsmbmJzcDu3orz+yMujuiZuYnNwO25ldGV4dC1yZXF1ZXN0PC9ESVY+DQo8RElWPiZndDsm Z3Q7Jm5ic3A7t6LLzcqxvOSjuiZuYnNwOzIwMTAtMDctMDgmbmJzcDsmbmJzcDswMzowMTo1Mjwv RElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO8rVvP7Iy6O6Jm5ic3A7bmV0ZXh0PC9ESVY+DQo8RElW PiZndDsmZ3Q7Jm5ic3A7s63LzaO6PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A71vfM4qO6Jm5i c3A7bmV0ZXh0Jm5ic3A7RGlnZXN0LCZuYnNwO1ZvbCZuYnNwOzE0LCZuYnNwO0lzc3VlJm5ic3A7 MTwvRElWPg0KPERJVj4mZ3Q7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2RpZ2VzdCZuYnNwO3dp dGhvdXQmbmJzcDthbGwmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7bWVzc2FnZTwvRElW Pg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO2F0dGFjaG1lbnRzJm5ic3A7eW91Jm5ic3A7d2lsbCZuYnNw O25lZWQmbmJzcDt0byZuYnNwO3VwZGF0ZSZuYnNwO3lvdXImbmJzcDtkaWdlc3QmbmJzcDtvcHRp b25zJm5ic3A7aW4mbmJzcDt5b3VyJm5ic3A7bGlzdDwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNw O3N1YnNjcmlwdGlvbi4mbmJzcDsmbmJzcDtUbyZuYnNwO2RvJm5ic3A7c28sJm5ic3A7Z28mbmJz cDt0bzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0ZXh0PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7Q2xpY2smbmJzcDt0 aGUmbmJzcDsnVW5zdWJzY3JpYmUmbmJzcDtvciZuYnNwO2VkaXQmbmJzcDtvcHRpb25zJyZuYnNw O2J1dHRvbiwmbmJzcDtsb2cmbmJzcDtpbiwmbmJzcDthbmQmbmJzcDtzZXQmbmJzcDsiR2V0PC9E SVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7TUlNRSZuYnNwO29yJm5ic3A7UGxhaW4mbmJzcDtUZXh0 Jm5ic3A7RGlnZXN0cz8iJm5ic3A7dG8mbmJzcDtNSU1FLiZuYnNwOyZuYnNwO1lvdSZuYnNwO2Nh biZuYnNwO3NldCZuYnNwO3RoaXMmbmJzcDtvcHRpb248L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJz cDtnbG9iYWxseSZuYnNwO2ZvciZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO2xpc3QmbmJzcDtkaWdl c3RzJm5ic3A7eW91Jm5ic3A7cmVjZWl2ZSZuYnNwO2F0Jm5ic3A7dGhpcyZuYnNwO3BvaW50Ljwv RElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO1NlbmQmbmJzcDtuZXRleHQmbmJzcDttYWlsaW5nJm5i c3A7bGlzdCZuYnNwO3N1Ym1pc3Npb25zJm5ic3A7dG88L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJz cDtuZXRleHRAaWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtUbyZuYnNwO3N1YnNj cmliZSZuYnNwO29yJm5ic3A7dW5zdWJzY3JpYmUmbmJzcDt2aWEmbmJzcDt0aGUmbmJzcDtXb3Js ZCZuYnNwO1dpZGUmbmJzcDtXZWIsJm5ic3A7dmlzaXQ8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJz cDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDwvRElWPg0KPERJ Vj4mZ3Q7Jmd0OyZuYnNwO29yLCZuYnNwO3ZpYSZuYnNwO2VtYWlsLCZuYnNwO3NlbmQmbmJzcDth Jm5ic3A7bWVzc2FnZSZuYnNwO3dpdGgmbmJzcDtzdWJqZWN0Jm5ic3A7b3ImbmJzcDtib2R5Jm5i c3A7J2hlbHAnJm5ic3A7dG88L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtuZXRleHQtcmVxdWVz dEBpZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO1lvdSZuYnNwO2NhbiZuYnNwO3Jl YWNoJm5ic3A7dGhlJm5ic3A7cGVyc29uJm5ic3A7bWFuYWdpbmcmbmJzcDt0aGUmbmJzcDtsaXN0 Jm5ic3A7YXQ8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtuZXRleHQtb3duZXJAaWV0Zi5vcmc8 L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtXaGVuJm5ic3A7cmVwbHlpbmcsJm5ic3A7cGxlYXNl Jm5ic3A7ZWRpdCZuYnNwO3lvdXImbmJzcDtTdWJqZWN0Jm5ic3A7bGluZSZuYnNwO3NvJm5ic3A7 aXQmbmJzcDtpcyZuYnNwO21vcmUmbmJzcDtzcGVjaWZpYzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZu YnNwO3RoYW4mbmJzcDsiUmU6Jm5ic3A7Q29udGVudHMmbmJzcDtvZiZuYnNwO25ldGV4dCZuYnNw O2RpZ2VzdC4uLiI8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtfX19fX19fX19fJm5ic3A7SW5m b3JtYXRpb24mbmJzcDtmcm9tJm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLCZu YnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNwO3ZpcnVzJm5ic3A7c2lnbmF0dXJlJm5ic3A7ZGF0YWJh c2UmbmJzcDs1MDkzJm5ic3A7KDIwMTAwNTA2KSZuYnNwO19fX19fX19fX188L0RJVj4NCjxESVY+ Jmd0OyZndDsmbmJzcDtUaGUmbmJzcDttZXNzYWdlJm5ic3A7d2FzJm5ic3A7Y2hlY2tlZCZuYnNw O2J5Jm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLjwvRElWPg0KPERJVj4mZ3Q7 Jmd0OyZuYnNwO2h0dHA6Ly93d3cuZXNldC5jb208L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtU b2RheSdzJm5ic3A7VG9waWNzOjwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OzEuJm5ic3A7V0cmbmJzcDtMQyZuYnNwO29uJm5ic3A7ZHJhZnQtaWV0Zi1uZXRleHQtcmVkaXJl Y3QtMDMmbmJzcDsoUmFqZWV2Jm5ic3A7S29vZGxpKTwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNw O19fX19fX19fX18mbmJzcDtJbmZvcm1hdGlvbiZuYnNwO2Zyb20mbmJzcDtFU0VUJm5ic3A7Tk9E MzImbmJzcDtBbnRpdmlydXMsJm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7dmlydXMmbmJzcDtz aWduYXR1cmUmbmJzcDtkYXRhYmFzZSZuYnNwOzUwOTMmbmJzcDsoMjAxMDA1MDYpJm5ic3A7X19f X19fX19fXzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO1RoZSZuYnNwO21lc3NhZ2UmbmJzcDt3 YXMmbmJzcDtjaGVja2VkJm5ic3A7YnkmbmJzcDtFU0VUJm5ic3A7Tk9EMzImbmJzcDtBbnRpdmly dXMuPC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7aHR0cDovL3d3dy5lc2V0LmNvbTwvRElWPg0K PERJVj4mZ3Q7Jmd0OyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO0Zyb206Jm5i c3A7Jm5ic3A7UmFqZWV2Jm5ic3A7S29vZGxpJm5ic3A7Jmx0O3Jrb29kbGlAY2lzY28uY29tJmd0 OzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO1RvOiZuYnNwOyZuYnNwOyJuZXRleHRAaWV0Zi5v cmciJm5ic3A7Jmx0O25ldGV4dEBpZXRmLm9yZyZndDs8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJz cDtTdWJqZWN0OiZuYnNwOyZuYnNwO1tuZXRleHRdJm5ic3A7V0cmbmJzcDtMQyZuYnNwO29uJm5i c3A7ZHJhZnQtaWV0Zi1uZXRleHQtcmVkaXJlY3QtMDM8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJz cDtEYXRlOiZuYnNwOyZuYnNwO1R1ZTA2Jm5ic3A7SnVsJm5ic3A7MjAxMCZuYnNwOzE0OjMxOjUx Jm5ic3A7LTA3MDA8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtIZWxsbyZuYnNwO2ZvbGtzLDwv RElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO1dlJm5ic3A7d291bGQmbmJzcDtsaWtlJm5ic3A7dG8m bmJzcDtwcm9ncmVzcyZuYnNwO3RoaXMmbmJzcDtkcmFmdC4mbmJzcDtUaGlzJm5ic3A7aXMmbmJz cDthJm5ic3A7dGhyZWUmbmJzcDt3ZWVrJm5ic3A7TEMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2Ry YWZ0LjwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO1BsZWFzZSZuYnNwO3Byb3ZpZGUmbmJzcDt5 b3VyJm5ic3A7aW5wdXQmbmJzcDtieSZuYnNwO0p1bHkmbmJzcDsyNy4mbmJzcDtIb3BlZnVsbHks Jm5ic3A7d2UmbmJzcDtjYW4mbmJzcDtkaXNjdXNzJm5ic3A7dGhlJm5ic3A7aW5wdXQ8L0RJVj4N CjxESVY+Jmd0OyZndDsmbmJzcDtkdXJpbmcmbmJzcDt0aGUmbmJzcDttZWV0aW5nJm5ic3A7b24m bmJzcDt0aGUmbmJzcDsyOHRoLjwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO0xvb2smbmJzcDtm b3J3YXJkJm5ic3A7dG8mbmJzcDt5b3VyJm5ic3A7cmV2aWV3cy48L0RJVj4NCjxESVY+Jmd0OyZn dDsmbmJzcDtJRCZuYnNwO1VSTDombmJzcDtodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWll dGYtbmV0ZXh0LXJlZGlyZWN0LTAzLnR4dDwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO1RoYW5r cyw8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDstUmFqZWV2Jm5ic3A7KGZvciZuYnNwO2NoYWly cyk8L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJ Vj4NCjxESVY+Jmd0OyZndDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO25ldGV4dCZuYnNwO21haWxp bmcmbmJzcDtsaXN0PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7bmV0ZXh0QGlldGYub3JnPC9E SVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRleHQ8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtfX19fX19fX19fJm5ic3A7SW5m b3JtYXRpb24mbmJzcDtmcm9tJm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLCZu YnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNwO3ZpcnVzJm5ic3A7c2lnbmF0dXJlJm5ic3A7ZGF0YWJh c2UmbmJzcDs1MDkzJm5ic3A7KDIwMTAwNTA2KSZuYnNwO19fX19fX19fX188L0RJVj4NCjxESVY+ Jmd0OyZndDsmbmJzcDtUaGUmbmJzcDttZXNzYWdlJm5ic3A7d2FzJm5ic3A7Y2hlY2tlZCZuYnNw O2J5Jm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLjwvRElWPg0KPERJVj4mZ3Q7 Jmd0OyZuYnNwO2h0dHA6Ly93d3cuZXNldC5jb208L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4N CjxESVY+Jmd0OyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZndDsm Z3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtuZXRleHQmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwv RElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO25ldGV4dEBpZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7 Jmd0OyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0PC9E SVY+DQo8RElWPiZndDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtfX19fX19fX19fJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtmcm9tJm5ic3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVz LCZuYnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNwO3ZpcnVzJm5ic3A7c2lnbmF0dXJlJm5ic3A7ZGF0 YWJhc2UmbmJzcDs1MDkzJm5ic3A7KDIwMTAwNTA2KSZuYnNwO19fX19fX19fX188L0RJVj4NCjxE SVY+Jmd0OyZuYnNwO1RoZSZuYnNwO21lc3NhZ2UmbmJzcDt3YXMmbmJzcDtjaGVja2VkJm5ic3A7 YnkmbmJzcDtFU0VUJm5ic3A7Tk9EMzImbmJzcDtBbnRpdmlydXMuPC9ESVY+DQo8RElWPiZndDsm bmJzcDtodHRwOi8vd3d3LmVzZXQuY29tPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+PC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZndDsmbmJzcDtfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bmV0ZXh0 Jm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO25ldGV4dEBpZXRm Lm9yZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRleHQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj48L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPl9fX19fX19fX18mbmJzcDtJbmZvcm1hdGlvbiZuYnNwO2Zyb20m bmJzcDtFU0VUJm5ic3A7Tk9EMzImbmJzcDtBbnRpdmlydXMsJm5ic3A7dmVyc2lvbiZuYnNwO29m Jm5ic3A7dmlydXMmbmJzcDtzaWduYXR1cmUmbmJzcDtkYXRhYmFzZSZuYnNwOzUwOTMmbmJzcDso MjAxMDA1MDYpJm5ic3A7X19fX19fX19fXzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhlJm5i c3A7bWVzc2FnZSZuYnNwO3dhcyZuYnNwO2NoZWNrZWQmbmJzcDtieSZuYnNwO0VTRVQmbmJzcDtO T0QzMiZuYnNwO0FudGl2aXJ1cy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPmh0dHA6Ly93d3cu ZXNldC5jb208L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj48L0ZP TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon827811816704_=====-- From Xiangsong.Cui@huawei.com Thu Jul 8 00:13:50 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 504433A677C for ; Thu, 8 Jul 2010 00:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.332 X-Spam-Level: *** X-Spam-Status: No, score=3.332 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 GflJbnPUE4Bb for ; Thu, 8 Jul 2010 00:13:48 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id F13AA3A6359 for ; Thu, 8 Jul 2010 00:13:47 -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 <0L5800M7X9BVOF@szxga03-in.huawei.com> for netext@ietf.org; Thu, 08 Jul 2010 15:11:55 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5800HMI9BU9L@szxga03-in.huawei.com> for netext@ietf.org; Thu, 08 Jul 2010 15:11:55 +0800 (CST) Date: Thu, 08 Jul 2010 15:11:54 +0800 From: Xiangsong Cui To: "gsnaa.v2" Message-id: <013d01cb1e6c$d8b653c0$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <201007081129470626009@163.com> <201007081402594841109@163.com> <00f701cb1e65$35ebff20$96106f0a@china.huawei.com> <201007081502049378775@163.com> Cc: netext Subject: Re: [netext] netext Digest, Vol 14, Issue 1 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: Thu, 08 Jul 2010 07:13:50 -0000 I think that would be a high cost and low benefit function. The intention of redirection item is binding registration redirection, not cover forwarding redirection. Regards Xiangsong ----- Original Message ----- From: "gsnaa.v2" To: "Xiangsong Cui" Cc: "netext" Sent: Thursday, July 08, 2010 3:02 PM Subject: Re: Re: [netext] netext Digest, Vol 14, Issue 1 > Hi, > Exactly, the cascade connection between rfLMA and r2LMA can be used to separate the packet transmission paths. That is feasible > because the LMAs are all limited into the “Redirection Domain”. > BR, > Zhiwei Yan > > > 2010-07-08 > > > > Zhiwei > > > > 发件人： Xiangsong Cui > 发送时间： 2010-07-08 14:17:16 > 收件人： gsnaa.v2 > 抄送： netext > 主题： Re: [netext] netext Digest, Vol 14, Issue 1 > > Do you mean cascade connection? > The packets go through one LMA and later another one? > Xiangsong > ----- Original Message ----- > From: "gsnaa.v2" > To: "Xiangsong Cui" > Cc: "netext" > Sent: Thursday, July 08, 2010 2:03 PM > Subject: Re: [netext] netext Digest, Vol 14, Issue 1 >> Hi, >> As a method, the rfLMA can act as a “proxy MAG”. After the registration process, the rfLMA can know that which flows should be >> redirected to the r2LMA and which flows should be transmitted by itself. >> BR, >> Zhiwei Yan >> >> 2010-07-08 >> >> >> >> Zhiwei >> >> >> >> 发件人： Xiangsong Cui >> 发送时间： 2010-07-08 11:54:23 >> 收件人： gsnaa.v2; netext >> 抄送： >> 主题： Re: [netext] netext Digest, Vol 14, Issue 1 >> >> Hi, >> I think that would be very difficult. >> For the outgoing traffic of MN, the MAG may use traffic filter to split MN's traffic to the separate LMAs, but for the incoming >> traffic, how can the network entities send the packets (for different sessions) to the corresponding LMA? >> Regards, >> Xiangsong >> ----- Original Message ----- >> From: "gsnaa.v2" >> To: "netext" >> Sent: Thursday, July 08, 2010 11:29 AM >> Subject: Re: [netext] netext Digest, Vol 14, Issue 1 >>> The redirection of LMA can definitely improve the overall performance of the PMIPv6 domain, for example it can balance the load >>> between LMAs as Rajeev mentioned in the draft. >>> However, sometimes one MAG may communicate with two LMAs at the same time to provide better service for a MN. For example, the >>> different sessions of the MN can be separately established through two different LMAs. >>> Although the draft specified that “during the redirection process, the rfLMA MAY need to maintain a temporary MAG-rfLMA-r2LMA >>> state and may even act as a "proxy MAG" to the r2LMA”. I think you can set a flag in the Redirect Mobility Option to indicate >>> the >>> MAG whether two BUL should be maintained for the MN or only one BUL can be established at the same time. >>> >>> >>> 2010-07-08 >>> >>> >>> >>> Zhiwei Yan >>> >>> >>> >>> 发件人： netext-request >>> 发送时间： 2010-07-08 03:01:52 >>> 收件人： netext >>> 抄送： >>> 主题： netext Digest, Vol 14, Issue 1 >>> >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>> https://www.ietf.org/mailman/listinfo/netext >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>> Send netext mailing list submissions to >>> netext@ietf.org >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/netext >>> or, via email, send a message with subject or body 'help' to >>> netext-request@ietf.org >>> You can reach the person managing the list at >>> netext-owner@ietf.org >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of netext digest..." >>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ >>> The message was checked by ESET NOD32 Antivirus. >>> http://www.eset.com >>> Today's Topics: >>> 1. WG LC on draft-ietf-netext-redirect-03 (Rajeev Koodli) >>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ >>> The message was checked by ESET NOD32 Antivirus. >>> http://www.eset.com >>> ------------------------------------------------------------ >>> From: Rajeev Koodli >>> To: "netext@ietf.org" >>> Subject: [netext] WG LC on draft-ietf-netext-redirect-03 >>> Date: Tue06 Jul 2010 14:31:51 -0700 >>> Hello folks, >>> We would like to progress this draft. This is a three week LC on the draft. >>> Please provide your input by July 27. Hopefully, we can discuss the input >>> during the meeting on the 28th. >>> Look forward to your reviews. >>> ID URL: http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt >>> Thanks, >>> -Rajeev (for chairs) >>> >>> ------------------------------------------------------------ >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ >>> The message was checked by ESET NOD32 Antivirus. >>> http://www.eset.com >>> >> -------------------------------------------------------------------------------- >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ >> The message was checked by ESET NOD32 Antivirus. >> http://www.eset.com >> > -------------------------------------------------------------------------------- >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __________ > The message was checked by ESET NOD32 Antivirus. > http://www.eset.com > From huimin.cmcc@gmail.com Thu Jul 8 19:40:32 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 450463A69F2 for ; Thu, 8 Jul 2010 19:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urbQIWWFHRfh for ; Thu, 8 Jul 2010 19:40:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 7B9BE3A6816 for ; Thu, 8 Jul 2010 19:40:31 -0700 (PDT) Received: by gxk3 with SMTP id 3so1014240gxk.31 for ; Thu, 08 Jul 2010 19:40:32 -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=yrjpQdwhoHTdppaENyHoJXW9Iy83hnUhE7dVKdvekU0=; b=aJA6Hg/OBLLvEAhl5lrDpU+S455vvo+K+mVE91b6wQ6LjDClmziqQeZ6AzBKETY1lI xW3/jUifLMV3FMxgBnHuM0cVT4GlKllr2fysb/OAK98kaM4VUZovugvNAXQLV7XM+KsB K82F79gMHJOeQUTVZXUuUD3A0pSphrX7vsFOg= 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=kTv8rlZTxxbvaUqwDWc3DtWZisNAHOcVLAic7j5hTmCULSdjn/bYUOm6nC6Nbw6CnY kCmPNnjzPcB3rPqZuXqDulRPPloSfiXkyjfLok/lLCyz7hZpSyZLZcjYvvOyJsVxHFur s0I3b08GxopWixOtkk98uwa8CbPqP5GuQanjM= MIME-Version: 1.0 Received: by 10.229.188.71 with SMTP id cz7mr5627291qcb.6.1278643232497; Thu, 08 Jul 2010 19:40:32 -0700 (PDT) Received: by 10.229.227.140 with HTTP; Thu, 8 Jul 2010 19:40:32 -0700 (PDT) In-Reply-To: <20100701104155.6E4EF28C118@core3.amsl.com> References: <20100701104155.6E4EF28C118@core3.amsl.com> Date: Fri, 9 Jul 2010 10:40:32 +0800 Message-ID: From: Min Hui To: netext Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [netext] New Version Notification for draft-hui-netext-service-flow-identifier-03 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, 09 Jul 2010 02:40:32 -0000 Hi, all A new version of I-D, draft-hui-netext-service-flow-identifier-03.txt has been successfully submitted by Min Hui and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-hui-netext-service-flow-identifier Revision: =A0 =A0 =A0 =A003 Title: =A0 =A0 =A0 =A0 =A0 Service Flow Identifier in Proxy Mobile IPv6 Creation_date: =A0 2010-07-01 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 19 Abstract: This document proposes extensions to Proxy Mobile IPv6 that allows service flow identification and binding, and PMIP tunnels will be set up based on the service flow granularity. Therefore, multiple service flows of the mobile node can be separately controlled, e.g. QoS, charging, traffic control, and provides the precondition of flow mobility among multiple interfaces of the mobile node. The IETF Secretariat. From Basavaraj.Patil@nokia.com Fri Jul 9 05:48: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 2792A3A6A6E for ; Fri, 9 Jul 2010 05:48:22 -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 thym-bQ3LWSr for ; Fri, 9 Jul 2010 05:48:21 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BE1603A6A6C for ; Fri, 9 Jul 2010 05:48:20 -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 o69CmM3f019975 for ; Fri, 9 Jul 2010 15:48:23 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 15:48:22 +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); Fri, 9 Jul 2010 15:48:15 +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; Fri, 9 Jul 2010 14:48:15 +0200 From: To: Date: Fri, 9 Jul 2010 14:48:13 +0200 Thread-Topic: Flow mobility I-D Thread-Index: AcsfZP4SZ/HhmMuGsU+2tgnLSSSE4A== 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: 09 Jul 2010 12:48:15.0407 (UTC) FILETIME=[FF81ABF0:01CB1F64] X-Nokia-AV: Clean Subject: [netext] Flow mobility I-D 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, 09 Jul 2010 12:48:22 -0000 Hello, One of our milestones is : Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces In order to make progress towards this milestone, we are taking the following approach: We have nominated Carlos Bernardos as the editor for the document which describes a mechanism to support flow mobility on a logical interface over multiple physical interfaces. The list of authors contributing to this I-D include: Mohana Jeyatharan, Rajeev Koodli, Telemaco Melia and Frank Xia. The contributing author list is based on an analysis of multiple I-Ds that proposed solutions for flow mobility and the scope of the work being undertaken in this WG. After whittling down the list we have picked one person from the author-list of each I-D (based on their willingness to work on the I-D) as co-authors for this I-D. Carlos has done the analysis of the various I-Ds based on the scope of the work defined and the milestone. Carlos has submitted the I-D: draft-bernardos-netext-pmipv6-flowmob-00 We will seek WG consensus to consider this as the working group document associated with the above milestone at IETF78. -Basavaraj From root@core3.amsl.com Sat Jul 10 12:30:13 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 E57853A6A47; Sat, 10 Jul 2010 12:30:05 -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: <20100710193012.E57853A6A47@core3.amsl.com> Date: Sat, 10 Jul 2010 12:30:06 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-bulk-re-registration-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: Sat, 10 Jul 2010 19:30:15 -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-01.txt Pages : 16 Date : 2010-07-10 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-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-bulk-re-registration-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-10121649.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 03:00:02 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 594AE3A67E9; Mon, 12 Jul 2010 03:00: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: <20100712100002.594AE3A67E9@core3.amsl.com> Date: Mon, 12 Jul 2010 03:00:02 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-03.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, 12 Jul 2010 10:00:02 -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 : PMIPv6 Localized Routing Problem Statement Author(s) : M. Liebsch, et al. Filename : draft-ietf-netext-pmip6-lr-ps-03.txt Pages : 17 Date : 2010-07-12 Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-03.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-pmip6-lr-ps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12024933.I-D@ietf.org> --NextPart-- From Basavaraj.Patil@nokia.com Tue Jul 13 16:13: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 51DA13A69EF for ; Tue, 13 Jul 2010 16:13:14 -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 DfdFTANPqXuL for ; Tue, 13 Jul 2010 16:13:13 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1CFA33A69E5 for ; Tue, 13 Jul 2010 16:13:12 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6DNDItI013077 for ; Wed, 14 Jul 2010 02:13:20 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 02:13:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 02:13:14 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 14 Jul 2010 01:13:13 +0200 From: To: Date: Wed, 14 Jul 2010 01:13:10 +0200 Thread-Topic: Localized routing Solution I-D Thread-Index: Acsi4PWtmjGvlIbHWEOP8FZ0H6rtfw== 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: 13 Jul 2010 23:13:14.0296 (UTC) FILETIME=[F83D0B80:01CB22E0] X-Nokia-AV: Clean Subject: [netext] Localized routing Solution I-D 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, 13 Jul 2010 23:13:14 -0000 Hello, We would like to propose the adoption of I-D: http://tools.ietf.org/html/draft-krishnan-netext-pmip-lr-02 as the WG baseline document. Please review and provide feedback. We will ask WG consensus for making thi= s the WG document at IETF78. -Basavaraj From gwz@net-zen.net Tue Jul 13 21:17:12 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 0F3C33A6910 for ; Tue, 13 Jul 2010 21:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.687, 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 U0zciNkZ-RI8 for ; Tue, 13 Jul 2010 21:17:11 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 4DF4C3A68E0 for ; Tue, 13 Jul 2010 21:17:11 -0700 (PDT) Received: (qmail 1853 invoked from network); 14 Jul 2010 04:17:19 -0000 Received: from unknown (124.157.141.21) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 14 Jul 2010 04:17:18 -0000 From: "Glen Zorn" To: References: In-Reply-To: Date: Wed, 14 Jul 2010 11:16:50 +0700 Organization: Network Zen Message-ID: <001801cb230b$63d4e460$2b7ead20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsi4PWtmjGvlIbHWEOP8FZ0H6rtfwAKhtTQ Content-Language: en-us Cc: netext@ietf.org Subject: Re: [netext] Localized routing Solution I-D 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, 14 Jul 2010 04:17:12 -0000 Basavaraj Patil [mailto://Basavaraj.Patil@nokia.com] writes: > Hello, > > We would like to propose the adoption of I-D: > http://tools.ietf.org/html/draft-krishnan-netext-pmip-lr-02 as the WG > baseline document. > > Please review and provide feedback. We will ask WG consensus for making > this > the WG document at IETF78. Surely you mean that you will "ask for WG consensus for making this a WG document _after_ IETF 78"? > > -Basavaraj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Wed Jul 14 07:09:02 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 4369A3A69BE for ; Wed, 14 Jul 2010 07:09:02 -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 iwFN39EUTcFm for ; Wed, 14 Jul 2010 07:08:58 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id EE2C93A6A53 for ; Wed, 14 Jul 2010 07:08:57 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6EE8aMJ007796; Wed, 14 Jul 2010 17:09:05 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 17:09:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 17:08:55 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 14 Jul 2010 16:08:55 +0200 From: To: Date: Wed, 14 Jul 2010 16:08:53 +0200 Thread-Topic: [netext] Localized routing Solution I-D Thread-Index: Acsi4PWtmjGvlIbHWEOP8FZ0H6rtfwAKhtTQABTBgMg= Message-ID: In-Reply-To: <001801cb230b$63d4e460$2b7ead20$@net> 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: 14 Jul 2010 14:08:55.0792 (UTC) FILETIME=[18AA8F00:01CB235E] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Localized routing Solution I-D 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, 14 Jul 2010 14:09:02 -0000 Hi Glen, We will seek consensus at the Netext WG meeting (at IETF78) as well as on the ML as per standard operating procedures. -Raj On 7/13/10 11:16 PM, "ext Glen Zorn" wrote: > Basavaraj Patil [mailto://Basavaraj.Patil@nokia.com] writes: >=20 >> Hello, >>=20 >> We would like to propose the adoption of I-D: >> http://tools.ietf.org/html/draft-krishnan-netext-pmip-lr-02 as the WG >> baseline document. >>=20 >> Please review and provide feedback. We will ask WG consensus for making >> this >> the WG document at IETF78. >=20 > Surely you mean that you will "ask for WG consensus for making this a WG > document _after_ IETF 78"? >=20 >>=20 >> -Basavaraj >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 >=20 From trungtm2909@gmail.com Wed Jul 14 19:42:30 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 898793A68B5 for ; Wed, 14 Jul 2010 19:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[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 e8-ueV43vJ+Z for ; Wed, 14 Jul 2010 19:42:29 -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 9D3623A684A for ; Wed, 14 Jul 2010 19:42:29 -0700 (PDT) Received: by iwn38 with SMTP id 38so505533iwn.31 for ; Wed, 14 Jul 2010 19:42:39 -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=EEBLyQc8wop6rHKNVBujaFeK+q/2rz6xe5AGf/yGMRU=; b=tqXxY2uZkG4yXHknZuouIiLAF/9SUBPYmAcBm1V02kNcBUeJ7foMIDijFRY0mK3cRh 2aszFst+rOcryDbu/qQvk92PcLmoEM7n116hdU5qb9WwpfZ4m3aJ8yHW7DyVckL7Kpx7 2FKjhs4r/mb9D6tSKJKJoImiQO93rA+SQJN/Q= 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=Og31jYaNopVnBoaTyxoBRNb4M66tzcApcPGIDY+zSy579ie1p66xB90bwyj4rGos4X RgMSDV8pSrxE8acl8rz2sOSV3PyCs02UPCdu9aj6TRu4uedWV6MLrsmfoPzq5GxMgbTU knE2EYSVC/y46pCl44YxABJ8itnBeJK/+RqDo= MIME-Version: 1.0 Received: by 10.231.34.70 with SMTP id k6mr8428080ibd.25.1279161758608; Wed, 14 Jul 2010 19:42:38 -0700 (PDT) Sender: trungtm2909@gmail.com Received: by 10.231.185.32 with HTTP; Wed, 14 Jul 2010 19:42:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Jul 2010 11:42:38 +0900 X-Google-Sender-Auth: EkBR2ZvgtvOfUhU_LmQYIK2wIOY Message-ID: From: Tran Minh Trung To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Agenda requests for IETF78 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: Thu, 15 Jul 2010 02:42:30 -0000 Dear Chairs, I would like to request a time slot of 10' for presenting the I-D: draft-trung-netext-flow-tracking-01.txt Thank you very much. Regards, Tran Minh Trung On Tue, Jun 29, 2010 at 7:20 AM, wrote: > > Hello, > > The Netext WG will meet at IETF78. Emphasis will be on the working group > documents and topics that are within the scope of the charter and > milestones. If you need a timeslot to present an I-D, please send a reque= st > to netext-chairs@tools.ietf.org > > Note that you need to have an I-D in order to request a timeslot. > Please specify the amount of time that you need and also how the I-D itse= lf > is relevant within the context of the netext charter and/or milestones. > > Also it is always useful to have some interest and discussion via the WG = ML. > > -Chairs > > _______________________________________________ > 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 Basavaraj.Patil@nokia.com Sat Jul 17 14:02:59 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 CF62A3A69E5 for ; Sat, 17 Jul 2010 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 TLcywuGw0kuM for ; Sat, 17 Jul 2010 14:02:59 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id DB6D43A69E2 for ; Sat, 17 Jul 2010 14:02:58 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6HL2wPQ015055 for ; Sat, 17 Jul 2010 16:03:10 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Jul 2010 23:59:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Jul 2010 23:59:34 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Sat, 17 Jul 2010 22:59:33 +0200 From: To: Date: Sat, 17 Jul 2010 22:59:31 +0200 Thread-Topic: Draft agenda of the Netext WG meeting at IETF78 Thread-Index: Acsl8vOi1bNNdB8FZUuuyUYCIZUxHA== 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: 17 Jul 2010 20:59:34.0144 (UTC) FILETIME=[F581F800:01CB25F2] X-Nokia-AV: Clean Subject: [netext] Draft agenda of the Netext WG meeting at IETF78 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: Sat, 17 Jul 2010 21:02:59 -0000 Below is the draft agenda. If I have missed some requests for an agenda slot, please do remind me again. Rgds, -Chairs Draft agenda (Rev 1) Network-Based Mobility Extensions WG meeting WEDNESDAY, July 28, 2010 1300-1530 Afternoon Session I (0.9 Athens) --------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG status update Chairs 5 Mins 3. Runtime LMA selection I-D update Jouni Korhonen 5 Mins I-D: draft-ietf-netext-redirect-03 4. Bulk re-reg I-D update and next steps Fuad Junior 5 Mins I-D: draft-ietf-netext-bulk-re-registration-01 5. Radius extensions for PMIP6 Frank Xia 5 Mins I-D: draft-ietf-netext-radius-pmip6-00 6. Localized routing PS I-D 5 Mins I-D: draft-ietf-netext-pmip6-lr-ps-03 7. Localized routing solution I-D Suresh K. 20 Mins I-D: draft-krishnan-netext-pmip-lr-02 8. Proxy Mobile IPv6 Extensions to Support Flow Mobility Carlos Bernardos 15 Mins I-D: draft-bernardos-netext-pmipv6-flowmob-00 9. Logical Interface Support for multi-mode IP Hosts Telemaco Melia 15 Mins I-D: draft-melia-netext-logical-interface-support-01.txt Proposals for WG consideration: 1. Service Flow Identifier in Proxy Mobile IPv6 Hui Min 5 Mins I-D: draft-hui-netext-service-flow-identifier-03 2. Flow tracking procedure for PMIPv6 Tran Trung 5 Mins I-D: draft-trung-netext-flow-tracking-01 3. Hybrid HNP for multihoming in PMIPv6 Yong-Geun Hong 5 Mins I-D: draft-hong-netext-hybrid-hnp-02 4. Scenarios of the usage of multiple HNPs on a logical interface Yong Geun Hong 5 Mins I-D: draft-hong-netext-scenario-logical-interface-01 From rkoodli@cisco.com Mon Jul 19 10:37:34 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 96F933A6B2A for ; Mon, 19 Jul 2010 10:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.551 X-Spam-Level: X-Spam-Status: No, score=-9.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7hO0AxnWYNHt for ; Mon, 19 Jul 2010 10:37:33 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 89C803A6958 for ; Mon, 19 Jul 2010 10:37:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoFABoqREytJV2c/2dsb2JhbACBRJ1KWXGqEZp8hSUEhACEV4I0 X-IronPort-AV: E=Sophos;i="4.55,227,1278288000"; d="scan'208,217";a="134274792" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 19 Jul 2010 17:37:47 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6JHbksJ028540 for ; Mon, 19 Jul 2010 17:37:47 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jul 2010 13:36:19 -0400 Received: from 10.21.71.185 ([10.21.71.185]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Jul 2010 17:35:34 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 19 Jul 2010 10:44:00 -0700 From: Rajeev Koodli To: "netext@ietf.org" Message-ID: Thread-Topic: [netext] WG LC on draft-ietf-netext-redirect-03 Thread-Index: AcsdUqVrO8fBUqLvpkmK+HWtlsKSHgKF1LRB In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3362381041_37179324" X-OriginalArrivalTime: 19 Jul 2010 17:36:19.0273 (UTC) FILETIME=[E59FD390:01CB2768] Subject: Re: [netext] WG LC on draft-ietf-netext-redirect-03 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, 19 Jul 2010 17:37:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3362381041_37179324 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Folks, Reminder about the LC. We need input, please provide. Thanks, -Rajeev On 7/6/10 2:31 PM, "Rajeev Koodli" wrote: > > Hello folks, > > We would like to progress this draft. This is a three week LC on the draft. > Please provide your input by July 27. Hopefully, we can discuss the input > during the meeting on the 28th. > > Look forward to your reviews. > > ID URL: http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt > > Thanks, > > -Rajeev (for chairs) > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --B_3362381041_37179324 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [netext] WG LC on draft-ietf-netext-redirect-03
Folks,

Reminder about the LC. We need input, please provide.

Thanks,

-Rajeev



On 7/6/10 2:31 PM, "Rajeev Koodli" <rkoodli@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>
Hello folks,

We would like to progress this draft. This is a three week LC on the draft.=
Please provide your input by July 27. Hopefully, we can discuss the input d= uring the meeting on the 28th.

Look forward to your reviews.

ID URL: = http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt

Thanks,

-Rajeev (for chairs)


 
___________= ____________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org= /mailman/listinfo/netext
--B_3362381041_37179324-- From trungtm2909@gmail.com Tue Jul 20 01:44:00 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 5F4953A68AB for ; Tue, 20 Jul 2010 01:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.118 X-Spam-Level: X-Spam-Status: No, score=-100.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 ISVxJ74Oyywa for ; Tue, 20 Jul 2010 01:43:58 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id A12FA3A67A4 for ; Tue, 20 Jul 2010 01:43:58 -0700 (PDT) Received: by gwj19 with SMTP id 19so2878127gwj.31 for ; Tue, 20 Jul 2010 01:44:10 -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:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8eu3U5JPDJC3Rp+PwRrv1Rzg30youwKVhd6X+PGn1zE=; b=XKL9F7AToQGMcENQk9jS2/fROSUfm4eBim6k2SjrQRLJkI3ND5Jnd0bVhhde2t7Vyf b0gupL9TZgeRtXeI5mYGyXFltJLdC5ZFINNwqgNnjZD60aTVsHmM72oevn+fEDoHQo5z vsg/qiQZNhXvxFioL4Ete0M/wAUy0pVthRNzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=rb1NF3//Z7HRQLn/xTAW1y6ojU92tA48SiZXSyLFygCfb1hyBpD2CvihVlRp7JrnhI 3cgtaqVDZXEIGVuZim/mpsuYUJL0dx9kURc8VFylKBWJCYTVs7UsrOJEyKuhBaMuTC0w cUgVc1nNCKtTh2yxCVlx7vMVCz/J6yBJSwC/w= MIME-Version: 1.0 Received: by 10.100.104.2 with SMTP id b2mr5981623anc.126.1279615450748; Tue, 20 Jul 2010 01:44:10 -0700 (PDT) Sender: trungtm2909@gmail.com Received: by 10.231.185.32 with HTTP; Tue, 20 Jul 2010 01:44:10 -0700 (PDT) Date: Tue, 20 Jul 2010 17:44:10 +0900 X-Google-Sender-Auth: lGR4QIOmZUydy553DmeNrssWg9g Message-ID: From: Tran Minh Trung To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 08:44:01 -0000 Hi Bernardos and all, I have some comments and questions on the I-D draft-bernardos-netext-pmipv6-flowmob-00 as follows: 1) I think the LMA can decide to move down-link flows only. The up-link flows should be moved by the MN (eg. the MN is aware of the attachment status via each IF and decide which IF is better for sending up-link flows). The MAG should be aware of the movement of up-link flows and inform the LMA to update information. 2) It is necessary to discuss about the flow mobility triggers. The signaling procedure between MAG/LMA depends on trigger. With different kind of trigger we have to use different signaling procedure. 3) The proposed solution requires new signaling messages and new caching table. It makes more complicated for implementing and combining with the existing standard than just extending the current PBU/PBA messages as well as BCE and BULE caching table. 4) What are the necessary requirements of the logical interface to support flow mobility? I hope that we can have more discussion on these issues before making it as a WG document. Regards, Tran Minh Trung --=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 Jul 20 09:05: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 BF9503A688F for ; Tue, 20 Jul 2010 09:05:22 -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 iGhJ803rwTEo for ; Tue, 20 Jul 2010 09:05:15 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 403693A69F1 for ; Tue, 20 Jul 2010 09:05:13 -0700 (PDT) X-uc3m-safe: yes Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 9D7676FB8BC; Tue, 20 Jul 2010 18:05:24 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Tran Minh Trung In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ojLijxLC9fo/9hhLzDrd" Organization: Universidad Carlos III de Madrid Date: Tue, 20 Jul 2010 18:06:36 +0200 Message-ID: <1279641996.2828.314.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17518.000 Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 16:05:22 -0000 --=-ojLijxLC9fo/9hhLzDrd Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Tran Minh, On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > Hi Bernardos and all, >=20 > I have some comments and questions on the I-D > draft-bernardos-netext-pmipv6-flowmob-00 as follows: Thanks a lot for the feedback. Please see some comments inline below. >=20 > 1) I think the LMA can decide to move down-link flows only. The > up-link flows should be moved by the MN (eg. the MN is aware of the > attachment status via each IF and decide which IF is better for > sending up-link flows). The MAG should be aware of the movement of Our assumption is that the MN does implement the logical interface (as explained in draft-melia-netext-logical-interface-support-01). The LMA has of course the direct control of how downlink flows are routed, but an MN implementing the logical interface will just mirror that behavior with the uplink packets. Therefore, the LMA is the only entity controlling flow mobility both in downlink and uplink directions. > up-link flows and inform the LMA to update information. In the current draft, the MAG is informed about flow mobility operations by the LMA. There is signaling defined for that purpose. >=20 > 2) It is necessary to discuss about the flow mobility triggers. The > signaling procedure between MAG/LMA depends on trigger. With different > kind of trigger we have to use different signaling procedure. The trigger is out of the scope of the solution draft. Any kind of trigger could be supported. For example a central policy entity can make the decisions based on the overall state of the network and trigger the LMA. IMHO, which entity triggers the LMA can be left out of the scope, as it does not have an impact on the protocol (with current design). >=20 > 3) The proposed solution requires new signaling messages and new > caching table. It makes more complicated for implementing and > combining with the existing standard than just extending the current > PBU/PBA messages as well as BCE and BULE caching table. Well, this was a design decision (there might be of course others). We preferred not to overload existing signaling. Regarding the data structures, they are just logical ones, they could also even be implemented by extending BCE and BUL. >=20 > 4) What are the necessary requirements of the logical interface to > support flow mobility? This should be covered by draft-melia-netext-logical-interface-support-01. >=20 > I hope that we can have more discussion on these issues before making > it as a WG document. Sure, useful discussion as this is very very welcome. Thanks! Kind Regards, Carlos >=20 > Regards, > Tran Minh Trung >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-ojLijxLC9fo/9hhLzDrd 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) iEYEABECAAYFAkxFyYwACgkQNdy6TdFwT2e/IgCeIssVdZ+ttz7Sz0CdsDnOW04K 1jsAoLexfFjq6AYKi65v7Ma/rWpJhtEJ =zuLl -----END PGP SIGNATURE----- --=-ojLijxLC9fo/9hhLzDrd-- From julienl@qualcomm.com Tue Jul 20 09:32:03 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 4ACC73A68EC for ; Tue, 20 Jul 2010 09:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 xqz0WtkXbqwj for ; Tue, 20 Jul 2010 09:32:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 469113A6878 for ; Tue, 20 Jul 2010 09:32: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=1279643534; x=1311179534; 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:=20"cjbc@it.uc3m.es"=20,=20Tran=20Mi nh=20Trung=20|CC:=20"netext@ietf.org" =20|Date:=20Tue,=2020=20Jul=202010=2009: 32:01=20-0700|Subject:=20RE:=20[netext]=20Comments=20&=20 Questions=20on=20the=20I-D:=0D=0A=20draft-bernardos-netex t-pmipv6-flowmob-00|Thread-Topic:=20[netext]=20Comments =20&=20Questions=20on=20the=20I-D:=0D=0A=20draft-bernardo s-netext-pmipv6-flowmob-00|Thread-Index:=20AcsoJWjkq+bt3W r5TBKXRhssTWvkxwAATGJg|Message-ID:=20 |References:=20=0D=0A=20<1279641996.2828.314.camel@a corde.it.uc3m.es>|In-Reply-To:=20<1279641996.2828.314.cam el@acorde.it.uc3m.es>|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-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=UMEEdWiUAk/EF/9NGo5SNOp/2m5GW19Gf9eFvyMyoUw=; b=exY/gqHZiZjDunYKSr2+iUHloqLzxIkBYmRrU5vHPasZzv25C5ggLRyU 5EIjqrDfkWutIykAdNMGQHbJ1j6OYLNGLrdY2LrWcTwgqu95ltizHvEKc H995o7wjiBZFuxG1mZcjlvulHytiIv6NeoXrMsLT6n79Y71L9MHXCIVeU s=; X-IronPort-AV: E=McAfee;i="5400,1158,6048"; a="47903686" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 20 Jul 2010 09:32:12 -0700 X-IronPort-AV: E=Sophos;i="4.55,232,1278313200"; d="scan'208";a="44676814" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jul 2010 09:32:12 -0700 Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 09:32:14 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 20 Jul 2010 09:32:13 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Tue, 20 Jul 2010 09:32:03 -0700 From: "Laganier, Julien" To: "cjbc@it.uc3m.es" , Tran Minh Trung Date: Tue, 20 Jul 2010 09:32:01 -0700 Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcsoJWjkq+bt3Wr5TBKXRhssTWvkxwAATGJg Message-ID: References: <1279641996.2828.314.camel@acorde.it.uc3m.es> In-Reply-To: <1279641996.2828.314.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 Cc: "netext@ietf.org" Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 16:32:03 -0000 Hi Carlos, One question below - Carlos Jes=FAs Bernardos Cano wrote: >=20 > Hi Tran Minh, >=20 > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > > Hi Bernardos and all, > > > > I have some comments and questions on the I-D > > draft-bernardos-netext-pmipv6-flowmob-00 as follows: >=20 > Thanks a lot for the feedback. Please see some comments inline below. >=20 > > 1) I think the LMA can decide to move down-link flows only. The > > up-link flows should be moved by the MN (eg. the MN is aware of the > > attachment status via each IF and decide which IF is better for > > sending up-link flows). The MAG should be aware of the movement of >=20 > Our assumption is that the MN does implement the logical interface (as > explained in draft-melia-netext-logical-interface-support-01). The LMA > has of course the direct control of how downlink flows are routed, but > an MN implementing the logical interface will just mirror that behavior > with the uplink packets. Therefore, the LMA is the only entity > controlling flow mobility both in downlink and uplink directions. >=20 > > up-link flows and inform the LMA to update information. >=20 > In the current draft, the MAG is informed about flow mobility > operations by the LMA. There is signaling defined for that purpose. Why does the LMA needs to inform the MAG about flow mobility operations? It seems to me that these operations are essentially transparent to the MAG= and thus the MAG needs not to be involved at all in flow mobility: The LMA= decides where to send downlink packets, and the MN mirrors that behavior f= or uplink packet (as described in the logical interface draft.) --julien From cjbc@it.uc3m.es Tue Jul 20 10:21:18 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 7B97A3A6992 for ; Tue, 20 Jul 2010 10:21:18 -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 RjsCTTaDTEhE for ; Tue, 20 Jul 2010 10:21:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BE3A73A6832 for ; Tue, 20 Jul 2010 10:21:16 -0700 (PDT) X-uc3m-safe: yes Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 518C7BE66A4; Tue, 20 Jul 2010 19:21:30 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Laganier, Julien" In-Reply-To: References: <1279641996.2828.314.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-j09/cTqeKIzFXqS1GSTQ" Organization: Universidad Carlos III de Madrid Date: Tue, 20 Jul 2010 19:22:39 +0200 Message-ID: <1279646559.2828.7.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17518.000 Cc: netext@ietf.org, Tran Minh Trung Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 17:21:18 -0000 --=-j09/cTqeKIzFXqS1GSTQ Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Tue, 2010-07-20 at 09:32 -0700, Laganier, Julien wrote: > Hi Carlos, >=20 > One question below - >=20 > Carlos Jes=FAs Bernardos Cano wrote: > >=20 > > Hi Tran Minh, > >=20 > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > > > Hi Bernardos and all, > > > > > > I have some comments and questions on the I-D > > > draft-bernardos-netext-pmipv6-flowmob-00 as follows: > >=20 > > Thanks a lot for the feedback. Please see some comments inline below. > >=20 > > > 1) I think the LMA can decide to move down-link flows only. The > > > up-link flows should be moved by the MN (eg. the MN is aware of the > > > attachment status via each IF and decide which IF is better for > > > sending up-link flows). The MAG should be aware of the movement of > >=20 > > Our assumption is that the MN does implement the logical interface (as > > explained in draft-melia-netext-logical-interface-support-01). The LMA > > has of course the direct control of how downlink flows are routed, but > > an MN implementing the logical interface will just mirror that behavior > > with the uplink packets. Therefore, the LMA is the only entity > > controlling flow mobility both in downlink and uplink directions. > >=20 > > > up-link flows and inform the LMA to update information. > >=20 > > In the current draft, the MAG is informed about flow mobility > > operations by the LMA. There is signaling defined for that purpose. >=20 > Why does the LMA needs to inform the MAG about flow mobility operations? >=20 > It seems to me that these operations are essentially transparent to the M= AG and thus the MAG needs not to be involved at all in flow mobility: The L= MA decides where to send downlink packets, and the MN mirrors that behavior= for uplink packet (as described in the logical interface draft.) Well, there are two scenarios. If the MN is assigned the same of prefixes across the different physical interfaces that belong to the logical interface, you are right that this signaling can be avoided (this is actually pointed out in the draft), as there is nothing else to be added at the MAG. However, if the MN gets different prefixes at each physical interface, then we need to signal the MAG, so it knows how to route packets downlink (and also to prevent potential ingress filtering in the uplink). Carlos >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-j09/cTqeKIzFXqS1GSTQ 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) iEYEABECAAYFAkxF20QACgkQNdy6TdFwT2f/vgCdGKEppX6ff8fbbw3a4AHGFDtm rFgAn3rYO5AoQItt8bdLeIefyD2xiVts =bfDE -----END PGP SIGNATURE----- --=-j09/cTqeKIzFXqS1GSTQ-- From julienl@qualcomm.com Tue Jul 20 12:06:02 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 39DC83A687D for ; Tue, 20 Jul 2010 12:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 dLmPPgkOqgAS for ; Tue, 20 Jul 2010 12:06:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E375D3A67DB for ; Tue, 20 Jul 2010 12:06:00 -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=1279652774; x=1311188774; 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:=20"cjbc@it.uc3m.es"=20|CC:=20Tran =20Minh=20Trung=20,=20"netext@ietf.or g"=20|Date:=20Tue,=2020=20Jul=202010=201 2:06:13=20-0700|Subject:=20RE:=20[netext]=20Comments=20& =20Questions=20on=20the=20I-D:=0D=0A=20draft-bernardos-ne text-pmipv6-flowmob-00|Thread-Topic:=20[netext]=20Comment s=20&=20Questions=20on=20the=20I-D:=0D=0A=20draft-bernard os-netext-pmipv6-flowmob-00|Thread-Index:=20AcsoMAEWBx0dC vLPTZG4fksedUIRVwADVvuA|Message-ID:=20 |References:=20=0D=0A=09=20<1279641996.2828.314.came l@acorde.it.uc3m.es>=0D=0A=09=20=0D=0A=20< 1279646559.2828.7.camel@acorde.it.uc3m.es>|In-Reply-To: =20<1279646559.2828.7.camel@acorde.it.uc3m.es> |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=kyaFEfo4qTsmVAjDyuQ9Yj+J9OGjcDrRDKLJyexJPLg=; b=zmcJGrlSEW8ceuNHa4gowXmsMZNwMxB8X0IQcLZf/zbaSo6Yfu2qkMWd BH76t20BE6x9tc7VXZxW/jhl4RxCIsrMH5YDwqm5MNcTbRRMPiZKMWO4E ONazXqSgV6yoza1a5cydwfsfSa63O92HTOPbLJhsE4/wtVUh0bW4wpDer g=; X-IronPort-AV: E=McAfee;i="5400,1158,6049"; a="48074262" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 20 Jul 2010 12:06:14 -0700 X-IronPort-AV: E=Sophos;i="4.55,232,1278313200"; d="scan'208";a="44754751" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jul 2010 12:06:14 -0700 Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 12:06:15 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 20 Jul 2010 12:06:15 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Tue, 20 Jul 2010 12:06:14 -0700 From: "Laganier, Julien" To: "cjbc@it.uc3m.es" Date: Tue, 20 Jul 2010 12:06:13 -0700 Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcsoMAEWBx0dCvLPTZG4fksedUIRVwADVvuA Message-ID: References: <1279641996.2828.314.camel@acorde.it.uc3m.es> <1279646559.2828.7.camel@acorde.it.uc3m.es> In-Reply-To: <1279646559.2828.7.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 Cc: "netext@ietf.org" , Tran Minh Trung Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 19:06:02 -0000 Hi Carlos, Carlos Jes=FAs Bernardos Cano wrote: >=20 > Hi Julien, >=20 > On Tue, 2010-07-20 at 09:32 -0700, Laganier, Julien wrote: > > Hi Carlos, > > > > One question below - > > > > Carlos Jes=FAs Bernardos Cano wrote: > > > > > > Hi Tran Minh, > > > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > > > > Hi Bernardos and all, > > > > > > > > I have some comments and questions on the I-D > > > > draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > > > Thanks a lot for the feedback. Please see some comments inline > > > below. > > > > > > > 1) I think the LMA can decide to move down-link flows only. The > > > > up-link flows should be moved by the MN (eg. the MN is aware of > > > > the attachment status via each IF and decide which IF is better > > > > for sending up-link flows). The MAG should be aware of the > > > > movement of > > > > > > Our assumption is that the MN does implement the logical interface > > > (as explained in draft-melia-netext-logical-interface-support-01). > > > The LMA has of course the direct control of how downlink flows are > > > routed, but an MN implementing the logical interface will just > > > mirror that behavior with the uplink packets. Therefore, the LMA is > > > the only entity controlling flow mobility both in downlink and > > > uplink directions. > > > > > > > up-link flows and inform the LMA to update information. > > > > > > In the current draft, the MAG is informed about flow mobility > > > operations by the LMA. There is signaling defined for that purpose. > > > > Why does the LMA needs to inform the MAG about flow mobility > > operations? > > > > It seems to me that these operations are essentially transparent to > > the MAG and thus the MAG needs not to be involved at all in flow > > mobility: The LMA decides where to send downlink packets, and the MN > > mirrors that behavior for uplink packet (as described in the logical > > interface draft.) >=20 > Well, there are two scenarios. If the MN is assigned the same of > prefixes across the different physical interfaces that belong to the > logical interface, you are right that this signaling can be avoided > (this is actually pointed out in the draft), as there is nothing else > to be added at the MAG. However, if the MN gets different prefixes at > each physical interface, then we need to signal the MAG, so it knows > how to route packets downlink (and also to prevent potential ingress > filtering in the uplink). So in the simple case where the MN is assigned the same (set of) prefix(es)= across multiple physical interfaces then there is no need for flow mobilit= y signaling.=20 Since the draft does not detail any requirement that would justify the need= for the other model (different prefixes assigned to different physical int= erfaces) my take is that we can keep things simple by simply removing that = other model from the draft and proceed with a single (and simple) model -- = same (set of) prefix(es) across multiple physical interfaces. --julien From cjbc@it.uc3m.es Tue Jul 20 15:01:32 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 983533A67EC for ; Tue, 20 Jul 2010 15:01:32 -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 l2pXUTTslika for ; Tue, 20 Jul 2010 15:01:31 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CDF9B3A659C for ; Tue, 20 Jul 2010 15:01:30 -0700 (PDT) X-uc3m-safe: yes Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4E1CA704621; Wed, 21 Jul 2010 00:01:45 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Laganier, Julien" In-Reply-To: References: <1279641996.2828.314.camel@acorde.it.uc3m.es> <1279646559.2828.7.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9sMizaOhxMkhVEZD7GOu" Organization: Universidad Carlos III de Madrid Date: Wed, 21 Jul 2010 00:02:57 +0200 Message-ID: <1279663377.2828.23.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17518.002 Cc: netext@ietf.org, Tran Minh Trung Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 22:01:32 -0000 --=-9sMizaOhxMkhVEZD7GOu Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Julien, On Tue, 2010-07-20 at 12:06 -0700, Laganier, Julien wrote: > Hi Carlos, >=20 > Carlos Jes=FAs Bernardos Cano wrote: > >=20 > > Hi Julien, > >=20 > > On Tue, 2010-07-20 at 09:32 -0700, Laganier, Julien wrote: > > > Hi Carlos, > > > > > > One question below - > > > > > > Carlos Jes=FAs Bernardos Cano wrote: > > > > > > > > Hi Tran Minh, > > > > > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > > > > > Hi Bernardos and all, > > > > > > > > > > I have some comments and questions on the I-D > > > > > draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > > > > > Thanks a lot for the feedback. Please see some comments inline > > > > below. > > > > > > > > > 1) I think the LMA can decide to move down-link flows only. The > > > > > up-link flows should be moved by the MN (eg. the MN is aware of > > > > > the attachment status via each IF and decide which IF is better > > > > > for sending up-link flows). The MAG should be aware of the > > > > > movement of > > > > > > > > Our assumption is that the MN does implement the logical interface > > > > (as explained in draft-melia-netext-logical-interface-support-01). > > > > The LMA has of course the direct control of how downlink flows are > > > > routed, but an MN implementing the logical interface will just > > > > mirror that behavior with the uplink packets. Therefore, the LMA is > > > > the only entity controlling flow mobility both in downlink and > > > > uplink directions. > > > > > > > > > up-link flows and inform the LMA to update information. > > > > > > > > In the current draft, the MAG is informed about flow mobility > > > > operations by the LMA. There is signaling defined for that purpose. > > > > > > Why does the LMA needs to inform the MAG about flow mobility > > > operations? > > > > > > It seems to me that these operations are essentially transparent to > > > the MAG and thus the MAG needs not to be involved at all in flow > > > mobility: The LMA decides where to send downlink packets, and the MN > > > mirrors that behavior for uplink packet (as described in the logical > > > interface draft.) > >=20 > > Well, there are two scenarios. If the MN is assigned the same of > > prefixes across the different physical interfaces that belong to the > > logical interface, you are right that this signaling can be avoided > > (this is actually pointed out in the draft), as there is nothing else > > to be added at the MAG. However, if the MN gets different prefixes at > > each physical interface, then we need to signal the MAG, so it knows > > how to route packets downlink (and also to prevent potential ingress > > filtering in the uplink). >=20 > So in the simple case where the MN is assigned the same (set of) > prefix(es) across multiple physical interfaces then there is no need > for flow mobility signaling.=20 I need to think of this more carefully (just to ensure I'm not overlooking anything). There might be the need in case the MN is attached through different interfaces to the same MAG. In that case we might need some support and signalling to make the MAG aware of the interface that should be used to deliver packets to the MN. That is a very particular scenario anyway, as the MAG will "see" the same IP address attached at different interfaces. >=20 > Since the draft does not detail any requirement that would justify the > need for the other model (different prefixes assigned to different > physical interfaces) my take is that we can keep things simple by > simply removing that other model from the draft and proceed with a > single (and simple) model -- same (set of) prefix(es) across multiple > physical interfaces. Well, the draft does not detail any requirement, but this does not necessarily mean there is not (I'm not saying either way). I think this deserves a second thought, because when I looked at existing solutions, there were some that assumed that model, so I'd say that we need to at least understand why. Maybe people can comment on this particular issue... I'd fine to removing this if there is no real need for supporting the two models. Thanks, Carlos >=20 > --julien --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-9sMizaOhxMkhVEZD7GOu 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) iEYEABECAAYFAkxGHREACgkQNdy6TdFwT2fb+gCgpLpX7emnex+kkFqTPoR2TURR zTYAniTVg0afhGwZcfD/32PqyvXgzqO4 =xxVZ -----END PGP SIGNATURE----- --=-9sMizaOhxMkhVEZD7GOu-- From rkoodli@cisco.com Tue Jul 20 15:22: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 516C53A6809 for ; Tue, 20 Jul 2010 15:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.833 X-Spam-Level: X-Spam-Status: No, score=-7.833 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 mjNxc5SqbRhy for ; Tue, 20 Jul 2010 15:22:41 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2F76B3A6818 for ; Tue, 20 Jul 2010 15:22:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0HAKO+RUytJV2b/2dsb2JhbACHc5gBAnGmUZsNhTIEhACEWYI1g3g Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 22:22:56 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o6KMMs1N001839; Tue, 20 Jul 2010 22:22:55 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jul 2010 18:21:25 -0400 Received: from 171.70.248.64 ([171.70.248.64]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Jul 2010 22:20:53 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 20 Jul 2010 15:29:26 -0700 From: Rajeev Koodli To: , "Laganier, Julien" Message-ID: Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcsoWwKL4E1k4RC610C22R8Kh2cqwQ== In-Reply-To: <1279663377.2828.23.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Jul 2010 22:21:25.0647 (UTC) FILETIME=[E43B19F0:01CB2859] Cc: netext@ietf.org, Tran Minh Trung Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 22:22:51 -0000 On 7/20/10 3:02 PM, "Carlos Jes=FAs Bernardos Cano" wrote: > Well, the draft does not detail any requirement, but this does not > necessarily mean there is not (I'm not saying either way). I think this > deserves a second thought, because when I looked at existing solutions, > there were some that assumed that model, so I'd say that we need to at > least understand why. Maybe people can comment on this particular > issue... I'd fine to removing this if there is no real need for > supporting the two models. >=20 I think both the models need to be captured. Having a separate /64 can be a subscription issue - the provider may want to maintain separate sessions fo= r the multi-access. And, a MAG needs to have the session state as well for such purposes as QoS, policy and accounting. So, signaling is necessary regardless of whether the same /64 is used or not. -Rajeev > Thanks, >=20 > Carlos >=20 >>=20 >> --julien From julienl@qualcomm.com Tue Jul 20 15:55: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 3DD983A685B for ; Tue, 20 Jul 2010 15:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 cRfK9LRWrwSi for ; Tue, 20 Jul 2010 15:55:10 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id EDB3D3A65A5 for ; Tue, 20 Jul 2010 15:55:09 -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=1279666523; x=1311202523; 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:=20Rajeev=20Koodli=20,=20"cjbc@it. uc3m.es"=20|CC:=20"netext@ietf.org"=20,=20Tran=20Minh=20Trung=20|Date:=20Tue,=2020=20Jul=202010=2015:55:24=20-0700 |Subject:=20RE:=20[netext]=20Comments=20&=20Questions=20o n=20the=20I-D:=0D=0A=20draft-bernardos-netext-pmipv6-flow mob-00|Thread-Topic:=20[netext]=20Comments=20&=20Question s=20on=20the=20I-D:=0D=0A=20draft-bernardos-netext-pmipv6 -flowmob-00|Thread-Index:=20AcsoWwKL4E1k4RC610C22R8Kh2cqw QAAMJUw|Message-ID:=20|References:=20<1279 663377.2828.23.camel@acorde.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-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=yHDbCaE3bXX4wgFrgJs97SGzyz5yaFi4QpLDUCKC0Q0=; b=RMDIFt1YrNgQhP8QIQ9CUQ30mfPFZFI6wdlsKDJq/mEaCODXq37tixam /KRRXg5Ora3itA2BlJy4A575R9s2oHPRYM4sW3A6XyS8CIVBRB/5nXe2D VkjJyMvGJSw8nXI4h+JV+61OfbSFPySOHPrTC6FQGXP3qDM2wevC9pfpQ A=; X-IronPort-AV: E=McAfee;i="5400,1158,6049"; a="47941750" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 20 Jul 2010 15:55:23 -0700 X-IronPort-AV: E=Sophos;i="4.55,232,1278313200"; d="scan'208";a="44855940" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Jul 2010 15:55:23 -0700 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 20 Jul 2010 15:55:25 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 20 Jul 2010 15:55:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 20 Jul 2010 15:55:24 -0700 From: "Laganier, Julien" To: Rajeev Koodli , "cjbc@it.uc3m.es" Date: Tue, 20 Jul 2010 15:55:24 -0700 Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcsoWwKL4E1k4RC610C22R8Kh2cqwQAAMJUw Message-ID: References: <1279663377.2828.23.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" , Tran Minh Trung Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 20 Jul 2010 22:55:11 -0000 Rajeev Koodli wrote:=20 >=20 > On 7/20/10 3:02 PM, "Carlos Jes=FAs Bernardos Cano" > wrote: >=20 > > Well, the draft does not detail any requirement, but this does not > > necessarily mean there is not (I'm not saying either way). I think > > this deserves a second thought, because when I looked at existing > > solutions, there were some that assumed that model, so I'd say that > > we need to at least understand why. Maybe people can comment on this=20 > > particular issue... I'd fine to removing this if there is no real need= =20 > > for supporting the two models. >=20 > I think both the models need to be captured.=20 Engineering is about designing solutions to problems. Thus seems premature = to capture more than one model without having captured requirements that ju= stify the need for those. > Having a separate /64 can > be a subscription issue - the provider may want to maintain separate > sessions for the multi-access. And, a MAG needs to have the session state= =20 > as well for such purposes as QoS, policy and accounting. So, signaling is > necessary regardless of whether the same /64 is used or not. If we can agree that there's a requirement that separate session be maintai= ned for each of the accesses, then we can discuss how to best fulfill this = requirements, including, but not necessarily relying on, signaling.=20 I do not know yet how that would relate to the use of one (set of) prefix(e= s) per physical interface. --julien=20 From trungtm2909@gmail.com Wed Jul 21 03:17:09 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 3E95A3A6B8D for ; Wed, 21 Jul 2010 03:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, 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 WWaDYx7mjUCH for ; Wed, 21 Jul 2010 03:17:07 -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 020453A6BB5 for ; Wed, 21 Jul 2010 03:17:06 -0700 (PDT) Received: by iwn38 with SMTP id 38so7375596iwn.31 for ; Wed, 21 Jul 2010 03:17:23 -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=KoiihldB5VR0M8P43hWQMq6pPJ5JgYRYHvS/YlJz4tA=; b=DpkEF6iaD1KRZBZTKgFpMk3f7X05NoOXV4ULZU4mvo5cGPtaY/hYs0wpOIrk0jTHlJ 4hfDc97p0krA9MJFiyxt7KUopOcqtVZ8IGw1bpGzZDpOuEVe4o+UWMrivrPODTWJrdW6 1jsduagRqq//N6X1Z1HCGQq1MhHqbY57SOlXs= 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=mndI5YHiXHhxuUNH1un3O2pgWHK3P4tTW4lOILF7perH7EuZao51qWViQV2l4UwyvF awY4nAUwLchIJwoHjvm6CAwqPHEYgRt0fNmlRcCduhenPzaUAhklvy6CUREGRYeLY3Jl Ce7T3fnO6OTh2aREgBvqQneURO1Ez3/vMCrzs= MIME-Version: 1.0 Received: by 10.231.146.205 with SMTP id i13mr8926668ibv.30.1279707442894; Wed, 21 Jul 2010 03:17:22 -0700 (PDT) Sender: trungtm2909@gmail.com Received: by 10.231.185.32 with HTTP; Wed, 21 Jul 2010 03:17:22 -0700 (PDT) In-Reply-To: <1279641996.2828.314.camel@acorde.it.uc3m.es> References: <1279641996.2828.314.camel@acorde.it.uc3m.es> Date: Wed, 21 Jul 2010 19:17:22 +0900 X-Google-Sender-Auth: -vNVIcTMQvGFH9JNP8n25d3KeTw Message-ID: From: Tran Minh Trung To: cjbc@it.uc3m.es Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 21 Jul 2010 10:17:09 -0000 Hi Bernardos, Thank you for your reply. Pls. see my replies inline. 2010/7/21 Carlos Jes=FAs Bernardos Cano : > Hi Tran Minh, > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: >> Hi Bernardos and all, >> >> I have some comments and questions on the I-D >> draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > Thanks a lot for the feedback. Please see some comments inline below. > >> >> 1) I think the LMA can decide to move down-link flows only. The >> up-link flows should be moved by the MN (eg. the MN is aware of the >> attachment status via each IF and decide which IF is better for >> sending up-link flows). The MAG should be aware of the movement of > > Our assumption is that the MN does implement the logical interface (as > explained in draft-melia-netext-logical-interface-support-01). The LMA > has of course the direct control of how downlink flows are routed, but > an MN implementing the logical interface will just mirror that behavior > with the uplink packets. Therefore, the LMA is the only entity > controlling flow mobility both in downlink and uplink directions. > >> up-link flows and inform the LMA to update information. > > In the current draft, the MAG is informed about flow mobility operations > by the LMA. There is signaling defined for that purpose. > Let's consider the case that the MN performs a handoff. I think it is a special case of flow mobility when all flows are moved from an interface to another. The MAG is aware of that event and informs the LMA by using handoff indicator. So I think that we may consider the same for the case that flows are moved by the MN. The MAG can be aware of this movement by analyzing the packets received from the MN and inform the LMA. In real network both operator (the LMA) and user (the MN) can set and perform the rules to select the best interface (access technologies) for serving a specific service flow. So we may better support for both of them. >> >> 2) It is necessary to discuss about the flow mobility triggers. The >> signaling procedure between MAG/LMA depends on trigger. With different >> kind of trigger we have to use different signaling procedure. > > The trigger is out of the scope of the solution draft. Any kind of > trigger could be supported. For example a central policy entity can make > the decisions based on the overall state of the network and trigger the > LMA. IMHO, which entity triggers the LMA can be left out of the scope, > as it does not have an impact on the protocol (with current design). > I agree that it is not necessary to discuss detail about trigger in the solution draft. However, we have to mention about where do triggers come from?. Basing on the source of trigger we have to use different signaling procedure. For examples: - The MN performs new attachment -> The MAG is aware of that event and informs the LMA about new attachment and asks the LMA whether to move some exiting flows to new attachment. - The MAG receives new flows from an interface of the MN -> The MAG informs and asks LMA to check whether this flow is a new flow or just a flow moved from another interface of the MN. - The LMA sees some changes in the network conditions or service profile of the MN -> The LMA decides to move some flows to get better services and inform MAGs. >> >> 3) The proposed solution requires new signaling messages and new >> caching table. It makes more complicated for implementing and >> combining with the existing standard than just extending the current >> PBU/PBA messages as well as BCE and BULE caching table. > > Well, this was a design decision (there might be of course others). We > preferred not to overload existing signaling. Regarding the data > structures, they are just logical ones, they could also even be > implemented by extending BCE and BUL. > >> >> 4) What are the necessary requirements of the logical interface to >> support flow mobility? > > This should be covered by > draft-melia-netext-logical-interface-support-01. > I get some confuses about the logical interface described in the I-D =93draft-melia-netext-logical-interface-support-=94 and the logical interface used in the I-D =9301draft-bernardos-netext-pmipv6-flowmob-00=94 IMHO, when we use logical interface, the (set of) prefix(es) is assigned to the logical interface only, not to physical interface. The LMA, at layer 3, may see only the logical interface. >From this point, I think the 'Unique prefix per physical interface' scenario is not necessary. However if we consider this scenario, then we can justify why we need it as Julien suggested. And also we can discuss to make clear that why we use the logical interface to hide the physical interfaces but we still separate prefix(es) assignment basing on physical interfaces. --- Tran Minh Trung >> >> I hope that we can have more discussion on these issues before making >> it as a WG document. > > Sure, useful discussion as this is very very welcome. Thanks! > > Kind Regards, > > Carlos > >> >> Regards, >> Tran Minh Trung >> > > -- > Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 > --=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 pierrick.seite@orange-ftgroup.com Wed Jul 21 06:51: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 591303A67A5 for ; Wed, 21 Jul 2010 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-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 vACHSFXAfZlS for ; Wed, 21 Jul 2010 06:51:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 6DE123A6826 for ; Wed, 21 Jul 2010 06:51:31 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF3C98B8009; Wed, 21 Jul 2010 15:52:12 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id E777D8B8008; Wed, 21 Jul 2010 15:52:12 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jul 2010 15:51:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 15:51:45 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620105E348@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments & Questions on the I-D:draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: Acsove08S5wuIPdmSMeR8QZ9x9FmygAHXuhw References: <1279641996.2828.314.camel@acorde.it.uc3m.es> From: To: , X-OriginalArrivalTime: 21 Jul 2010 13:51:45.0362 (UTC) FILETIME=[DB5FAB20:01CB28DB] Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions on the I-D:draft-bernardos-netext-pmipv6-flowmob-00 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, 21 Jul 2010 13:51:36 -0000 Hi Tran Minh and Carlos, Please let me jump into this interesting discussion. Tran Minh, You're right, theoretically both the LMA and the MN should = also be able to make decision about the path to use for a given IP flow. = In addition to handover triggers at the MN side that you are suggesting, = it may be not desirable that the LMA enforces its decision to the MN = despite of the user preferences.=20 However, a MN driven decision in a network based mobility management = solution is quite tricky without MN signalling (and we definitely want = to avoid such a signalling, I don't want to reopen the debate :-)). For = example, you wrote: "The MAG can be aware of this movement by analyzing the packets received = from the MN and inform the LMA." I don't think such a simple solution could be sufficient, since there = are some cases where the MN does not use the uplink very often, e.g. RTP = streaming.=20 So, trying to support the MN driven routing decision would bring = additional complexity and delay in the design of a solution. So, for the = sake of pragmatism, it makes sense to focus, in a first step, on a = routing decision driven by the LMA where the MN just updates its uplink = path according to where packets are received. Then we need to clarify the requirement for handover triggers to be = processed at the MN side only. If so, we could think about extension to = the base solution as drafted in draft-bernardos. Regards, Pierrick > -----Message d'origine----- > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part > de Tran Minh Trung > Envoy=E9=A0: mercredi 21 juillet 2010 12:17 > =C0=A0: cjbc@it.uc3m.es > Cc=A0: netext@ietf.org > Objet=A0: Re: [netext] Comments & Questions on the = I-D:draft-bernardos- > netext-pmipv6-flowmob-00 >=20 > Hi Bernardos, >=20 > Thank you for your reply. > Pls. see my replies inline. >=20 > 2010/7/21 Carlos Jes=FAs Bernardos Cano : > > Hi Tran Minh, > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > >> Hi Bernardos and all, > >> > >> I have some comments and questions on the I-D > >> draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > Thanks a lot for the feedback. Please see some comments inline = below. > > > >> > >> 1) I think the LMA can decide to move down-link flows only. The > >> up-link flows should be moved by the MN (eg. the MN is aware of the > >> attachment status via each IF and decide which IF is better for > >> sending up-link flows). The MAG should be aware of the movement of > > > > Our assumption is that the MN does implement the logical interface = (as > > explained in draft-melia-netext-logical-interface-support-01). The = LMA > > has of course the direct control of how downlink flows are routed, = but > > an MN implementing the logical interface will just mirror that = behavior > > with the uplink packets. Therefore, the LMA is the only entity > > controlling flow mobility both in downlink and uplink directions. > > >=20 >=20 > >> up-link flows and inform the LMA to update information. > > > > In the current draft, the MAG is informed about flow mobility = operations > > by the LMA. There is signaling defined for that purpose. > > >=20 > Let's consider the case that the MN performs a handoff. I think it is > a special case of flow mobility when all flows are moved from an > interface to another. The MAG is aware of that event and informs the > LMA by using handoff indicator. So I think that we may consider the > same for the case that flows are moved by the MN. The MAG can be aware > of this movement by analyzing the packets received from the MN and > inform the LMA. >=20 > In real network both operator (the LMA) and user (the MN) can set and > perform the rules to select the best interface (access technologies) > for serving a specific service flow. So we may better support for both > of them. >=20 >=20 > >> > >> 2) It is necessary to discuss about the flow mobility triggers. The > >> signaling procedure between MAG/LMA depends on trigger. With = different > >> kind of trigger we have to use different signaling procedure. > > > > The trigger is out of the scope of the solution draft. Any kind of > > trigger could be supported. For example a central policy entity can = make > > the decisions based on the overall state of the network and trigger = the > > LMA. IMHO, which entity triggers the LMA can be left out of the = scope, > > as it does not have an impact on the protocol (with current design). > > >=20 > I agree that it is not necessary to discuss detail about trigger in > the solution draft. > However, we have to mention about where do triggers come from?. Basing > on the source of trigger we have to use different signaling procedure. >=20 > For examples: >=20 > - The MN performs new attachment -> The MAG is aware of that event and > informs the LMA about new attachment and asks the LMA whether to move > some exiting flows to new attachment. > - The MAG receives new flows from an interface of the MN -> The MAG > informs and asks LMA to check whether this flow is a new flow or just > a flow moved from another interface of the MN. > - The LMA sees some changes in the network conditions or service > profile of the MN -> The LMA decides to move some flows to get better > services and inform MAGs. >=20 >=20 > >> > >> 3) The proposed solution requires new signaling messages and new > >> caching table. It makes more complicated for implementing and > >> combining with the existing standard than just extending the = current > >> PBU/PBA messages as well as BCE and BULE caching table. > > >=20 > > Well, this was a design decision (there might be of course others). = We > > preferred not to overload existing signaling. Regarding the data > > structures, they are just logical ones, they could also even be > > implemented by extending BCE and BUL. > > > >> > >> 4) What are the necessary requirements of the logical interface to > >> support flow mobility? > > > > This should be covered by > > draft-melia-netext-logical-interface-support-01. > > >=20 > I get some confuses about the logical interface described in the I-D > "draft-melia-netext-logical-interface-support-" and the logical > interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob-00" >=20 > IMHO, when we use logical interface, the (set of) prefix(es) is > assigned to the logical interface only, not to physical interface. The > LMA, at layer 3, may see only the logical interface. >=20 > From this point, I think the 'Unique prefix per physical interface' > scenario is not necessary. >=20 > However if we consider this scenario, then we can justify why we need > it as Julien suggested. And also we can discuss to make clear that why > we use the logical interface to hide the physical interfaces but we > still separate prefix(es) assignment basing on physical interfaces. >=20 > --- > Tran Minh Trung >=20 > >> > >> I hope that we can have more discussion on these issues before = making > >> it as a WG document. > > > > Sure, useful discussion as this is very very welcome. Thanks! > > > > Kind Regards, > > > > Carlos > > > >> > >> Regards, > >> Tran Minh Trung > >> > > > > -- > > Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 > > >=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 JuanCarlos.Zuniga@InterDigital.com Wed Jul 21 14:06:06 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 6E5803A67FB for ; Wed, 21 Jul 2010 14:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.445, 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 e4bJw6bqe5yy for ; Wed, 21 Jul 2010 14:06:02 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 421DD3A6B78 for ; Wed, 21 Jul 2010 14:06:02 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jul 2010 17:06:18 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jul 2010 17:06:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 17:06:16 -0400 Message-ID: In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620105E348@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments & Questions on theI-D:draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: Acsove08S5wuIPdmSMeR8QZ9x9FmygAHXuhwAA8L/cA= References: <1279641996.2828.314.camel@acorde.it.uc3m.es> <843DA8228A1BA74CA31FB4E111A5C4620105E348@ftrdmel0.rd.francetelecom.fr> From: "Zuniga, Juan Carlos" To: , X-OriginalArrivalTime: 21 Jul 2010 21:06:18.0231 (UTC) FILETIME=[9003C070:01CB2918] Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions on theI-D:draft-bernardos-netext-pmipv6-flowmob-00 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, 21 Jul 2010 21:06:06 -0000 Pierrick, Tran Minh, As Carlos mentioned in his first response to Tran Minh, the necessary = requirements of the logical interface to support flow mobility should be = captured in the applicability document. The current wording in = "draft-melia-netext-logical-interface-support-01" is a little messy due = to the last minute merger of two other i-ds, but this is the place where = the overall system should be described (i.e. beyond PMIP changes). Regarding the MN driven decision, we discussed in the past that a = trigger could be sent to the LMA via L2.5 signalling. This would not be = in scope for the solution document = (draft-bernardos-netext-pmipv6-flowmob-00) which, as Pierrick points = out, only considers network based solutions. However, it should be = documented in the applicability document as this could be one more input = at the LMA to trigger the flow mobility (from the network). By making = this distinction, we allow both MN and LMA to start the flow mobility, = and still limit the mobility management solution to be network based. Regards, Juan-Carlos > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of pierrick.seite@orange-ftgroup.com > Sent: Wednesday, July 21, 2010 9:52 AM > To: trungtm@etri.re.kr; cjbc@it.uc3m.es > Cc: netext@ietf.org > Subject: Re: [netext] Comments & Questions on theI-D:draft-bernardos- > netext-pmipv6-flowmob-00 >=20 > Hi Tran Minh and Carlos, >=20 > Please let me jump into this interesting discussion. >=20 > Tran Minh, You're right, theoretically both the LMA and the MN should > also be able to make decision about the path to use for a given IP > flow. In addition to handover triggers at the MN side that you are > suggesting, it may be not desirable that the LMA enforces its decision > to the MN despite of the user preferences. >=20 > However, a MN driven decision in a network based mobility management > solution is quite tricky without MN signalling (and we definitely want > to avoid such a signalling, I don't want to reopen the debate :-)). = For > example, you wrote: >=20 > "The MAG can be aware of this movement by analyzing the packets > received from the MN and inform the LMA." >=20 > I don't think such a simple solution could be sufficient, since there > are some cases where the MN does not use the uplink very often, e.g. > RTP streaming. >=20 > So, trying to support the MN driven routing decision would bring > additional complexity and delay in the design of a solution. So, for > the sake of pragmatism, it makes sense to focus, in a first step, on a > routing decision driven by the LMA where the MN just updates its = uplink > path according to where packets are received. >=20 > Then we need to clarify the requirement for handover triggers to be > processed at the MN side only. If so, we could think about extension = to > the base solution as drafted in draft-bernardos. >=20 > Regards, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De = la > part > > de Tran Minh Trung > > Envoy=E9=A0: mercredi 21 juillet 2010 12:17 > > =C0=A0: cjbc@it.uc3m.es > > Cc=A0: netext@ietf.org > > Objet=A0: Re: [netext] Comments & Questions on the = I-D:draft-bernardos- > > netext-pmipv6-flowmob-00 > > > > Hi Bernardos, > > > > Thank you for your reply. > > Pls. see my replies inline. > > > > 2010/7/21 Carlos Jes=FAs Bernardos Cano : > > > Hi Tran Minh, > > > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > > >> Hi Bernardos and all, > > >> > > >> I have some comments and questions on the I-D > > >> draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > > > Thanks a lot for the feedback. Please see some comments inline > below. > > > > > >> > > >> 1) I think the LMA can decide to move down-link flows only. The > > >> up-link flows should be moved by the MN (eg. the MN is aware of > the > > >> attachment status via each IF and decide which IF is better for > > >> sending up-link flows). The MAG should be aware of the movement = of > > > > > > Our assumption is that the MN does implement the logical interface > (as > > > explained in draft-melia-netext-logical-interface-support-01). The > LMA > > > has of course the direct control of how downlink flows are routed, > but > > > an MN implementing the logical interface will just mirror that > behavior > > > with the uplink packets. Therefore, the LMA is the only entity > > > controlling flow mobility both in downlink and uplink directions. > > > > > > > > > >> up-link flows and inform the LMA to update information. > > > > > > In the current draft, the MAG is informed about flow mobility > operations > > > by the LMA. There is signaling defined for that purpose. > > > > > > > Let's consider the case that the MN performs a handoff. I think it = is > > a special case of flow mobility when all flows are moved from an > > interface to another. The MAG is aware of that event and informs the > > LMA by using handoff indicator. So I think that we may consider the > > same for the case that flows are moved by the MN. The MAG can be > aware > > of this movement by analyzing the packets received from the MN and > > inform the LMA. > > > > In real network both operator (the LMA) and user (the MN) can set = and > > perform the rules to select the best interface (access technologies) > > for serving a specific service flow. So we may better support for > both > > of them. > > > > > > >> > > >> 2) It is necessary to discuss about the flow mobility triggers. > The > > >> signaling procedure between MAG/LMA depends on trigger. With > different > > >> kind of trigger we have to use different signaling procedure. > > > > > > The trigger is out of the scope of the solution draft. Any kind of > > > trigger could be supported. For example a central policy entity = can > make > > > the decisions based on the overall state of the network and = trigger > the > > > LMA. IMHO, which entity triggers the LMA can be left out of the > scope, > > > as it does not have an impact on the protocol (with current > design). > > > > > > > I agree that it is not necessary to discuss detail about trigger in > > the solution draft. > > However, we have to mention about where do triggers come from?. > Basing > > on the source of trigger we have to use different signaling > procedure. > > > > For examples: > > > > - The MN performs new attachment -> The MAG is aware of that event > and > > informs the LMA about new attachment and asks the LMA whether to = move > > some exiting flows to new attachment. > > - The MAG receives new flows from an interface of the MN -> The MAG > > informs and asks LMA to check whether this flow is a new flow or = just > > a flow moved from another interface of the MN. > > - The LMA sees some changes in the network conditions or service > > profile of the MN -> The LMA decides to move some flows to get = better > > services and inform MAGs. > > > > > > >> > > >> 3) The proposed solution requires new signaling messages and new > > >> caching table. It makes more complicated for implementing and > > >> combining with the existing standard than just extending the > current > > >> PBU/PBA messages as well as BCE and BULE caching table. > > > > > > > > Well, this was a design decision (there might be of course = others). > We > > > preferred not to overload existing signaling. Regarding the data > > > structures, they are just logical ones, they could also even be > > > implemented by extending BCE and BUL. > > > > > >> > > >> 4) What are the necessary requirements of the logical interface = to > > >> support flow mobility? > > > > > > This should be covered by > > > draft-melia-netext-logical-interface-support-01. > > > > > > > I get some confuses about the logical interface described in the I-D > > "draft-melia-netext-logical-interface-support-" and the logical > > interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob- > 00" > > > > IMHO, when we use logical interface, the (set of) prefix(es) is > > assigned to the logical interface only, not to physical interface. > The > > LMA, at layer 3, may see only the logical interface. > > > > From this point, I think the 'Unique prefix per physical interface' > > scenario is not necessary. > > > > However if we consider this scenario, then we can justify why we = need > > it as Julien suggested. And also we can discuss to make clear that > why > > we use the logical interface to hide the physical interfaces but we > > still separate prefix(es) assignment basing on physical interfaces. > > > > --- > > Tran Minh Trung > > > > >> > > >> I hope that we can have more discussion on these issues before > making > > >> it as a WG document. > > > > > > Sure, useful discussion as this is very very welcome. Thanks! > > > > > > Kind Regards, > > > > > > Carlos > > > > > >> > > >> Regards, > > >> Tran Minh Trung > > >> > > > > > > -- > > > Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net > > > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 > > > > > > > > > > > -- > > 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 From gsnaa.v2@163.com Wed Jul 21 17:12:35 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 6341C3A6946 for ; Wed, 21 Jul 2010 17:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.064 X-Spam-Level: **** X-Spam-Status: No, score=4.064 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 OqhoBUQsq960 for ; Wed, 21 Jul 2010 17:12:30 -0700 (PDT) Received: from m50-133.163.com (m50-133.163.com [123.125.50.133]) by core3.amsl.com (Postfix) with ESMTP id 6E0033A6B47 for ; Wed, 21 Jul 2010 17:12:27 -0700 (PDT) Received: from iplab-yzw (unknown [218.249.29.37]) by smtp3 (Coremail) with SMTP id DdGowKBr6gP7jEdMaV+gAA--.6653S2; Thu, 22 Jul 2010 08:12:43 +0800 (CST) Date: Thu, 22 Jul 2010 08:12:41 +0800 From: "gsnaa.v2" To: "netext" References: Message-ID: <201007220812406407956@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon701757034568_=====" X-CM-TRANSID: DdGowKBr6gP7jEdMaV+gAA--.6653S2 X-Coremail-Antispam: 1Uf129KBjvJXoWfGFy7Ar4xuw4ktw45CrW3Wrg_yoWDWrWkpF WSgFW2k3yDJr18Zw1Ivw1UWw1Yv34rXrWUCFyrJ3y8A3s0kFyIqr1rtrWrZFWDCr93Jw4j qr47Kr15Zw1ruFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jzrWOUUUUU= X-CM-SenderInfo: 5jvqttsoysqiywtou0bp/1tbioR4WQkgYuoGXogAAs1 Subject: Re: [netext] netext Digest, Vol 14, Issue 14 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: Thu, 22 Jul 2010 00:12:35 -0000 This is a multi-part message in MIME format. --=====003_Dragon701757034568_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KQXMgUGllcnJpY2sgbWVudGlvbmVkLCBJIHRoaW5rIGEgdmVyeSBpbXBvcnRhbnQg cXVlc3Rpb24gd2Ugc2hvdWxkIHNvbHZlIG5vdyBpcyB0aGF0IHdoZXRoZXIgTU4gc2hvdWxkIGlu dm9sdmUgaW4gdGhlIGNvbXBsZXggbW9iaWxpdHkgbWFuYWdlbWVudC4gQWx0aG91Z2ggdGhlIGRv Y3VtZW50IKGwZHJhZnQtZ3VuZGF2ZWxsaS1uZXRleHQtZXh0ZW5zaW9ucy1tb3RpdmF0aW9uLTAw LnR4dKGxIGhhcyBkZWNsYXJlZCB0aGF0IHRoZSBNTiBjYW4gaW52b2x2ZSBpbiB0aGUgbW9iaWxp dHkgbWFuYWdlbWVudCBpbiBzb21lIHNwZWNpYWwgc2NlbmFyaW9zLCBpbmNsdWRpbmcgdmVydGlj YWwgaGFuZG92ZXIsIG11bHRpaG9taW5nIGFuZCBmbG93IG1vYmlsaXR5LCB0aGlzIHF1ZXN0aW9u IGlzIHN0aWxsIGJlaW5nIGRpc2N1c3NlZCBhbmQgd2UgY2FuIG5vdCByZWFjaCBhIGNvbnNlbnN1 cyBhYm91dCBpdC4gDQpSZWdhcmRzLA0KWmhpd2VpIFlhbg0KDQoNCjIwMTAtMDctMjIgDQoNCg0K DQpnc25hYS52MiANCg0KDQoNCreivP7Iy6O6IG5ldGV4dC1yZXF1ZXN0IA0Kt6LLzcqxvOSjuiAy MDEwLTA3LTIyICAwMzowMDoxOCANCsrVvP7Iy6O6IG5ldGV4dCANCrOty82juiANCtb3zOKjuiBu ZXRleHQgRGlnZXN0LCBWb2wgMTQsIElzc3VlIDE0IA0KIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZQ0KYXR0YWNobWVu dHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxp c3QNCnN1YnNjcmlwdGlvbi4gIFRvIGRvIHNvLCBnbyB0byANCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQpDbGljayB0aGUgJ1Vuc3Vic2NyaWJlIG9yIGVkaXQg b3B0aW9ucycgYnV0dG9uLCBsb2cgaW4sIGFuZCBzZXQgIkdldA0KTUlNRSBvciBQbGFpbiBUZXh0 IERpZ2VzdHM/IiB0byBNSU1FLiAgWW91IGNhbiBzZXQgdGhpcyBvcHRpb24NCmdsb2JhbGx5IGZv ciBhbGwgdGhlIGxpc3QgZGlnZXN0cyB5b3UgcmVjZWl2ZSBhdCB0aGlzIHBvaW50Lg0KU2VuZCBu ZXRleHQgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQpuZXRleHRAaWV0Zi5vcmcNClRvIHN1 YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCm9yLCB2aWEgZW1haWws IHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KbmV0ZXh0LXJl cXVlc3RAaWV0Zi5vcmcNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlz dCBhdA0KbmV0ZXh0LW93bmVyQGlldGYub3JnDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5 b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVu dHMgb2YgbmV0ZXh0IGRpZ2VzdC4uLiINCl9fX19fX19fX18gSW5mb3JtYXRpb24gZnJvbSBFU0VU IE5PRDMyIEFudGl2aXJ1cywgdmVyc2lvbiBvZiB2aXJ1cyBzaWduYXR1cmUgZGF0YWJhc2UgNTA5 MyAoMjAxMDA1MDYpIF9fX19fX19fX18NClRoZSBtZXNzYWdlIHdhcyBjaGVja2VkIGJ5IEVTRVQg Tk9EMzIgQW50aXZpcnVzLg0KaHR0cDovL3d3dy5lc2V0LmNvbQ0KVG9kYXkncyBUb3BpY3M6DQog ICAxLiBSZTogQ29tbWVudHMgJiBRdWVzdGlvbnMgb24gdGhlDQogICAgICBJLUQ6ZHJhZnQtYmVy bmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYi0wMA0KICAgICAgKHBpZXJyaWNrLnNlaXRlQG9y YW5nZS1mdGdyb3VwLmNvbSkNCl9fX19fX19fX18gSW5mb3JtYXRpb24gZnJvbSBFU0VUIE5PRDMy IEFudGl2aXJ1cywgdmVyc2lvbiBvZiB2aXJ1cyBzaWduYXR1cmUgZGF0YWJhc2UgNTA5MyAoMjAx MDA1MDYpIF9fX19fX19fX18NClRoZSBtZXNzYWdlIHdhcyBjaGVja2VkIGJ5IEVTRVQgTk9EMzIg QW50aXZpcnVzLg0KaHR0cDovL3d3dy5lc2V0LmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgPHBpZXJyaWNrLnNl aXRlQG9yYW5nZS1mdGdyb3VwLmNvbT4NClRvOiAgPHRydW5ndG1AZXRyaS5yZS5rcj4NCiA8Y2pi Y0BpdC51YzNtLmVzPg0KU3ViamVjdDogIFJlOiBbbmV0ZXh0XSBDb21tZW50cyAmIFF1ZXN0aW9u cyBvbiB0aGVJLUQ6ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYi0wMA0KRGF0 ZTogIFdlZDIxIEp1bCAyMDEwIDE1OjUxOjQ1ICswMjAwDQpIaSBUcmFuIE1pbmggYW5kIENhcmxv cywNClBsZWFzZSBsZXQgbWUganVtcCBpbnRvIHRoaXMgaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbi4N ClRyYW4gTWluaCwgWW91J3JlIHJpZ2h0LCB0aGVvcmV0aWNhbGx5IGJvdGggdGhlIExNQSBhbmQg dGhlIE1OIHNob3VsZCBhbHNvIGJlIGFibGUgdG8gbWFrZSBkZWNpc2lvbiBhYm91dCB0aGUgcGF0 aCB0byB1c2UgZm9yIGEgZ2l2ZW4gSVAgZmxvdy4gSW4gYWRkaXRpb24gdG8gaGFuZG92ZXIgdHJp Z2dlcnMgYXQgdGhlIE1OIHNpZGUgdGhhdCB5b3UgYXJlIHN1Z2dlc3RpbmcsIGl0IG1heSBiZSBu b3QgZGVzaXJhYmxlIHRoYXQgdGhlIExNQSBlbmZvcmNlcyBpdHMgZGVjaXNpb24gdG8gdGhlIE1O IGRlc3BpdGUgb2YgdGhlIHVzZXIgcHJlZmVyZW5jZXMuIA0KSG93ZXZlciwgYSBNTiBkcml2ZW4g ZGVjaXNpb24gaW4gYSBuZXR3b3JrIGJhc2VkIG1vYmlsaXR5IG1hbmFnZW1lbnQgc29sdXRpb24g aXMgcXVpdGUgdHJpY2t5IHdpdGhvdXQgTU4gc2lnbmFsbGluZyAoYW5kIHdlIGRlZmluaXRlbHkg d2FudCB0byBhdm9pZCBzdWNoIGEgc2lnbmFsbGluZywgSSBkb24ndCB3YW50IHRvIHJlb3BlbiB0 aGUgZGViYXRlIDotKSkuIEZvciBleGFtcGxlLCB5b3Ugd3JvdGU6DQoiVGhlIE1BRyBjYW4gYmUg YXdhcmUgb2YgdGhpcyBtb3ZlbWVudCBieSBhbmFseXppbmcgdGhlIHBhY2tldHMgcmVjZWl2ZWQg ZnJvbSB0aGUgTU4gYW5kIGluZm9ybSB0aGUgTE1BLiINCkkgZG9uJ3QgdGhpbmsgc3VjaCBhIHNp bXBsZSBzb2x1dGlvbiBjb3VsZCBiZSBzdWZmaWNpZW50LCBzaW5jZSB0aGVyZSBhcmUgc29tZSBj YXNlcyB3aGVyZSB0aGUgTU4gZG9lcyBub3QgdXNlIHRoZSB1cGxpbmsgdmVyeSBvZnRlbiwgZS5n LiBSVFAgc3RyZWFtaW5nLiANClNvLCB0cnlpbmcgdG8gc3VwcG9ydCB0aGUgTU4gZHJpdmVuIHJv dXRpbmcgZGVjaXNpb24gd291bGQgYnJpbmcgYWRkaXRpb25hbCBjb21wbGV4aXR5IGFuZCBkZWxh eSBpbiB0aGUgZGVzaWduIG9mIGEgc29sdXRpb24uIFNvLCBmb3IgdGhlIHNha2Ugb2YgcHJhZ21h dGlzbSwgaXQgbWFrZXMgc2Vuc2UgdG8gZm9jdXMsIGluIGEgZmlyc3Qgc3RlcCwgb24gYSByb3V0 aW5nIGRlY2lzaW9uIGRyaXZlbiBieSB0aGUgTE1BIHdoZXJlIHRoZSBNTiBqdXN0IHVwZGF0ZXMg aXRzIHVwbGluayBwYXRoIGFjY29yZGluZyB0byB3aGVyZSBwYWNrZXRzIGFyZSByZWNlaXZlZC4N ClRoZW4gd2UgbmVlZCB0byBjbGFyaWZ5IHRoZSByZXF1aXJlbWVudCBmb3IgaGFuZG92ZXIgdHJp Z2dlcnMgdG8gYmUgcHJvY2Vzc2VkIGF0IHRoZSBNTiBzaWRlIG9ubHkuIElmIHNvLCB3ZSBjb3Vs ZCB0aGluayBhYm91dCBleHRlbnNpb24gdG8gdGhlIGJhc2Ugc29sdXRpb24gYXMgZHJhZnRlZCBp biBkcmFmdC1iZXJuYXJkb3MuDQpSZWdhcmRzLA0KUGllcnJpY2sNCj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+IERlIDogbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuZXRl eHQtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydA0KPiBkZSBUcmFuIE1pbmggVHJ1bmcNCj4g RW52b3mopiA6IG1lcmNyZWRpIDIxIGp1aWxsZXQgMjAxMCAxMjoxNw0KPiCopCA6IGNqYmNAaXQu dWMzbS5lcw0KPiBDYyA6IG5ldGV4dEBpZXRmLm9yZw0KPiBPYmpldCA6IFJlOiBbbmV0ZXh0XSBD b21tZW50cyAmIFF1ZXN0aW9ucyBvbiB0aGUgSS1EOmRyYWZ0LWJlcm5hcmRvcy0NCj4gbmV0ZXh0 LXBtaXB2Ni1mbG93bW9iLTAwDQo+IA0KPiBIaSBCZXJuYXJkb3MsDQo+IA0KPiBUaGFuayB5b3Ug Zm9yIHlvdXIgcmVwbHkuDQo+IFBscy4gc2VlIG15IHJlcGxpZXMgaW5saW5lLg0KPiANCj4gMjAx MC83LzIxIENhcmxvcyBKZXOosnMgQmVybmFyZG9zIENhbm8gPGNqYmNAaXQudWMzbS5lcz46DQo+ ID4gSGkgVHJhbiBNaW5oLA0KPiA+DQo+ID4gT24gVHVlLCAyMDEwLTA3LTIwIGF0IDE3OjQ0ICsw OTAwLCBUcmFuIE1pbmggVHJ1bmcgd3JvdGU6DQo+ID4+IEhpIEJlcm5hcmRvcyBhbmQgYWxsLA0K PiA+Pg0KPiA+PiBJIGhhdmUgc29tZSBjb21tZW50cyBhbmQgcXVlc3Rpb25zIG9uIHRoZSBJLUQN Cj4gPj4gZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYi0wMCBhcyBmb2xsb3dz Og0KPiA+DQo+ID4gVGhhbmtzIGEgbG90IGZvciB0aGUgZmVlZGJhY2suIFBsZWFzZSBzZWUgc29t ZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQo+ID4NCj4gPj4NCj4gPj4gMSkgSSB0aGluayB0aGUg TE1BIGNhbiBkZWNpZGUgdG8gbW92ZSBkb3duLWxpbmsgZmxvd3Mgb25seS4gVGhlDQo+ID4+IHVw LWxpbmsgZmxvd3Mgc2hvdWxkIGJlIG1vdmVkIGJ5IHRoZSBNTiAoZWcuIHRoZSBNTiBpcyBhd2Fy ZSBvZiB0aGUNCj4gPj4gYXR0YWNobWVudCBzdGF0dXMgdmlhIGVhY2ggSUYgYW5kIGRlY2lkZSB3 aGljaCBJRiBpcyBiZXR0ZXIgZm9yDQo+ID4+IHNlbmRpbmcgdXAtbGluayBmbG93cykuIFRoZSBN QUcgc2hvdWxkIGJlIGF3YXJlIG9mIHRoZSBtb3ZlbWVudCBvZg0KPiA+DQo+ID4gT3VyIGFzc3Vt cHRpb24gaXMgdGhhdCB0aGUgTU4gZG9lcyBpbXBsZW1lbnQgdGhlIGxvZ2ljYWwgaW50ZXJmYWNl IChhcw0KPiA+IGV4cGxhaW5lZCBpbiBkcmFmdC1tZWxpYS1uZXRleHQtbG9naWNhbC1pbnRlcmZh Y2Utc3VwcG9ydC0wMSkuIFRoZSBMTUENCj4gPiBoYXMgb2YgY291cnNlIHRoZSBkaXJlY3QgY29u dHJvbCBvZiBob3cgZG93bmxpbmsgZmxvd3MgYXJlIHJvdXRlZCwgYnV0DQo+ID4gYW4gTU4gaW1w bGVtZW50aW5nIHRoZSBsb2dpY2FsIGludGVyZmFjZSB3aWxsIGp1c3QgbWlycm9yIHRoYXQgYmVo YXZpb3INCj4gPiB3aXRoIHRoZSB1cGxpbmsgcGFja2V0cy4gVGhlcmVmb3JlLCB0aGUgTE1BIGlz IHRoZSBvbmx5IGVudGl0eQ0KPiA+IGNvbnRyb2xsaW5nIGZsb3cgbW9iaWxpdHkgYm90aCBpbiBk b3dubGluayBhbmQgdXBsaW5rIGRpcmVjdGlvbnMuDQo+ID4NCj4gDQo+IA0KPiA+PiB1cC1saW5r IGZsb3dzIGFuZCBpbmZvcm0gdGhlIExNQSB0byB1cGRhdGUgaW5mb3JtYXRpb24uDQo+ID4NCj4g PiBJbiB0aGUgY3VycmVudCBkcmFmdCwgdGhlIE1BRyBpcyBpbmZvcm1lZCBhYm91dCBmbG93IG1v YmlsaXR5IG9wZXJhdGlvbnMNCj4gPiBieSB0aGUgTE1BLiBUaGVyZSBpcyBzaWduYWxpbmcgZGVm aW5lZCBmb3IgdGhhdCBwdXJwb3NlLg0KPiA+DQo+IA0KPiBMZXQncyBjb25zaWRlciB0aGUgY2Fz ZSB0aGF0IHRoZSBNTiBwZXJmb3JtcyBhIGhhbmRvZmYuIEkgdGhpbmsgaXQgaXMNCj4gYSBzcGVj aWFsIGNhc2Ugb2YgZmxvdyBtb2JpbGl0eSB3aGVuIGFsbCBmbG93cyBhcmUgbW92ZWQgZnJvbSBh bg0KPiBpbnRlcmZhY2UgdG8gYW5vdGhlci4gVGhlIE1BRyBpcyBhd2FyZSBvZiB0aGF0IGV2ZW50 IGFuZCBpbmZvcm1zIHRoZQ0KPiBMTUEgYnkgdXNpbmcgaGFuZG9mZiBpbmRpY2F0b3IuIFNvIEkg dGhpbmsgdGhhdCB3ZSBtYXkgY29uc2lkZXIgdGhlDQo+IHNhbWUgZm9yIHRoZSBjYXNlIHRoYXQg Zmxvd3MgYXJlIG1vdmVkIGJ5IHRoZSBNTi4gVGhlIE1BRyBjYW4gYmUgYXdhcmUNCj4gb2YgdGhp cyBtb3ZlbWVudCBieSBhbmFseXppbmcgdGhlIHBhY2tldHMgcmVjZWl2ZWQgZnJvbSB0aGUgTU4g YW5kDQo+IGluZm9ybSB0aGUgTE1BLg0KPiANCj4gSW4gcmVhbCBuZXR3b3JrIGJvdGggb3BlcmF0 b3IgKHRoZSBMTUEpIGFuZCB1c2VyICh0aGUgTU4pIGNhbiBzZXQgYW5kDQo+IHBlcmZvcm0gdGhl IHJ1bGVzIHRvIHNlbGVjdCB0aGUgYmVzdCBpbnRlcmZhY2UgKGFjY2VzcyB0ZWNobm9sb2dpZXMp DQo+IGZvciBzZXJ2aW5nIGEgc3BlY2lmaWMgc2VydmljZSBmbG93LiBTbyB3ZSBtYXkgYmV0dGVy IHN1cHBvcnQgZm9yIGJvdGgNCj4gb2YgdGhlbS4NCj4gDQo+IA0KPiA+Pg0KPiA+PiAyKSBJdCBp cyBuZWNlc3NhcnkgdG8gZGlzY3VzcyBhYm91dCB0aGUgZmxvdyBtb2JpbGl0eSB0cmlnZ2Vycy4g VGhlDQo+ID4+IHNpZ25hbGluZyBwcm9jZWR1cmUgYmV0d2VlbiBNQUcvTE1BIGRlcGVuZHMgb24g dHJpZ2dlci4gV2l0aCBkaWZmZXJlbnQNCj4gPj4ga2luZCBvZiB0cmlnZ2VyIHdlIGhhdmUgdG8g dXNlIGRpZmZlcmVudCBzaWduYWxpbmcgcHJvY2VkdXJlLg0KPiA+DQo+ID4gVGhlIHRyaWdnZXIg aXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGUgc29sdXRpb24gZHJhZnQuIEFueSBraW5kIG9mDQo+ ID4gdHJpZ2dlciBjb3VsZCBiZSBzdXBwb3J0ZWQuIEZvciBleGFtcGxlIGEgY2VudHJhbCBwb2xp Y3kgZW50aXR5IGNhbiBtYWtlDQo+ID4gdGhlIGRlY2lzaW9ucyBiYXNlZCBvbiB0aGUgb3ZlcmFs bCBzdGF0ZSBvZiB0aGUgbmV0d29yayBhbmQgdHJpZ2dlciB0aGUNCj4gPiBMTUEuIElNSE8sIHdo aWNoIGVudGl0eSB0cmlnZ2VycyB0aGUgTE1BIGNhbiBiZSBsZWZ0IG91dCBvZiB0aGUgc2NvcGUs DQo+ID4gYXMgaXQgZG9lcyBub3QgaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIHByb3RvY29sICh3aXRo IGN1cnJlbnQgZGVzaWduKS4NCj4gPg0KPiANCj4gSSBhZ3JlZSB0aGF0IGl0IGlzIG5vdCBuZWNl c3NhcnkgdG8gZGlzY3VzcyBkZXRhaWwgYWJvdXQgdHJpZ2dlciBpbg0KPiB0aGUgc29sdXRpb24g ZHJhZnQuDQo+IEhvd2V2ZXIsIHdlIGhhdmUgdG8gbWVudGlvbiBhYm91dCB3aGVyZSBkbyB0cmln Z2VycyBjb21lIGZyb20/LiBCYXNpbmcNCj4gb24gdGhlIHNvdXJjZSBvZiB0cmlnZ2VyIHdlIGhh dmUgdG8gdXNlIGRpZmZlcmVudCBzaWduYWxpbmcgcHJvY2VkdXJlLg0KPiANCj4gRm9yIGV4YW1w bGVzOg0KPiANCj4gLSBUaGUgTU4gcGVyZm9ybXMgbmV3IGF0dGFjaG1lbnQgLT4gVGhlIE1BRyBp cyBhd2FyZSBvZiB0aGF0IGV2ZW50IGFuZA0KPiBpbmZvcm1zIHRoZSBMTUEgYWJvdXQgbmV3IGF0 dGFjaG1lbnQgYW5kIGFza3MgdGhlIExNQSB3aGV0aGVyIHRvIG1vdmUNCj4gc29tZSBleGl0aW5n IGZsb3dzIHRvIG5ldyBhdHRhY2htZW50Lg0KPiAtIFRoZSBNQUcgcmVjZWl2ZXMgbmV3IGZsb3dz IGZyb20gYW4gaW50ZXJmYWNlIG9mIHRoZSBNTiAtPiBUaGUgTUFHDQo+IGluZm9ybXMgYW5kIGFz a3MgTE1BIHRvIGNoZWNrIHdoZXRoZXIgdGhpcyBmbG93IGlzIGEgbmV3IGZsb3cgb3IganVzdA0K PiBhIGZsb3cgbW92ZWQgZnJvbSBhbm90aGVyIGludGVyZmFjZSBvZiB0aGUgTU4uDQo+IC0gVGhl IExNQSBzZWVzIHNvbWUgY2hhbmdlcyBpbiB0aGUgbmV0d29yayBjb25kaXRpb25zIG9yIHNlcnZp Y2UNCj4gcHJvZmlsZSBvZiB0aGUgTU4gLT4gVGhlIExNQSBkZWNpZGVzIHRvIG1vdmUgc29tZSBm bG93cyB0byBnZXQgYmV0dGVyDQo+IHNlcnZpY2VzIGFuZCBpbmZvcm0gTUFHcy4NCj4gDQo+IA0K PiA+Pg0KPiA+PiAzKSBUaGUgcHJvcG9zZWQgc29sdXRpb24gcmVxdWlyZXMgbmV3IHNpZ25hbGlu ZyBtZXNzYWdlcyBhbmQgbmV3DQo+ID4+IGNhY2hpbmcgdGFibGUuIEl0IG1ha2VzIG1vcmUgY29t cGxpY2F0ZWQgZm9yIGltcGxlbWVudGluZyBhbmQNCj4gPj4gY29tYmluaW5nIHdpdGggdGhlIGV4 aXN0aW5nIHN0YW5kYXJkIHRoYW4ganVzdCBleHRlbmRpbmcgdGhlIGN1cnJlbnQNCj4gPj4gUEJV L1BCQSBtZXNzYWdlcyBhcyB3ZWxsIGFzIEJDRSBhbmQgQlVMRSBjYWNoaW5nIHRhYmxlLg0KPiA+ DQo+IA0KPiA+IFdlbGwsIHRoaXMgd2FzIGEgZGVzaWduIGRlY2lzaW9uICh0aGVyZSBtaWdodCBi ZSBvZiBjb3Vyc2Ugb3RoZXJzKS4gV2UNCj4gPiBwcmVmZXJyZWQgbm90IHRvIG92ZXJsb2FkIGV4 aXN0aW5nIHNpZ25hbGluZy4gUmVnYXJkaW5nIHRoZSBkYXRhDQo+ID4gc3RydWN0dXJlcywgdGhl eSBhcmUganVzdCBsb2dpY2FsIG9uZXMsIHRoZXkgY291bGQgYWxzbyBldmVuIGJlDQo+ID4gaW1w bGVtZW50ZWQgYnkgZXh0ZW5kaW5nIEJDRSBhbmQgQlVMLg0KPiA+DQo+ID4+DQo+ID4+IDQpIFdo YXQgYXJlIHRoZSBuZWNlc3NhcnkgcmVxdWlyZW1lbnRzIG9mIHRoZSBsb2dpY2FsIGludGVyZmFj ZSB0bw0KPiA+PiBzdXBwb3J0IGZsb3cgbW9iaWxpdHk/DQo+ID4NCj4gPiBUaGlzIHNob3VsZCBi ZSBjb3ZlcmVkIGJ5DQo+ID4gZHJhZnQtbWVsaWEtbmV0ZXh0LWxvZ2ljYWwtaW50ZXJmYWNlLXN1 cHBvcnQtMDEuDQo+ID4NCj4gDQo+IEkgZ2V0IHNvbWUgY29uZnVzZXMgYWJvdXQgdGhlIGxvZ2lj YWwgaW50ZXJmYWNlIGRlc2NyaWJlZCBpbiB0aGUgSS1EDQo+ICJkcmFmdC1tZWxpYS1uZXRleHQt bG9naWNhbC1pbnRlcmZhY2Utc3VwcG9ydC0iIGFuZCB0aGUgbG9naWNhbA0KPiBpbnRlcmZhY2Ug dXNlZCBpbiB0aGUgSS1EICIwMWRyYWZ0LWJlcm5hcmRvcy1uZXRleHQtcG1pcHY2LWZsb3dtb2It MDAiDQo+IA0KPiBJTUhPLCB3aGVuIHdlIHVzZSBsb2dpY2FsIGludGVyZmFjZSwgdGhlIChzZXQg b2YpIHByZWZpeChlcykgaXMNCj4gYXNzaWduZWQgdG8gdGhlIGxvZ2ljYWwgaW50ZXJmYWNlIG9u bHksIG5vdCB0byBwaHlzaWNhbCBpbnRlcmZhY2UuIFRoZQ0KPiBMTUEsIGF0IGxheWVyIDMsIG1h eSBzZWUgb25seSB0aGUgbG9naWNhbCBpbnRlcmZhY2UuDQo+IA0KPiBGcm9tIHRoaXMgcG9pbnQs IEkgdGhpbmsgdGhlICdVbmlxdWUgcHJlZml4IHBlciBwaHlzaWNhbCBpbnRlcmZhY2UnDQo+IHNj ZW5hcmlvIGlzIG5vdCBuZWNlc3NhcnkuDQo+IA0KPiBIb3dldmVyIGlmIHdlIGNvbnNpZGVyIHRo aXMgc2NlbmFyaW8sIHRoZW4gd2UgY2FuIGp1c3RpZnkgd2h5IHdlIG5lZWQNCj4gaXQgYXMgSnVs aWVuIHN1Z2dlc3RlZC4gQW5kIGFsc28gd2UgY2FuIGRpc2N1c3MgdG8gbWFrZSBjbGVhciB0aGF0 IHdoeQ0KPiB3ZSB1c2UgdGhlIGxvZ2ljYWwgaW50ZXJmYWNlIHRvIGhpZGUgdGhlIHBoeXNpY2Fs IGludGVyZmFjZXMgYnV0IHdlDQo+IHN0aWxsIHNlcGFyYXRlIHByZWZpeChlcykgYXNzaWdubWVu dCBiYXNpbmcgb24gcGh5c2ljYWwgaW50ZXJmYWNlcy4NCj4gDQo+IC0tLQ0KPiBUcmFuIE1pbmgg VHJ1bmcNCj4gDQo+ID4+DQo+ID4+IEkgaG9wZSB0aGF0IHdlIGNhbiBoYXZlIG1vcmUgZGlzY3Vz c2lvbiBvbiB0aGVzZSBpc3N1ZXMgYmVmb3JlIG1ha2luZw0KPiA+PiBpdCBhcyBhIFdHIGRvY3Vt ZW50Lg0KPiA+DQo+ID4gU3VyZSwgdXNlZnVsIGRpc2N1c3Npb24gYXMgdGhpcyBpcyB2ZXJ5IHZl cnkgd2VsY29tZS4gVGhhbmtzIQ0KPiA+DQo+ID4gS2luZCBSZWdhcmRzLA0KPiA+DQo+ID4gQ2Fy bG9zDQo+ID4NCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4gVHJhbiBNaW5oIFRydW5nDQo+ID4+ DQo+ID4NCj4gPiAtLQ0KPiA+IENhcmxvcyBKZXOosnMgQmVybmFyZG9zIENhbm8gICAgIGh0dHA6 Ly93d3cubmV0Y29tcy5uZXQNCj4gPiBHUEcgRlA6IEQyOUIgMEE2QSA2MzlBIEE1NjEgOTNDQSAg NEQ1NSAzNURDIEJBNEQgRDE3MCA0RjY3DQo+ID4NCj4gDQo+IA0KPiANCj4gLS0NCj4gUGguRC4s IFNlbmlvciBNZW1iZXINCj4gRWxlY3Ryb25pY3MgYW5kIFRlbGVjb21tdW5pY2F0aW9ucyBSZXNl YXJjaCBJbnN0aXR1dGUNCj4gU3RhbmRhcmRzIFJlc2VhcmNoIENlbnRlcg0KPiAxNjEgR2FqZW9u Zy1Eb25nLCBZdXNlb25nLUd1LCBEYWVqZW9uLCAzMDUtMzUwLCBLT1JFQQ0KPiBUZWwgOiArODIt NDItODYwLTExMzIsICAgRmF4IDogKzgyLTQyLTg2MS01NDA0DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4g bmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0ZXh0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpuZXRleHQgbWFpbGluZyBsaXN0DQpuZXRleHRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0ZXh0DQpfX19fX19fX19fIEluZm9ybWF0aW9uIGZy b20gRVNFVCBOT0QzMiBBbnRpdmlydXMsIHZlcnNpb24gb2YgdmlydXMgc2lnbmF0dXJlIGRhdGFi YXNlIDUwOTMgKDIwMTAwNTA2KSBfX19fX19fX19fDQpUaGUgbWVzc2FnZSB3YXMgY2hlY2tlZCBi eSBFU0VUIE5PRDMyIEFudGl2aXJ1cy4NCmh0dHA6Ly93d3cuZXNldC5jb20NCg== --=====003_Dragon701757034568_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjU5NjkiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGNvbG9yPSMwMDAwMDA+ SGkgDQphbGwsPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGNvbG9yPSMwMDAwMDA+QXMgDQpQaWVy cmljayBtZW50aW9uZWQsIEkgdGhpbmsgYSB2ZXJ5IGltcG9ydGFudCBxdWVzdGlvbiB3ZSBzaG91 bGQgc29sdmUgbm93IGlzIA0KdGhhdCB3aGV0aGVyIE1OIHNob3VsZCBpbnZvbHZlIGluIHRoZSBj b21wbGV4IG1vYmlsaXR5IG1hbmFnZW1lbnQuIEFsdGhvdWdoIHRoZSANCmRvY3VtZW50IKGwZHJh ZnQtZ3VuZGF2ZWxsaS1uZXRleHQtZXh0ZW5zaW9ucy1tb3RpdmF0aW9uLTAwLnR4dKGxIGhhcyBk ZWNsYXJlZCANCnRoYXQgdGhlIE1OIGNhbiBpbnZvbHZlIGluIHRoZSBtb2JpbGl0eSBtYW5hZ2Vt ZW50IGluIHNvbWUgc3BlY2lhbCBzY2VuYXJpb3MsIA0KaW5jbHVkaW5nIHZlcnRpY2FsIGhhbmRv dmVyLCBtdWx0aWhvbWluZyBhbmQgZmxvdyBtb2JpbGl0eSwgdGhpcyBxdWVzdGlvbiBpcyANCnN0 aWxsIGJlaW5nIGRpc2N1c3NlZCBhbmQgd2UgY2FuIG5vdCByZWFjaCBhIGNvbnNlbnN1cyBhYm91 dCBpdC4gDQo8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOOiAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPlJlZ2FyZHMs PD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8gbnMgPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOm9mZmljZTpvZmZpY2UiIC8+PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQg DQpjb2xvcj0jMDAwMDAwPlpoaXdlaSBZYW48L0ZPTlQ+PC9TUEFOPjwvUD48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMw IHNpemU9Mj4yMDEwLTA3LTIyIDwvRk9OVD48L0RJVj48Rk9OVCANCmZhY2U9VmVyZGFuYSBjb2xv cj0jMDAwMDgwIHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIg YWxpZ249bGVmdCBTSVpFPTI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xv cj0jYzBjMGMwIHNpemU9Mj48U1BBTj5nc25hYS52MjwvU1BBTj4gDQo8L0ZPTlQ+PC9ESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSPg0KPC9GT05UPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gbmV0 ZXh0LXJlcXVlc3QgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IDIwMTAtMDctMjImbmJzcDsgMDM6MDA6MTgg DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7K 1bz+yMujujwvU1RST05HPiBuZXRleHQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPtb3zOKjujwvU1RST05HPiBuZXRleHQg RGlnZXN0LCBWb2wgMTQsIElzc3VlIA0KMTQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+DQo8RElWPklmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhp cyZuYnNwO2RpZ2VzdCZuYnNwO3dpdGhvdXQmbmJzcDthbGwmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7bWVzc2FnZTwvRElWPg0KPERJVj5hdHRhY2htZW50cyZuYnNwO3lvdSZuYnNwO3dp bGwmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDt1cGRhdGUmbmJzcDt5b3VyJm5ic3A7ZGlnZXN0Jm5i c3A7b3B0aW9ucyZuYnNwO2luJm5ic3A7eW91ciZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+c3Vic2Ny aXB0aW9uLiZuYnNwOyZuYnNwO1RvJm5ic3A7ZG8mbmJzcDtzbywmbmJzcDtnbyZuYnNwO3RvJm5i c3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGV4dDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Q2xpY2smbmJzcDt0aGUm bmJzcDsnVW5zdWJzY3JpYmUmbmJzcDtvciZuYnNwO2VkaXQmbmJzcDtvcHRpb25zJyZuYnNwO2J1 dHRvbiwmbmJzcDtsb2cmbmJzcDtpbiwmbmJzcDthbmQmbmJzcDtzZXQmbmJzcDsiR2V0PC9ESVY+ DQo8RElWPk1JTUUmbmJzcDtvciZuYnNwO1BsYWluJm5ic3A7VGV4dCZuYnNwO0RpZ2VzdHM/IiZu YnNwO3RvJm5ic3A7TUlNRS4mbmJzcDsmbmJzcDtZb3UmbmJzcDtjYW4mbmJzcDtzZXQmbmJzcDt0 aGlzJm5ic3A7b3B0aW9uPC9ESVY+DQo8RElWPmdsb2JhbGx5Jm5ic3A7Zm9yJm5ic3A7YWxsJm5i c3A7dGhlJm5ic3A7bGlzdCZuYnNwO2RpZ2VzdHMmbmJzcDt5b3UmbmJzcDtyZWNlaXZlJm5ic3A7 YXQmbmJzcDt0aGlzJm5ic3A7cG9pbnQuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPlNlbmQmbmJzcDtuZXRleHQmbmJzcDttYWlsaW5nJm5ic3A7bGlz dCZuYnNwO3N1Ym1pc3Npb25zJm5ic3A7dG88L0RJVj4NCjxESVY+bmV0ZXh0QGlldGYub3JnPC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj5UbyZuYnNwO3N1YnNjcmliZSZuYnNwO29yJm5ic3A7dW5z dWJzY3JpYmUmbmJzcDt2aWEmbmJzcDt0aGUmbmJzcDtXb3JsZCZuYnNwO1dpZGUmbmJzcDtXZWIs Jm5ic3A7dmlzaXQ8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRleHQ8L0RJVj4NCjxESVY+b3IsJm5ic3A7dmlhJm5ic3A7ZW1haWwsJm5ic3A7c2Vu ZCZuYnNwO2EmbmJzcDttZXNzYWdlJm5ic3A7d2l0aCZuYnNwO3N1YmplY3QmbmJzcDtvciZuYnNw O2JvZHkmbmJzcDsnaGVscCcmbmJzcDt0bzwvRElWPg0KPERJVj5uZXRleHQtcmVxdWVzdEBpZXRm Lm9yZzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+WW91Jm5ic3A7Y2FuJm5ic3A7cmVhY2gmbmJz cDt0aGUmbmJzcDtwZXJzb24mbmJzcDttYW5hZ2luZyZuYnNwO3RoZSZuYnNwO2xpc3QmbmJzcDth dDwvRElWPg0KPERJVj5uZXRleHQtb3duZXJAaWV0Zi5vcmc8L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPldoZW4mbmJzcDtyZXBseWluZywmbmJzcDtwbGVhc2UmbmJzcDtlZGl0Jm5ic3A7eW91ciZu YnNwO1N1YmplY3QmbmJzcDtsaW5lJm5ic3A7c28mbmJzcDtpdCZuYnNwO2lzJm5ic3A7bW9yZSZu YnNwO3NwZWNpZmljPC9ESVY+DQo8RElWPnRoYW4mbmJzcDsiUmU6Jm5ic3A7Q29udGVudHMmbmJz cDtvZiZuYnNwO25ldGV4dCZuYnNwO2RpZ2VzdC4uLiI8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+X19fX19fX19fXyZuYnNwO0luZm9ybWF0aW9uJm5i c3A7ZnJvbSZuYnNwO0VTRVQmbmJzcDtOT0QzMiZuYnNwO0FudGl2aXJ1cywmbmJzcDt2ZXJzaW9u Jm5ic3A7b2YmbmJzcDt2aXJ1cyZuYnNwO3NpZ25hdHVyZSZuYnNwO2RhdGFiYXNlJm5ic3A7NTA5 MyZuYnNwOygyMDEwMDUwNikmbmJzcDtfX19fX19fX19fPC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj5UaGUmbmJzcDttZXNzYWdlJm5ic3A7d2FzJm5ic3A7Y2hlY2tlZCZuYnNwO2J5Jm5ic3A7RVNF VCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+aHR0 cDovL3d3dy5lc2V0LmNvbTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRv ZGF5J3MmbmJzcDtUb3BpY3M6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsm bmJzcDsxLiZuYnNwO1JlOiZuYnNwO0NvbW1lbnRzJm5ic3A7JmFtcDsmbmJzcDtRdWVzdGlvbnMm bmJzcDtvbiZuYnNwO3RoZTwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtJLUQ6ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21vYi0wMDwvRElW Pg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsocGllcnJpY2suc2Vp dGVAb3JhbmdlLWZ0Z3JvdXAuY29tKTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPjwvRElWPg0KPERJVj5fX19fX19fX19fJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtmcm9tJm5i c3A7RVNFVCZuYnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLCZuYnNwO3ZlcnNpb24mbmJzcDtvZiZu YnNwO3ZpcnVzJm5ic3A7c2lnbmF0dXJlJm5ic3A7ZGF0YWJhc2UmbmJzcDs1MDkzJm5ic3A7KDIw MTAwNTA2KSZuYnNwO19fX19fX19fX188L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoZSZuYnNw O21lc3NhZ2UmbmJzcDt3YXMmbmJzcDtjaGVja2VkJm5ic3A7YnkmbmJzcDtFU0VUJm5ic3A7Tk9E MzImbmJzcDtBbnRpdmlydXMuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5odHRwOi8vd3d3LmVz ZXQuY29tPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8 RElWPkZyb206Jm5ic3A7Jm5ic3A7Jmx0O3BpZXJyaWNrLnNlaXRlQG9yYW5nZS1mdGdyb3VwLmNv bSZndDs8L0RJVj4NCjxESVY+VG86Jm5ic3A7Jm5ic3A7Jmx0O3RydW5ndG1AZXRyaS5yZS5rciZn dDs8L0RJVj4NCjxESVY+Jm5ic3A7Jmx0O2NqYmNAaXQudWMzbS5lcyZndDs8L0RJVj4NCjxESVY+ U3ViamVjdDombmJzcDsmbmJzcDtSZTombmJzcDtbbmV0ZXh0XSZuYnNwO0NvbW1lbnRzJm5ic3A7 JmFtcDsmbmJzcDtRdWVzdGlvbnMmbmJzcDtvbiZuYnNwO3RoZUktRDpkcmFmdC1iZXJuYXJkb3Mt bmV0ZXh0LXBtaXB2Ni1mbG93bW9iLTAwPC9ESVY+DQo8RElWPkRhdGU6Jm5ic3A7Jm5ic3A7V2Vk MjEmbmJzcDtKdWwmbmJzcDsyMDEwJm5ic3A7MTU6NTE6NDUmbmJzcDsrMDIwMDwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+SGkmbmJzcDtUcmFuJm5ic3A7TWluaCZuYnNwO2FuZCZuYnNwO0Nhcmxv cyw8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlBsZWFzZSZuYnNwO2xldCZuYnNwO21lJm5ic3A7 anVtcCZuYnNwO2ludG8mbmJzcDt0aGlzJm5ic3A7aW50ZXJlc3RpbmcmbmJzcDtkaXNjdXNzaW9u LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VHJhbiZuYnNwO01pbmgsJm5ic3A7WW91J3JlJm5i c3A7cmlnaHQsJm5ic3A7dGhlb3JldGljYWxseSZuYnNwO2JvdGgmbmJzcDt0aGUmbmJzcDtMTUEm bmJzcDthbmQmbmJzcDt0aGUmbmJzcDtNTiZuYnNwO3Nob3VsZCZuYnNwO2Fsc28mbmJzcDtiZSZu YnNwO2FibGUmbmJzcDt0byZuYnNwO21ha2UmbmJzcDtkZWNpc2lvbiZuYnNwO2Fib3V0Jm5ic3A7 dGhlJm5ic3A7cGF0aCZuYnNwO3RvJm5ic3A7dXNlJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO2dpdmVu Jm5ic3A7SVAmbmJzcDtmbG93LiZuYnNwO0luJm5ic3A7YWRkaXRpb24mbmJzcDt0byZuYnNwO2hh bmRvdmVyJm5ic3A7dHJpZ2dlcnMmbmJzcDthdCZuYnNwO3RoZSZuYnNwO01OJm5ic3A7c2lkZSZu YnNwO3RoYXQmbmJzcDt5b3UmbmJzcDthcmUmbmJzcDtzdWdnZXN0aW5nLCZuYnNwO2l0Jm5ic3A7 bWF5Jm5ic3A7YmUmbmJzcDtub3QmbmJzcDtkZXNpcmFibGUmbmJzcDt0aGF0Jm5ic3A7dGhlJm5i c3A7TE1BJm5ic3A7ZW5mb3JjZXMmbmJzcDtpdHMmbmJzcDtkZWNpc2lvbiZuYnNwO3RvJm5ic3A7 dGhlJm5ic3A7TU4mbmJzcDtkZXNwaXRlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDt1c2VyJm5ic3A7 cHJlZmVyZW5jZXMuJm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5Ib3dldmVyLCZuYnNw O2EmbmJzcDtNTiZuYnNwO2RyaXZlbiZuYnNwO2RlY2lzaW9uJm5ic3A7aW4mbmJzcDthJm5ic3A7 bmV0d29yayZuYnNwO2Jhc2VkJm5ic3A7bW9iaWxpdHkmbmJzcDttYW5hZ2VtZW50Jm5ic3A7c29s dXRpb24mbmJzcDtpcyZuYnNwO3F1aXRlJm5ic3A7dHJpY2t5Jm5ic3A7d2l0aG91dCZuYnNwO01O Jm5ic3A7c2lnbmFsbGluZyZuYnNwOyhhbmQmbmJzcDt3ZSZuYnNwO2RlZmluaXRlbHkmbmJzcDt3 YW50Jm5ic3A7dG8mbmJzcDthdm9pZCZuYnNwO3N1Y2gmbmJzcDthJm5ic3A7c2lnbmFsbGluZywm bmJzcDtJJm5ic3A7ZG9uJ3QmbmJzcDt3YW50Jm5ic3A7dG8mbmJzcDtyZW9wZW4mbmJzcDt0aGUm bmJzcDtkZWJhdGUmbmJzcDs6LSkpLiZuYnNwO0ZvciZuYnNwO2V4YW1wbGUsJm5ic3A7eW91Jm5i c3A7d3JvdGU6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4iVGhlJm5ic3A7TUFHJm5ic3A7Y2Fu Jm5ic3A7YmUmbmJzcDthd2FyZSZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO21vdmVtZW50Jm5ic3A7 YnkmbmJzcDthbmFseXppbmcmbmJzcDt0aGUmbmJzcDtwYWNrZXRzJm5ic3A7cmVjZWl2ZWQmbmJz cDtmcm9tJm5ic3A7dGhlJm5ic3A7TU4mbmJzcDthbmQmbmJzcDtpbmZvcm0mbmJzcDt0aGUmbmJz cDtMTUEuIjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SSZuYnNwO2Rvbid0Jm5ic3A7dGhpbmsm bmJzcDtzdWNoJm5ic3A7YSZuYnNwO3NpbXBsZSZuYnNwO3NvbHV0aW9uJm5ic3A7Y291bGQmbmJz cDtiZSZuYnNwO3N1ZmZpY2llbnQsJm5ic3A7c2luY2UmbmJzcDt0aGVyZSZuYnNwO2FyZSZuYnNw O3NvbWUmbmJzcDtjYXNlcyZuYnNwO3doZXJlJm5ic3A7dGhlJm5ic3A7TU4mbmJzcDtkb2VzJm5i c3A7bm90Jm5ic3A7dXNlJm5ic3A7dGhlJm5ic3A7dXBsaW5rJm5ic3A7dmVyeSZuYnNwO29mdGVu LCZuYnNwO2UuZy4mbmJzcDtSVFAmbmJzcDtzdHJlYW1pbmcuJm5ic3A7PC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj5TbywmbmJzcDt0cnlpbmcmbmJzcDt0byZuYnNwO3N1cHBvcnQmbmJzcDt0aGUm bmJzcDtNTiZuYnNwO2RyaXZlbiZuYnNwO3JvdXRpbmcmbmJzcDtkZWNpc2lvbiZuYnNwO3dvdWxk Jm5ic3A7YnJpbmcmbmJzcDthZGRpdGlvbmFsJm5ic3A7Y29tcGxleGl0eSZuYnNwO2FuZCZuYnNw O2RlbGF5Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtkZXNpZ24mbmJzcDtvZiZuYnNwO2EmbmJzcDtz b2x1dGlvbi4mbmJzcDtTbywmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtzYWtlJm5ic3A7b2YmbmJz cDtwcmFnbWF0aXNtLCZuYnNwO2l0Jm5ic3A7bWFrZXMmbmJzcDtzZW5zZSZuYnNwO3RvJm5ic3A7 Zm9jdXMsJm5ic3A7aW4mbmJzcDthJm5ic3A7Zmlyc3QmbmJzcDtzdGVwLCZuYnNwO29uJm5ic3A7 YSZuYnNwO3JvdXRpbmcmbmJzcDtkZWNpc2lvbiZuYnNwO2RyaXZlbiZuYnNwO2J5Jm5ic3A7dGhl Jm5ic3A7TE1BJm5ic3A7d2hlcmUmbmJzcDt0aGUmbmJzcDtNTiZuYnNwO2p1c3QmbmJzcDt1cGRh dGVzJm5ic3A7aXRzJm5ic3A7dXBsaW5rJm5ic3A7cGF0aCZuYnNwO2FjY29yZGluZyZuYnNwO3Rv Jm5ic3A7d2hlcmUmbmJzcDtwYWNrZXRzJm5ic3A7YXJlJm5ic3A7cmVjZWl2ZWQuPC9ESVY+DQo8 RElWPjwvRElWPg0KPERJVj5UaGVuJm5ic3A7d2UmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDtjbGFy aWZ5Jm5ic3A7dGhlJm5ic3A7cmVxdWlyZW1lbnQmbmJzcDtmb3ImbmJzcDtoYW5kb3ZlciZuYnNw O3RyaWdnZXJzJm5ic3A7dG8mbmJzcDtiZSZuYnNwO3Byb2Nlc3NlZCZuYnNwO2F0Jm5ic3A7dGhl Jm5ic3A7TU4mbmJzcDtzaWRlJm5ic3A7b25seS4mbmJzcDtJZiZuYnNwO3NvLCZuYnNwO3dlJm5i c3A7Y291bGQmbmJzcDt0aGluayZuYnNwO2Fib3V0Jm5ic3A7ZXh0ZW5zaW9uJm5ic3A7dG8mbmJz cDt0aGUmbmJzcDtiYXNlJm5ic3A7c29sdXRpb24mbmJzcDthcyZuYnNwO2RyYWZ0ZWQmbmJzcDtp biZuYnNwO2RyYWZ0LWJlcm5hcmRvcy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlJlZ2FyZHMs PC9ESVY+DQo8RElWPlBpZXJyaWNrPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 LS0tLS1NZXNzYWdlJm5ic3A7ZCdvcmlnaW5lLS0tLS08L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0Rl Jm5ic3A7OiZuYnNwO25ldGV4dC1ib3VuY2VzQGlldGYub3JnJm5ic3A7W21haWx0bzpuZXRleHQt Ym91bmNlc0BpZXRmLm9yZ10mbmJzcDtEZSZuYnNwO2xhJm5ic3A7cGFydDwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7ZGUmbmJzcDtUcmFuJm5ic3A7TWluaCZuYnNwO1RydW5nPC9ESVY+DQo8RElWPiZn dDsmbmJzcDtFbnZveaimJm5ic3A7OiZuYnNwO21lcmNyZWRpJm5ic3A7MjEmbmJzcDtqdWlsbGV0 Jm5ic3A7MjAxMCZuYnNwOzEyOjE3PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmQWdyYXZlOyZuYnNw OzombmJzcDtjamJjQGl0LnVjM20uZXM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0NjJm5ic3A7OiZu YnNwO25ldGV4dEBpZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7T2JqZXQmbmJzcDs6Jm5i c3A7UmU6Jm5ic3A7W25ldGV4dF0mbmJzcDtDb21tZW50cyZuYnNwOyZhbXA7Jm5ic3A7UXVlc3Rp b25zJm5ic3A7b24mbmJzcDt0aGUmbmJzcDtJLUQ6ZHJhZnQtYmVybmFyZG9zLTwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7bmV0ZXh0LXBtaXB2Ni1mbG93bW9iLTAwPC9ESVY+DQo8RElWPiZndDsmbmJz cDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0hpJm5ic3A7QmVybmFyZG9zLDwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtUaGFuayZuYnNwO3lvdSZuYnNwO2ZvciZu YnNwO3lvdXImbmJzcDtyZXBseS48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1Bscy4mbmJzcDtzZWUm bmJzcDtteSZuYnNwO3JlcGxpZXMmbmJzcDtpbmxpbmUuPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzIwMTAvNy8yMSZuYnNwO0NhcmxvcyZuYnNwO0plc6iycyZu YnNwO0Jlcm5hcmRvcyZuYnNwO0Nhbm8mbmJzcDsmbHQ7Y2piY0BpdC51YzNtLmVzJmd0Ozo8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDtIaSZuYnNwO1RyYW4mbmJzcDtNaW5oLDwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO09u Jm5ic3A7VHVlLCZuYnNwOzIwMTAtMDctMjAmbmJzcDthdCZuYnNwOzE3OjQ0Jm5ic3A7KzA5MDAs Jm5ic3A7VHJhbiZuYnNwO01pbmgmbmJzcDtUcnVuZyZuYnNwO3dyb3RlOjwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtIaSZuYnNwO0Jlcm5hcmRvcyZuYnNwO2FuZCZuYnNwO2Fs bCw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsm Z3Q7Jmd0OyZuYnNwO0kmbmJzcDtoYXZlJm5ic3A7c29tZSZuYnNwO2NvbW1lbnRzJm5ic3A7YW5k Jm5ic3A7cXVlc3Rpb25zJm5ic3A7b24mbmJzcDt0aGUmbmJzcDtJLUQ8L0RJVj4NCjxESVY+Jmd0 OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7ZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1wbWlwdjYtZmxvd21v Yi0wMCZuYnNwO2FzJm5ic3A7Zm9sbG93czo8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDs8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDtUaGFua3MmbmJzcDthJm5ic3A7bG90Jm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7ZmVlZGJhY2suJm5ic3A7UGxlYXNlJm5ic3A7c2VlJm5ic3A7c29t ZSZuYnNwO2NvbW1lbnRzJm5ic3A7aW5saW5lJm5ic3A7YmVsb3cuPC9ESVY+DQo8RElWPiZndDsm bmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7Jmd0OyZndDsmbmJzcDsxKSZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3RoZSZuYnNwO0xN QSZuYnNwO2NhbiZuYnNwO2RlY2lkZSZuYnNwO3RvJm5ic3A7bW92ZSZuYnNwO2Rvd24tbGluayZu YnNwO2Zsb3dzJm5ic3A7b25seS4mbmJzcDtUaGU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsm Z3Q7Jm5ic3A7dXAtbGluayZuYnNwO2Zsb3dzJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDttb3Zl ZCZuYnNwO2J5Jm5ic3A7dGhlJm5ic3A7TU4mbmJzcDsoZWcuJm5ic3A7dGhlJm5ic3A7TU4mbmJz cDtpcyZuYnNwO2F3YXJlJm5ic3A7b2YmbmJzcDt0aGU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZn dDsmZ3Q7Jm5ic3A7YXR0YWNobWVudCZuYnNwO3N0YXR1cyZuYnNwO3ZpYSZuYnNwO2VhY2gmbmJz cDtJRiZuYnNwO2FuZCZuYnNwO2RlY2lkZSZuYnNwO3doaWNoJm5ic3A7SUYmbmJzcDtpcyZuYnNw O2JldHRlciZuYnNwO2ZvcjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtzZW5k aW5nJm5ic3A7dXAtbGluayZuYnNwO2Zsb3dzKS4mbmJzcDtUaGUmbmJzcDtNQUcmbmJzcDtzaG91 bGQmbmJzcDtiZSZuYnNwO2F3YXJlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttb3ZlbWVudCZuYnNw O29mPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7 Jm5ic3A7T3VyJm5ic3A7YXNzdW1wdGlvbiZuYnNwO2lzJm5ic3A7dGhhdCZuYnNwO3RoZSZuYnNw O01OJm5ic3A7ZG9lcyZuYnNwO2ltcGxlbWVudCZuYnNwO3RoZSZuYnNwO2xvZ2ljYWwmbmJzcDtp bnRlcmZhY2UmbmJzcDsoYXM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDtleHBsYWlu ZWQmbmJzcDtpbiZuYnNwO2RyYWZ0LW1lbGlhLW5ldGV4dC1sb2dpY2FsLWludGVyZmFjZS1zdXBw b3J0LTAxKS4mbmJzcDtUaGUmbmJzcDtMTUE8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJz cDtoYXMmbmJzcDtvZiZuYnNwO2NvdXJzZSZuYnNwO3RoZSZuYnNwO2RpcmVjdCZuYnNwO2NvbnRy b2wmbmJzcDtvZiZuYnNwO2hvdyZuYnNwO2Rvd25saW5rJm5ic3A7Zmxvd3MmbmJzcDthcmUmbmJz cDtyb3V0ZWQsJm5ic3A7YnV0PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7YW4mbmJz cDtNTiZuYnNwO2ltcGxlbWVudGluZyZuYnNwO3RoZSZuYnNwO2xvZ2ljYWwmbmJzcDtpbnRlcmZh Y2UmbmJzcDt3aWxsJm5ic3A7anVzdCZuYnNwO21pcnJvciZuYnNwO3RoYXQmbmJzcDtiZWhhdmlv cjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO3dpdGgmbmJzcDt0aGUmbmJzcDt1cGxp bmsmbmJzcDtwYWNrZXRzLiZuYnNwO1RoZXJlZm9yZSwmbmJzcDt0aGUmbmJzcDtMTUEmbmJzcDtp cyZuYnNwO3RoZSZuYnNwO29ubHkmbmJzcDtlbnRpdHk8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZn dDsmbmJzcDtjb250cm9sbGluZyZuYnNwO2Zsb3cmbmJzcDttb2JpbGl0eSZuYnNwO2JvdGgmbmJz cDtpbiZuYnNwO2Rvd25saW5rJm5ic3A7YW5kJm5ic3A7dXBsaW5rJm5ic3A7ZGlyZWN0aW9ucy48 L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO3VwLWxp bmsmbmJzcDtmbG93cyZuYnNwO2FuZCZuYnNwO2luZm9ybSZuYnNwO3RoZSZuYnNwO0xNQSZuYnNw O3RvJm5ic3A7dXBkYXRlJm5ic3A7aW5mb3JtYXRpb24uPC9ESVY+DQo8RElWPiZndDsmbmJzcDsm Z3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7SW4mbmJzcDt0aGUmbmJzcDtjdXJy ZW50Jm5ic3A7ZHJhZnQsJm5ic3A7dGhlJm5ic3A7TUFHJm5ic3A7aXMmbmJzcDtpbmZvcm1lZCZu YnNwO2Fib3V0Jm5ic3A7ZmxvdyZuYnNwO21vYmlsaXR5Jm5ic3A7b3BlcmF0aW9uczwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO2J5Jm5ic3A7dGhlJm5ic3A7TE1BLiZuYnNwO1RoZXJl Jm5ic3A7aXMmbmJzcDtzaWduYWxpbmcmbmJzcDtkZWZpbmVkJm5ic3A7Zm9yJm5ic3A7dGhhdCZu YnNwO3B1cnBvc2UuPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsm bmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0xldCdzJm5ic3A7Y29uc2lkZXImbmJzcDt0aGUm bmJzcDtjYXNlJm5ic3A7dGhhdCZuYnNwO3RoZSZuYnNwO01OJm5ic3A7cGVyZm9ybXMmbmJzcDth Jm5ic3A7aGFuZG9mZi4mbmJzcDtJJm5ic3A7dGhpbmsmbmJzcDtpdCZuYnNwO2lzPC9ESVY+DQo8 RElWPiZndDsmbmJzcDthJm5ic3A7c3BlY2lhbCZuYnNwO2Nhc2UmbmJzcDtvZiZuYnNwO2Zsb3cm bmJzcDttb2JpbGl0eSZuYnNwO3doZW4mbmJzcDthbGwmbmJzcDtmbG93cyZuYnNwO2FyZSZuYnNw O21vdmVkJm5ic3A7ZnJvbSZuYnNwO2FuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtpbnRlcmZhY2Um bmJzcDt0byZuYnNwO2Fub3RoZXIuJm5ic3A7VGhlJm5ic3A7TUFHJm5ic3A7aXMmbmJzcDthd2Fy ZSZuYnNwO29mJm5ic3A7dGhhdCZuYnNwO2V2ZW50Jm5ic3A7YW5kJm5ic3A7aW5mb3JtcyZuYnNw O3RoZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7TE1BJm5ic3A7YnkmbmJzcDt1c2luZyZuYnNwO2hh bmRvZmYmbmJzcDtpbmRpY2F0b3IuJm5ic3A7U28mbmJzcDtJJm5ic3A7dGhpbmsmbmJzcDt0aGF0 Jm5ic3A7d2UmbmJzcDttYXkmbmJzcDtjb25zaWRlciZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7c2FtZSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2Nhc2UmbmJzcDt0aGF0Jm5ic3A7Zmxv d3MmbmJzcDthcmUmbmJzcDttb3ZlZCZuYnNwO2J5Jm5ic3A7dGhlJm5ic3A7TU4uJm5ic3A7VGhl Jm5ic3A7TUFHJm5ic3A7Y2FuJm5ic3A7YmUmbmJzcDthd2FyZTwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7b2YmbmJzcDt0aGlzJm5ic3A7bW92ZW1lbnQmbmJzcDtieSZuYnNwO2FuYWx5emluZyZuYnNw O3RoZSZuYnNwO3BhY2tldHMmbmJzcDtyZWNlaXZlZCZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtN TiZuYnNwO2FuZDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aW5mb3JtJm5ic3A7dGhlJm5ic3A7TE1B LjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtJbiZuYnNwO3Jl YWwmbmJzcDtuZXR3b3JrJm5ic3A7Ym90aCZuYnNwO29wZXJhdG9yJm5ic3A7KHRoZSZuYnNwO0xN QSkmbmJzcDthbmQmbmJzcDt1c2VyJm5ic3A7KHRoZSZuYnNwO01OKSZuYnNwO2NhbiZuYnNwO3Nl dCZuYnNwO2FuZDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7cGVyZm9ybSZuYnNwO3RoZSZuYnNwO3J1 bGVzJm5ic3A7dG8mbmJzcDtzZWxlY3QmbmJzcDt0aGUmbmJzcDtiZXN0Jm5ic3A7aW50ZXJmYWNl Jm5ic3A7KGFjY2VzcyZuYnNwO3RlY2hub2xvZ2llcyk8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2Zv ciZuYnNwO3NlcnZpbmcmbmJzcDthJm5ic3A7c3BlY2lmaWMmbmJzcDtzZXJ2aWNlJm5ic3A7Zmxv dy4mbmJzcDtTbyZuYnNwO3dlJm5ic3A7bWF5Jm5ic3A7YmV0dGVyJm5ic3A7c3VwcG9ydCZuYnNw O2ZvciZuYnNwO2JvdGg8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO29mJm5ic3A7dGhlbS48L0RJVj4N CjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsm bmJzcDsmZ3Q7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDsyKSZuYnNw O0l0Jm5ic3A7aXMmbmJzcDtuZWNlc3NhcnkmbmJzcDt0byZuYnNwO2Rpc2N1c3MmbmJzcDthYm91 dCZuYnNwO3RoZSZuYnNwO2Zsb3cmbmJzcDttb2JpbGl0eSZuYnNwO3RyaWdnZXJzLiZuYnNwO1Ro ZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtzaWduYWxpbmcmbmJzcDtwcm9j ZWR1cmUmbmJzcDtiZXR3ZWVuJm5ic3A7TUFHL0xNQSZuYnNwO2RlcGVuZHMmbmJzcDtvbiZuYnNw O3RyaWdnZXIuJm5ic3A7V2l0aCZuYnNwO2RpZmZlcmVudDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 Jmd0OyZndDsmbmJzcDtraW5kJm5ic3A7b2YmbmJzcDt0cmlnZ2VyJm5ic3A7d2UmbmJzcDtoYXZl Jm5ic3A7dG8mbmJzcDt1c2UmbmJzcDtkaWZmZXJlbnQmbmJzcDtzaWduYWxpbmcmbmJzcDtwcm9j ZWR1cmUuPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsm Z3Q7Jm5ic3A7VGhlJm5ic3A7dHJpZ2dlciZuYnNwO2lzJm5ic3A7b3V0Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzY29wZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c29sdXRpb24mbmJzcDtkcmFmdC4m bmJzcDtBbnkmbmJzcDtraW5kJm5ic3A7b2Y8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJz cDt0cmlnZ2VyJm5ic3A7Y291bGQmbmJzcDtiZSZuYnNwO3N1cHBvcnRlZC4mbmJzcDtGb3ImbmJz cDtleGFtcGxlJm5ic3A7YSZuYnNwO2NlbnRyYWwmbmJzcDtwb2xpY3kmbmJzcDtlbnRpdHkmbmJz cDtjYW4mbmJzcDttYWtlPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7dGhlJm5ic3A7 ZGVjaXNpb25zJm5ic3A7YmFzZWQmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO292ZXJhbGwmbmJzcDtz dGF0ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bmV0d29yayZuYnNwO2FuZCZuYnNwO3RyaWdnZXIm bmJzcDt0aGU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDtMTUEuJm5ic3A7SU1ITywm bmJzcDt3aGljaCZuYnNwO2VudGl0eSZuYnNwO3RyaWdnZXJzJm5ic3A7dGhlJm5ic3A7TE1BJm5i c3A7Y2FuJm5ic3A7YmUmbmJzcDtsZWZ0Jm5ic3A7b3V0Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz Y29wZSw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDthcyZuYnNwO2l0Jm5ic3A7ZG9l cyZuYnNwO25vdCZuYnNwO2hhdmUmbmJzcDthbiZuYnNwO2ltcGFjdCZuYnNwO29uJm5ic3A7dGhl Jm5ic3A7cHJvdG9jb2wmbmJzcDsod2l0aCZuYnNwO2N1cnJlbnQmbmJzcDtkZXNpZ24pLjwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElW PiZndDsmbmJzcDtJJm5ic3A7YWdyZWUmbmJzcDt0aGF0Jm5ic3A7aXQmbmJzcDtpcyZuYnNwO25v dCZuYnNwO25lY2Vzc2FyeSZuYnNwO3RvJm5ic3A7ZGlzY3VzcyZuYnNwO2RldGFpbCZuYnNwO2Fi b3V0Jm5ic3A7dHJpZ2dlciZuYnNwO2luPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0aGUmbmJzcDtz b2x1dGlvbiZuYnNwO2RyYWZ0LjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SG93ZXZlciwmbmJzcDt3 ZSZuYnNwO2hhdmUmbmJzcDt0byZuYnNwO21lbnRpb24mbmJzcDthYm91dCZuYnNwO3doZXJlJm5i c3A7ZG8mbmJzcDt0cmlnZ2VycyZuYnNwO2NvbWUmbmJzcDtmcm9tPy4mbmJzcDtCYXNpbmc8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwO29uJm5ic3A7dGhlJm5ic3A7c291cmNlJm5ic3A7b2YmbmJzcDt0 cmlnZ2VyJm5ic3A7d2UmbmJzcDtoYXZlJm5ic3A7dG8mbmJzcDt1c2UmbmJzcDtkaWZmZXJlbnQm bmJzcDtzaWduYWxpbmcmbmJzcDtwcm9jZWR1cmUuPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJ Vj4NCjxESVY+Jmd0OyZuYnNwO0ZvciZuYnNwO2V4YW1wbGVzOjwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDstJm5ic3A7VGhlJm5ic3A7TU4mbmJzcDtwZXJmb3Jt cyZuYnNwO25ldyZuYnNwO2F0dGFjaG1lbnQmbmJzcDstJmd0OyZuYnNwO1RoZSZuYnNwO01BRyZu YnNwO2lzJm5ic3A7YXdhcmUmbmJzcDtvZiZuYnNwO3RoYXQmbmJzcDtldmVudCZuYnNwO2FuZDwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7aW5mb3JtcyZuYnNwO3RoZSZuYnNwO0xNQSZuYnNwO2Fib3V0 Jm5ic3A7bmV3Jm5ic3A7YXR0YWNobWVudCZuYnNwO2FuZCZuYnNwO2Fza3MmbmJzcDt0aGUmbmJz cDtMTUEmbmJzcDt3aGV0aGVyJm5ic3A7dG8mbmJzcDttb3ZlPC9ESVY+DQo8RElWPiZndDsmbmJz cDtzb21lJm5ic3A7ZXhpdGluZyZuYnNwO2Zsb3dzJm5ic3A7dG8mbmJzcDtuZXcmbmJzcDthdHRh Y2htZW50LjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7LSZuYnNwO1RoZSZuYnNwO01BRyZuYnNwO3Jl Y2VpdmVzJm5ic3A7bmV3Jm5ic3A7Zmxvd3MmbmJzcDtmcm9tJm5ic3A7YW4mbmJzcDtpbnRlcmZh Y2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO01OJm5ic3A7LSZndDsmbmJzcDtUaGUmbmJzcDtNQUc8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2luZm9ybXMmbmJzcDthbmQmbmJzcDthc2tzJm5ic3A7TE1B Jm5ic3A7dG8mbmJzcDtjaGVjayZuYnNwO3doZXRoZXImbmJzcDt0aGlzJm5ic3A7ZmxvdyZuYnNw O2lzJm5ic3A7YSZuYnNwO25ldyZuYnNwO2Zsb3cmbmJzcDtvciZuYnNwO2p1c3Q8L0RJVj4NCjxE SVY+Jmd0OyZuYnNwO2EmbmJzcDtmbG93Jm5ic3A7bW92ZWQmbmJzcDtmcm9tJm5ic3A7YW5vdGhl ciZuYnNwO2ludGVyZmFjZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7TU4uPC9ESVY+DQo8RElWPiZn dDsmbmJzcDstJm5ic3A7VGhlJm5ic3A7TE1BJm5ic3A7c2VlcyZuYnNwO3NvbWUmbmJzcDtjaGFu Z2VzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtuZXR3b3JrJm5ic3A7Y29uZGl0aW9ucyZuYnNwO29y Jm5ic3A7c2VydmljZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7cHJvZmlsZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7TU4mbmJzcDstJmd0OyZuYnNwO1RoZSZuYnNwO0xNQSZuYnNwO2RlY2lkZXMmbmJz cDt0byZuYnNwO21vdmUmbmJzcDtzb21lJm5ic3A7Zmxvd3MmbmJzcDt0byZuYnNwO2dldCZuYnNw O2JldHRlcjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c2VydmljZXMmbmJzcDthbmQmbmJzcDtpbmZv cm0mbmJzcDtNQUdzLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJz cDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsm Z3Q7Jmd0OyZuYnNwOzMpJm5ic3A7VGhlJm5ic3A7cHJvcG9zZWQmbmJzcDtzb2x1dGlvbiZuYnNw O3JlcXVpcmVzJm5ic3A7bmV3Jm5ic3A7c2lnbmFsaW5nJm5ic3A7bWVzc2FnZXMmbmJzcDthbmQm bmJzcDtuZXc8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7Y2FjaGluZyZuYnNw O3RhYmxlLiZuYnNwO0l0Jm5ic3A7bWFrZXMmbmJzcDttb3JlJm5ic3A7Y29tcGxpY2F0ZWQmbmJz cDtmb3ImbmJzcDtpbXBsZW1lbnRpbmcmbmJzcDthbmQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZn dDsmZ3Q7Jm5ic3A7Y29tYmluaW5nJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO2V4aXN0aW5nJm5i c3A7c3RhbmRhcmQmbmJzcDt0aGFuJm5ic3A7anVzdCZuYnNwO2V4dGVuZGluZyZuYnNwO3RoZSZu YnNwO2N1cnJlbnQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7UEJVL1BCQSZu YnNwO21lc3NhZ2VzJm5ic3A7YXMmbmJzcDt3ZWxsJm5ic3A7YXMmbmJzcDtCQ0UmbmJzcDthbmQm bmJzcDtCVUxFJm5ic3A7Y2FjaGluZyZuYnNwO3RhYmxlLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5i c3A7V2VsbCwmbmJzcDt0aGlzJm5ic3A7d2FzJm5ic3A7YSZuYnNwO2Rlc2lnbiZuYnNwO2RlY2lz aW9uJm5ic3A7KHRoZXJlJm5ic3A7bWlnaHQmbmJzcDtiZSZuYnNwO29mJm5ic3A7Y291cnNlJm5i c3A7b3RoZXJzKS4mbmJzcDtXZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO3ByZWZl cnJlZCZuYnNwO25vdCZuYnNwO3RvJm5ic3A7b3ZlcmxvYWQmbmJzcDtleGlzdGluZyZuYnNwO3Np Z25hbGluZy4mbmJzcDtSZWdhcmRpbmcmbmJzcDt0aGUmbmJzcDtkYXRhPC9ESVY+DQo8RElWPiZn dDsmbmJzcDsmZ3Q7Jm5ic3A7c3RydWN0dXJlcywmbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7anVz dCZuYnNwO2xvZ2ljYWwmbmJzcDtvbmVzLCZuYnNwO3RoZXkmbmJzcDtjb3VsZCZuYnNwO2Fsc28m bmJzcDtldmVuJm5ic3A7YmU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDtpbXBsZW1l bnRlZCZuYnNwO2J5Jm5ic3A7ZXh0ZW5kaW5nJm5ic3A7QkNFJm5ic3A7YW5kJm5ic3A7QlVMLjwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZndDs8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7NCkmbmJzcDtXaGF0Jm5ic3A7YXJl Jm5ic3A7dGhlJm5ic3A7bmVjZXNzYXJ5Jm5ic3A7cmVxdWlyZW1lbnRzJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtsb2dpY2FsJm5ic3A7aW50ZXJmYWNlJm5ic3A7dG88L0RJVj4NCjxESVY+Jmd0OyZu YnNwOyZndDsmZ3Q7Jm5ic3A7c3VwcG9ydCZuYnNwO2Zsb3cmbmJzcDttb2JpbGl0eT88L0RJVj4N CjxESVY+Jmd0OyZuYnNwOyZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDtUaGlz Jm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtjb3ZlcmVkJm5ic3A7Ynk8L0RJVj4NCjxESVY+Jmd0 OyZuYnNwOyZndDsmbmJzcDtkcmFmdC1tZWxpYS1uZXRleHQtbG9naWNhbC1pbnRlcmZhY2Utc3Vw cG9ydC0wMS48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNw OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SSZuYnNwO2dldCZuYnNwO3NvbWUmbmJzcDtjb25mdXNl cyZuYnNwO2Fib3V0Jm5ic3A7dGhlJm5ic3A7bG9naWNhbCZuYnNwO2ludGVyZmFjZSZuYnNwO2Rl c2NyaWJlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7SS1EPC9ESVY+DQo8RElWPiZndDsmbmJzcDsi ZHJhZnQtbWVsaWEtbmV0ZXh0LWxvZ2ljYWwtaW50ZXJmYWNlLXN1cHBvcnQtIiZuYnNwO2FuZCZu YnNwO3RoZSZuYnNwO2xvZ2ljYWw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2ludGVyZmFjZSZuYnNw O3VzZWQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO0ktRCZuYnNwOyIwMWRyYWZ0LWJlcm5hcmRvcy1u ZXRleHQtcG1pcHY2LWZsb3dtb2ItMDAiPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4NCjxE SVY+Jmd0OyZuYnNwO0lNSE8sJm5ic3A7d2hlbiZuYnNwO3dlJm5ic3A7dXNlJm5ic3A7bG9naWNh bCZuYnNwO2ludGVyZmFjZSwmbmJzcDt0aGUmbmJzcDsoc2V0Jm5ic3A7b2YpJm5ic3A7cHJlZml4 KGVzKSZuYnNwO2lzPC9ESVY+DQo8RElWPiZndDsmbmJzcDthc3NpZ25lZCZuYnNwO3RvJm5ic3A7 dGhlJm5ic3A7bG9naWNhbCZuYnNwO2ludGVyZmFjZSZuYnNwO29ubHksJm5ic3A7bm90Jm5ic3A7 dG8mbmJzcDtwaHlzaWNhbCZuYnNwO2ludGVyZmFjZS4mbmJzcDtUaGU8L0RJVj4NCjxESVY+Jmd0 OyZuYnNwO0xNQSwmbmJzcDthdCZuYnNwO2xheWVyJm5ic3A7MywmbmJzcDttYXkmbmJzcDtzZWUm bmJzcDtvbmx5Jm5ic3A7dGhlJm5ic3A7bG9naWNhbCZuYnNwO2ludGVyZmFjZS48L0RJVj4NCjxE SVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RnJvbSZuYnNwO3RoaXMmbmJzcDtw b2ludCwmbmJzcDtJJm5ic3A7dGhpbmsmbmJzcDt0aGUmbmJzcDsnVW5pcXVlJm5ic3A7cHJlZml4 Jm5ic3A7cGVyJm5ic3A7cGh5c2ljYWwmbmJzcDtpbnRlcmZhY2UnPC9ESVY+DQo8RElWPiZndDsm bmJzcDtzY2VuYXJpbyZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7bmVjZXNzYXJ5LjwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtIb3dldmVyJm5ic3A7aWYmbmJzcDt3 ZSZuYnNwO2NvbnNpZGVyJm5ic3A7dGhpcyZuYnNwO3NjZW5hcmlvLCZuYnNwO3RoZW4mbmJzcDt3 ZSZuYnNwO2NhbiZuYnNwO2p1c3RpZnkmbmJzcDt3aHkmbmJzcDt3ZSZuYnNwO25lZWQ8L0RJVj4N CjxESVY+Jmd0OyZuYnNwO2l0Jm5ic3A7YXMmbmJzcDtKdWxpZW4mbmJzcDtzdWdnZXN0ZWQuJm5i c3A7QW5kJm5ic3A7YWxzbyZuYnNwO3dlJm5ic3A7Y2FuJm5ic3A7ZGlzY3VzcyZuYnNwO3RvJm5i c3A7bWFrZSZuYnNwO2NsZWFyJm5ic3A7dGhhdCZuYnNwO3doeTwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7d2UmbmJzcDt1c2UmbmJzcDt0aGUmbmJzcDtsb2dpY2FsJm5ic3A7aW50ZXJmYWNlJm5ic3A7 dG8mbmJzcDtoaWRlJm5ic3A7dGhlJm5ic3A7cGh5c2ljYWwmbmJzcDtpbnRlcmZhY2VzJm5ic3A7 YnV0Jm5ic3A7d2U8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3N0aWxsJm5ic3A7c2VwYXJhdGUmbmJz cDtwcmVmaXgoZXMpJm5ic3A7YXNzaWdubWVudCZuYnNwO2Jhc2luZyZuYnNwO29uJm5ic3A7cGh5 c2ljYWwmbmJzcDtpbnRlcmZhY2VzLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElW PiZndDsmbmJzcDstLS08L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1RyYW4mbmJzcDtNaW5oJm5ic3A7 VHJ1bmc8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZn dDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmZ3Q7Jm5ic3A7SSZuYnNwO2hvcGUmbmJzcDt0 aGF0Jm5ic3A7d2UmbmJzcDtjYW4mbmJzcDtoYXZlJm5ic3A7bW9yZSZuYnNwO2Rpc2N1c3Npb24m bmJzcDtvbiZuYnNwO3RoZXNlJm5ic3A7aXNzdWVzJm5ic3A7YmVmb3JlJm5ic3A7bWFraW5nPC9E SVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jmd0OyZuYnNwO2l0Jm5ic3A7YXMmbmJzcDthJm5ic3A7 V0cmbmJzcDtkb2N1bWVudC48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDs8L0RJVj4NCjxESVY+ Jmd0OyZuYnNwOyZndDsmbmJzcDtTdXJlLCZuYnNwO3VzZWZ1bCZuYnNwO2Rpc2N1c3Npb24mbmJz cDthcyZuYnNwO3RoaXMmbmJzcDtpcyZuYnNwO3ZlcnkmbmJzcDt2ZXJ5Jm5ic3A7d2VsY29tZS4m bmJzcDtUaGFua3MhPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsm bmJzcDsmZ3Q7Jm5ic3A7S2luZCZuYnNwO1JlZ2FyZHMsPC9ESVY+DQo8RElWPiZndDsmbmJzcDsm Z3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Q2FybG9zPC9ESVY+DQo8RElWPiZn dDsmbmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jmd0OzwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7Jmd0OyZndDsmbmJzcDtSZWdhcmRzLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0 OyZndDsmbmJzcDtUcmFuJm5ic3A7TWluaCZuYnNwO1RydW5nPC9ESVY+DQo8RElWPiZndDsmbmJz cDsmZ3Q7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7Jmd0OyZuYnNwOy0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Q2FybG9zJm5i c3A7SmVzqLJzJm5ic3A7QmVybmFyZG9zJm5ic3A7Q2FubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2h0dHA6Ly93d3cubmV0Y29tcy5uZXQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsm bmJzcDtHUEcmbmJzcDtGUDombmJzcDtEMjlCJm5ic3A7MEE2QSZuYnNwOzYzOUEmbmJzcDtBNTYx Jm5ic3A7OTNDQSZuYnNwOyZuYnNwOzRENTUmbmJzcDszNURDJm5ic3A7QkE0RCZuYnNwO0QxNzAm bmJzcDs0RjY3PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJz cDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8 RElWPiZndDsmbmJzcDstLTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7UGguRC4sJm5ic3A7U2VuaW9y Jm5ic3A7TWVtYmVyPC9ESVY+DQo8RElWPiZndDsmbmJzcDtFbGVjdHJvbmljcyZuYnNwO2FuZCZu YnNwO1RlbGVjb21tdW5pY2F0aW9ucyZuYnNwO1Jlc2VhcmNoJm5ic3A7SW5zdGl0dXRlPC9ESVY+ DQo8RElWPiZndDsmbmJzcDtTdGFuZGFyZHMmbmJzcDtSZXNlYXJjaCZuYnNwO0NlbnRlcjwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7MTYxJm5ic3A7R2FqZW9uZy1Eb25nLCZuYnNwO1l1c2VvbmctR3Us Jm5ic3A7RGFlamVvbiwmbmJzcDszMDUtMzUwLCZuYnNwO0tPUkVBPC9ESVY+DQo8RElWPiZndDsm bmJzcDtUZWwmbmJzcDs6Jm5ic3A7KzgyLTQyLTg2MC0xMTMyLCZuYnNwOyZuYnNwOyZuYnNwO0Zh eCZuYnNwOzombmJzcDsrODItNDItODYxLTU0MDQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9ESVY+DQo8RElWPiZn dDsmbmJzcDtuZXRleHQmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7bmV0ZXh0QGlldGYub3JnPC9ESVY+DQo8RElWPiZndDsmbmJzcDtodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9E SVY+DQo8RElWPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvRElWPg0KPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvRElWPg0KPERJVj5uZXRleHQmbmJzcDttYWlsaW5nJm5ic3A7bGlz dDwvRElWPg0KPERJVj5uZXRleHRAaWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+X19fX19fX19fXyZuYnNwO0luZm9ybWF0aW9uJm5ic3A7 ZnJvbSZuYnNwO0VTRVQmbmJzcDtOT0QzMiZuYnNwO0FudGl2aXJ1cywmbmJzcDt2ZXJzaW9uJm5i c3A7b2YmbmJzcDt2aXJ1cyZuYnNwO3NpZ25hdHVyZSZuYnNwO2RhdGFiYXNlJm5ic3A7NTA5MyZu YnNwOygyMDEwMDUwNikmbmJzcDtfX19fX19fX19fPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5U aGUmbmJzcDttZXNzYWdlJm5ic3A7d2FzJm5ic3A7Y2hlY2tlZCZuYnNwO2J5Jm5ic3A7RVNFVCZu YnNwO05PRDMyJm5ic3A7QW50aXZpcnVzLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+aHR0cDov L3d3dy5lc2V0LmNvbTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+PC9GT05UPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon701757034568_=====-- From cjbc@it.uc3m.es Wed Jul 21 22:14:15 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 E6BA53A68AD for ; Wed, 21 Jul 2010 22:14:14 -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=[AWL=-0.000, 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 OeMnSDo6CqOz for ; Wed, 21 Jul 2010 22:14:09 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 849C23A68BF for ; Wed, 21 Jul 2010 22:14:08 -0700 (PDT) X-uc3m-safe: yes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Tran Minh Trung In-Reply-To: References: <1279641996.2828.314.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EZ1+8VoDIErGhVNrS5AQ" Organization: Universidad Carlos III de Madrid Date: Thu, 22 Jul 2010 07:15:16 +0200 Message-ID: <1279775716.9026.41.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17520.003 Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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: Thu, 22 Jul 2010 05:14:16 -0000 --=-EZ1+8VoDIErGhVNrS5AQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tran Minh, Some comments inline below... On Wed, 2010-07-21 at 19:17 +0900, Tran Minh Trung wrote: > Hi Bernardos, >=20 > Thank you for your reply. > Pls. see my replies inline. >=20 > 2010/7/21 Carlos Jes=C3=BAs Bernardos Cano : > > Hi Tran Minh, > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > >> Hi Bernardos and all, > >> > >> I have some comments and questions on the I-D > >> draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > Thanks a lot for the feedback. Please see some comments inline below. > > > >> > >> 1) I think the LMA can decide to move down-link flows only. The > >> up-link flows should be moved by the MN (eg. the MN is aware of the > >> attachment status via each IF and decide which IF is better for > >> sending up-link flows). The MAG should be aware of the movement of > > > > Our assumption is that the MN does implement the logical interface (as > > explained in draft-melia-netext-logical-interface-support-01). The LMA > > has of course the direct control of how downlink flows are routed, but > > an MN implementing the logical interface will just mirror that behavior > > with the uplink packets. Therefore, the LMA is the only entity > > controlling flow mobility both in downlink and uplink directions. > > >=20 >=20 > >> up-link flows and inform the LMA to update information. > > > > In the current draft, the MAG is informed about flow mobility operation= s > > by the LMA. There is signaling defined for that purpose. > > >=20 > Let's consider the case that the MN performs a handoff. I think it is > a special case of flow mobility when all flows are moved from an > interface to another. The MAG is aware of that event and informs the > LMA by using handoff indicator. So I think that we may consider the > same for the case that flows are moved by the MN. The MAG can be aware > of this movement by analyzing the packets received from the MN and > inform the LMA. I think the case of an MN handoff should not be tackled as a particular case of flow mobility. I'd try to explain why is so IMHO. There are two different cases: simultaneous attachment to different access technologies and sequential attachment. The first case is the one I think you are referring to, and for that I think we cannot assume the MN can easily control the movement of flows. With current charter, we are not allowed to define any signaling between the MN and the MAG, and therefore -- how Pierrick said in another e-mail -- it is quite hard to define an MN-centric solution for flow mobility. The second case is really what I understand as inter-tech handoff, and for that we probably need to tackle that in a different way than flow mobility. Using the logical interface, that case actually can be supported quite easily, as we just basically need to follow RFC5213, but benefiting from the fact that the address(es) that the MN is using remains the same (it can be seen as an intra-technology handover from the viewpoint of the MN). >=20 > In real network both operator (the LMA) and user (the MN) can set and > perform the rules to select the best interface (access technologies) > for serving a specific service flow. So we may better support for both > of them. See above. >=20 >=20 > >> > >> 2) It is necessary to discuss about the flow mobility triggers. The > >> signaling procedure between MAG/LMA depends on trigger. With different > >> kind of trigger we have to use different signaling procedure. > > > > The trigger is out of the scope of the solution draft. Any kind of > > trigger could be supported. For example a central policy entity can mak= e > > the decisions based on the overall state of the network and trigger the > > LMA. IMHO, which entity triggers the LMA can be left out of the scope, > > as it does not have an impact on the protocol (with current design). > > >=20 > I agree that it is not necessary to discuss detail about trigger in > the solution draft. > However, we have to mention about where do triggers come from?. Basing > on the source of trigger we have to use different signaling procedure. Why do we need to know where the triggers come from? If the LMA knows that it has to move flow X from MN's interface a to MN's interface b... does it really matter where this flow mobility decision come from (from the viewpoint of the solution design)? >=20 > For examples: >=20 > - The MN performs new attachment -> The MAG is aware of that event and > informs the LMA about new attachment and asks the LMA whether to move > some exiting flows to new attachment. In the drafted solution, the LMA is aware of this event. However that event is not the trigger itself for moving flows. The deciding entity (which could be the LMA itself, or even the MAG) should be aware of the interfaces through which the MN is attached to the PMIPv6 domain, so it can use that information when deciding to move flows. > - The MAG receives new flows from an interface of the MN -> The MAG > informs and asks LMA to check whether this flow is a new flow or just > a flow moved from another interface of the MN. Why do we need this? I don't understand. > - The LMA sees some changes in the network conditions or service > profile of the MN -> The LMA decides to move some flows to get better > services and inform MAGs. It can be the LMA or any other entity. The LMA is the entity signaling and managing the mobility of flows, but it is not necessarily the entity making the decisions about flow mobility. >=20 >=20 > >> > >> 3) The proposed solution requires new signaling messages and new > >> caching table. It makes more complicated for implementing and > >> combining with the existing standard than just extending the current > >> PBU/PBA messages as well as BCE and BULE caching table. > > >=20 > > Well, this was a design decision (there might be of course others). We > > preferred not to overload existing signaling. Regarding the data > > structures, they are just logical ones, they could also even be > > implemented by extending BCE and BUL. > > > >> > >> 4) What are the necessary requirements of the logical interface to > >> support flow mobility? > > > > This should be covered by > > draft-melia-netext-logical-interface-support-01. > > >=20 > I get some confuses about the logical interface described in the I-D > =E2=80=9Cdraft-melia-netext-logical-interface-support-=E2=80=9D and the l= ogical > interface used in the I-D =E2=80=9C01draft-bernardos-netext-pmipv6-flowmo= b-00=E2=80=9D >=20 > IMHO, when we use logical interface, the (set of) prefix(es) is > assigned to the logical interface only, not to physical interface. The > LMA, at layer 3, may see only the logical interface. I don't agree with that. The logical interface is an artifact at the MN side, to avoid requiring changes at the host stack. The network can -- and in my opinion must -- know about the different physical interfaces that the mobile has, so it can handle the movement of flows. >=20 > From this point, I think the 'Unique prefix per physical interface' > scenario is not necessary. This is not exactly the same that saying that the LMA sees at layer 3 only the logical interface, IMHO. We still need to discuss and agree about whether this "unique (set of) prefix(es) per physical interface" model is required or not. >=20 > However if we consider this scenario, then we can justify why we need > it as Julien suggested. And also we can discuss to make clear that why > we use the logical interface to hide the physical interfaces but we > still separate prefix(es) assignment basing on physical interfaces. See above. Thanks, Carlos >=20 > --- > Tran Minh Trung >=20 > >> > >> I hope that we can have more discussion on these issues before making > >> it as a WG document. > > > > Sure, useful discussion as this is very very welcome. Thanks! > > > > Kind Regards, > > > > Carlos > > > >> > >> Regards, > >> Tran Minh Trung > >> > > > > -- > > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > >=20 >=20 >=20 --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-EZ1+8VoDIErGhVNrS5AQ 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) iEYEABECAAYFAkxH0+QACgkQNdy6TdFwT2fVHACglczqzhKlzuCo7loSpE4aKXxn D2sAoMmVpduxQwRyFKAZ7QXkUTwnwYd9 =tRRM -----END PGP SIGNATURE----- --=-EZ1+8VoDIErGhVNrS5AQ-- From cjbc@it.uc3m.es Wed Jul 21 22:14: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 BEC853A69AA for ; Wed, 21 Jul 2010 22:14:35 -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 COD0EyIkl9Hl for ; Wed, 21 Jul 2010 22:14:31 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 1F3643A67AE for ; Wed, 21 Jul 2010 22:14:31 -0700 (PDT) X-uc3m-safe: yes From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: pierrick.seite@orange-ftgroup.com In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620105E348@ftrdmel0.rd.francetelecom.fr> References: <1279641996.2828.314.camel@acorde.it.uc3m.es> <843DA8228A1BA74CA31FB4E111A5C4620105E348@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AbaU6HeEGnaYPBQJYnHU" Organization: Universidad Carlos III de Madrid Date: Thu, 22 Jul 2010 07:15:21 +0200 Message-ID: <1279775721.9026.42.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17520.003 Cc: netext@ietf.org, trungtm@etri.re.kr Subject: Re: [netext] Comments & Questions on the I-D:draft-bernardos-netext-pmipv6-flowmob-00 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: Thu, 22 Jul 2010 05:14:36 -0000 --=-AbaU6HeEGnaYPBQJYnHU Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Dear Pierrick, I agree with your comments. Thanks, Carlos On Wed, 2010-07-21 at 15:51 +0200, pierrick.seite@orange-ftgroup.com wrote: > Hi Tran Minh and Carlos, >=20 > Please let me jump into this interesting discussion. >=20 > Tran Minh, You're right, theoretically both the LMA and the MN should > also be able to make decision about the path to use for a given IP > flow. In addition to handover triggers at the MN side that you are > suggesting, it may be not desirable that the LMA enforces its decision > to the MN despite of the user preferences.=20 >=20 > However, a MN driven decision in a network based mobility management > solution is quite tricky without MN signalling (and we definitely want > to avoid such a signalling, I don't want to reopen the debate :-)). > For example, you wrote: >=20 > "The MAG can be aware of this movement by analyzing the packets > received from the MN and inform the LMA." >=20 > I don't think such a simple solution could be sufficient, since there > are some cases where the MN does not use the uplink very often, e.g. > RTP streaming.=20 >=20 > So, trying to support the MN driven routing decision would bring > additional complexity and delay in the design of a solution. So, for > the sake of pragmatism, it makes sense to focus, in a first step, on a > routing decision driven by the LMA where the MN just updates its > uplink path according to where packets are received. >=20 > Then we need to clarify the requirement for handover triggers to be > processed at the MN side only. If so, we could think about extension > to the base solution as drafted in draft-bernardos. >=20 > Regards, > Pierrick >=20 > > -----Message d'origine----- > > De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la par= t > > de Tran Minh Trung > > Envoy=E9 : mercredi 21 juillet 2010 12:17 > > =C0 : cjbc@it.uc3m.es > > Cc : netext@ietf.org > > Objet : Re: [netext] Comments & Questions on the I-D:draft-bernardos- > > netext-pmipv6-flowmob-00 > >=20 > > Hi Bernardos, > >=20 > > Thank you for your reply. > > Pls. see my replies inline. > >=20 > > 2010/7/21 Carlos Jes=FAs Bernardos Cano : > > > Hi Tran Minh, > > > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > > >> Hi Bernardos and all, > > >> > > >> I have some comments and questions on the I-D > > >> draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > > > Thanks a lot for the feedback. Please see some comments inline below. > > > > > >> > > >> 1) I think the LMA can decide to move down-link flows only. The > > >> up-link flows should be moved by the MN (eg. the MN is aware of the > > >> attachment status via each IF and decide which IF is better for > > >> sending up-link flows). The MAG should be aware of the movement of > > > > > > Our assumption is that the MN does implement the logical interface (a= s > > > explained in draft-melia-netext-logical-interface-support-01). The LM= A > > > has of course the direct control of how downlink flows are routed, bu= t > > > an MN implementing the logical interface will just mirror that behavi= or > > > with the uplink packets. Therefore, the LMA is the only entity > > > controlling flow mobility both in downlink and uplink directions. > > > > >=20 > >=20 > > >> up-link flows and inform the LMA to update information. > > > > > > In the current draft, the MAG is informed about flow mobility operati= ons > > > by the LMA. There is signaling defined for that purpose. > > > > >=20 > > Let's consider the case that the MN performs a handoff. I think it is > > a special case of flow mobility when all flows are moved from an > > interface to another. The MAG is aware of that event and informs the > > LMA by using handoff indicator. So I think that we may consider the > > same for the case that flows are moved by the MN. The MAG can be aware > > of this movement by analyzing the packets received from the MN and > > inform the LMA. > >=20 > > In real network both operator (the LMA) and user (the MN) can set and > > perform the rules to select the best interface (access technologies) > > for serving a specific service flow. So we may better support for both > > of them. > >=20 > >=20 > > >> > > >> 2) It is necessary to discuss about the flow mobility triggers. The > > >> signaling procedure between MAG/LMA depends on trigger. With differe= nt > > >> kind of trigger we have to use different signaling procedure. > > > > > > The trigger is out of the scope of the solution draft. Any kind of > > > trigger could be supported. For example a central policy entity can m= ake > > > the decisions based on the overall state of the network and trigger t= he > > > LMA. IMHO, which entity triggers the LMA can be left out of the scope= , > > > as it does not have an impact on the protocol (with current design). > > > > >=20 > > I agree that it is not necessary to discuss detail about trigger in > > the solution draft. > > However, we have to mention about where do triggers come from?. Basing > > on the source of trigger we have to use different signaling procedure. > >=20 > > For examples: > >=20 > > - The MN performs new attachment -> The MAG is aware of that event and > > informs the LMA about new attachment and asks the LMA whether to move > > some exiting flows to new attachment. > > - The MAG receives new flows from an interface of the MN -> The MAG > > informs and asks LMA to check whether this flow is a new flow or just > > a flow moved from another interface of the MN. > > - The LMA sees some changes in the network conditions or service > > profile of the MN -> The LMA decides to move some flows to get better > > services and inform MAGs. > >=20 > >=20 > > >> > > >> 3) The proposed solution requires new signaling messages and new > > >> caching table. It makes more complicated for implementing and > > >> combining with the existing standard than just extending the current > > >> PBU/PBA messages as well as BCE and BULE caching table. > > > > >=20 > > > Well, this was a design decision (there might be of course others). W= e > > > preferred not to overload existing signaling. Regarding the data > > > structures, they are just logical ones, they could also even be > > > implemented by extending BCE and BUL. > > > > > >> > > >> 4) What are the necessary requirements of the logical interface to > > >> support flow mobility? > > > > > > This should be covered by > > > draft-melia-netext-logical-interface-support-01. > > > > >=20 > > I get some confuses about the logical interface described in the I-D > > "draft-melia-netext-logical-interface-support-" and the logical > > interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob-00" > >=20 > > IMHO, when we use logical interface, the (set of) prefix(es) is > > assigned to the logical interface only, not to physical interface. The > > LMA, at layer 3, may see only the logical interface. > >=20 > > From this point, I think the 'Unique prefix per physical interface' > > scenario is not necessary. > >=20 > > However if we consider this scenario, then we can justify why we need > > it as Julien suggested. And also we can discuss to make clear that why > > we use the logical interface to hide the physical interfaces but we > > still separate prefix(es) assignment basing on physical interfaces. > >=20 > > --- > > Tran Minh Trung > >=20 > > >> > > >> I hope that we can have more discussion on these issues before makin= g > > >> it as a WG document. > > > > > > Sure, useful discussion as this is very very welcome. Thanks! > > > > > > Kind Regards, > > > > > > Carlos > > > > > >> > > >> Regards, > > >> Tran Minh Trung > > >> > > > > > > -- > > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > > > >=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, Fax : +82-42-861-5404 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-AbaU6HeEGnaYPBQJYnHU 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) iEYEABECAAYFAkxH0+kACgkQNdy6TdFwT2ffvQCg0Pvueg3MtVUibnFn4ROFihJG mD0An3vJ74w93YVxzRIWcrEqj1QLKe1F =kWr1 -----END PGP SIGNATURE----- --=-AbaU6HeEGnaYPBQJYnHU-- From Telemaco.Melia@alcatel-lucent.com Thu Jul 22 01:55:41 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 5256D3A6A01 for ; Thu, 22 Jul 2010 01:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.742 X-Spam-Level: X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, 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 DjDcWXdSUMoi for ; Thu, 22 Jul 2010 01:55:39 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 2385A3A69DD for ; Thu, 22 Jul 2010 01:55:38 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6M8thg2009103; Thu, 22 Jul 2010 10:55:46 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 10:55:43 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Jul 2010 10:55:42 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C0466A851@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments & Questions ontheI-D:draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: Acsove08S5wuIPdmSMeR8QZ9x9FmygAHXuhwAA8L/cAAGOZ8oA== References: <1279641996.2828.314.camel@acorde.it.uc3m.es><843DA8228A1BA74CA31FB4E111A5C4620105E348@ftrdmel0.rd.francetelecom.fr> From: "MELIA TELEMACO" To: "Zuniga, Juan Carlos" , , X-OriginalArrivalTime: 22 Jul 2010 08:55:43.0464 (UTC) FILETIME=[AADEDE80:01CB297B] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions ontheI-D:draft-bernardos-netext-pmipv6-flowmob-00 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: Thu, 22 Jul 2010 08:55:41 -0000 Right, and this is currently captured in the logical interface ID = (section 5.3). This should clear up doubts. telemaco -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Zuniga, Juan Carlos Envoy=E9=A0: mercredi 21 juillet 2010 23:06 =C0=A0: pierrick.seite@orange-ftgroup.com; trungtm@etri.re.kr Cc=A0: netext@ietf.org Objet=A0: Re: [netext] Comments & Questions = ontheI-D:draft-bernardos-netext-pmipv6-flowmob-00 Pierrick, Tran Minh, As Carlos mentioned in his first response to Tran Minh, the necessary = requirements of the logical interface to support flow mobility should be = captured in the applicability document. The current wording in = "draft-melia-netext-logical-interface-support-01" is a little messy due = to the last minute merger of two other i-ds, but this is the place where = the overall system should be described (i.e. beyond PMIP changes). Regarding the MN driven decision, we discussed in the past that a = trigger could be sent to the LMA via L2.5 signalling. This would not be = in scope for the solution document = (draft-bernardos-netext-pmipv6-flowmob-00) which, as Pierrick points = out, only considers network based solutions. However, it should be = documented in the applicability document as this could be one more input = at the LMA to trigger the flow mobility (from the network). By making = this distinction, we allow both MN and LMA to start the flow mobility, = and still limit the mobility management solution to be network based. Regards, Juan-Carlos > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of pierrick.seite@orange-ftgroup.com > Sent: Wednesday, July 21, 2010 9:52 AM > To: trungtm@etri.re.kr; cjbc@it.uc3m.es > Cc: netext@ietf.org > Subject: Re: [netext] Comments & Questions on theI-D:draft-bernardos- > netext-pmipv6-flowmob-00 >=20 > Hi Tran Minh and Carlos, >=20 > Please let me jump into this interesting discussion. >=20 > Tran Minh, You're right, theoretically both the LMA and the MN should > also be able to make decision about the path to use for a given IP > flow. In addition to handover triggers at the MN side that you are > suggesting, it may be not desirable that the LMA enforces its decision > to the MN despite of the user preferences. >=20 > However, a MN driven decision in a network based mobility management > solution is quite tricky without MN signalling (and we definitely want > to avoid such a signalling, I don't want to reopen the debate :-)). = For > example, you wrote: >=20 > "The MAG can be aware of this movement by analyzing the packets > received from the MN and inform the LMA." >=20 > I don't think such a simple solution could be sufficient, since there > are some cases where the MN does not use the uplink very often, e.g. > RTP streaming. >=20 > So, trying to support the MN driven routing decision would bring > additional complexity and delay in the design of a solution. So, for > the sake of pragmatism, it makes sense to focus, in a first step, on a > routing decision driven by the LMA where the MN just updates its = uplink > path according to where packets are received. >=20 > Then we need to clarify the requirement for handover triggers to be > processed at the MN side only. If so, we could think about extension = to > the base solution as drafted in draft-bernardos. >=20 > Regards, > Pierrick >=20 > > -----Message d'origine----- > > De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De = la > part > > de Tran Minh Trung > > Envoy=E9=A0: mercredi 21 juillet 2010 12:17 > > =C0=A0: cjbc@it.uc3m.es > > Cc=A0: netext@ietf.org > > Objet=A0: Re: [netext] Comments & Questions on the = I-D:draft-bernardos- > > netext-pmipv6-flowmob-00 > > > > Hi Bernardos, > > > > Thank you for your reply. > > Pls. see my replies inline. > > > > 2010/7/21 Carlos Jes=FAs Bernardos Cano : > > > Hi Tran Minh, > > > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > > >> Hi Bernardos and all, > > >> > > >> I have some comments and questions on the I-D > > >> draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > > > Thanks a lot for the feedback. Please see some comments inline > below. > > > > > >> > > >> 1) I think the LMA can decide to move down-link flows only. The > > >> up-link flows should be moved by the MN (eg. the MN is aware of > the > > >> attachment status via each IF and decide which IF is better for > > >> sending up-link flows). The MAG should be aware of the movement = of > > > > > > Our assumption is that the MN does implement the logical interface > (as > > > explained in draft-melia-netext-logical-interface-support-01). The > LMA > > > has of course the direct control of how downlink flows are routed, > but > > > an MN implementing the logical interface will just mirror that > behavior > > > with the uplink packets. Therefore, the LMA is the only entity > > > controlling flow mobility both in downlink and uplink directions. > > > > > > > > > >> up-link flows and inform the LMA to update information. > > > > > > In the current draft, the MAG is informed about flow mobility > operations > > > by the LMA. There is signaling defined for that purpose. > > > > > > > Let's consider the case that the MN performs a handoff. I think it = is > > a special case of flow mobility when all flows are moved from an > > interface to another. The MAG is aware of that event and informs the > > LMA by using handoff indicator. So I think that we may consider the > > same for the case that flows are moved by the MN. The MAG can be > aware > > of this movement by analyzing the packets received from the MN and > > inform the LMA. > > > > In real network both operator (the LMA) and user (the MN) can set = and > > perform the rules to select the best interface (access technologies) > > for serving a specific service flow. So we may better support for > both > > of them. > > > > > > >> > > >> 2) It is necessary to discuss about the flow mobility triggers. > The > > >> signaling procedure between MAG/LMA depends on trigger. With > different > > >> kind of trigger we have to use different signaling procedure. > > > > > > The trigger is out of the scope of the solution draft. Any kind of > > > trigger could be supported. For example a central policy entity = can > make > > > the decisions based on the overall state of the network and = trigger > the > > > LMA. IMHO, which entity triggers the LMA can be left out of the > scope, > > > as it does not have an impact on the protocol (with current > design). > > > > > > > I agree that it is not necessary to discuss detail about trigger in > > the solution draft. > > However, we have to mention about where do triggers come from?. > Basing > > on the source of trigger we have to use different signaling > procedure. > > > > For examples: > > > > - The MN performs new attachment -> The MAG is aware of that event > and > > informs the LMA about new attachment and asks the LMA whether to = move > > some exiting flows to new attachment. > > - The MAG receives new flows from an interface of the MN -> The MAG > > informs and asks LMA to check whether this flow is a new flow or = just > > a flow moved from another interface of the MN. > > - The LMA sees some changes in the network conditions or service > > profile of the MN -> The LMA decides to move some flows to get = better > > services and inform MAGs. > > > > > > >> > > >> 3) The proposed solution requires new signaling messages and new > > >> caching table. It makes more complicated for implementing and > > >> combining with the existing standard than just extending the > current > > >> PBU/PBA messages as well as BCE and BULE caching table. > > > > > > > > Well, this was a design decision (there might be of course = others). > We > > > preferred not to overload existing signaling. Regarding the data > > > structures, they are just logical ones, they could also even be > > > implemented by extending BCE and BUL. > > > > > >> > > >> 4) What are the necessary requirements of the logical interface = to > > >> support flow mobility? > > > > > > This should be covered by > > > draft-melia-netext-logical-interface-support-01. > > > > > > > I get some confuses about the logical interface described in the I-D > > "draft-melia-netext-logical-interface-support-" and the logical > > interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob- > 00" > > > > IMHO, when we use logical interface, the (set of) prefix(es) is > > assigned to the logical interface only, not to physical interface. > The > > LMA, at layer 3, may see only the logical interface. > > > > From this point, I think the 'Unique prefix per physical interface' > > scenario is not necessary. > > > > However if we consider this scenario, then we can justify why we = need > > it as Julien suggested. And also we can discuss to make clear that > why > > we use the logical interface to hide the physical interfaces but we > > still separate prefix(es) assignment basing on physical interfaces. > > > > --- > > Tran Minh Trung > > > > >> > > >> I hope that we can have more discussion on these issues before > making > > >> it as a WG document. > > > > > > Sure, useful discussion as this is very very welcome. Thanks! > > > > > > Kind Regards, > > > > > > Carlos > > > > > >> > > >> Regards, > > >> Tran Minh Trung > > >> > > > > > > -- > > > Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net > > > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 > > > > > > > > > > > -- > > 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 _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From Telemaco.Melia@alcatel-lucent.com Thu Jul 22 02:06: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 2E0393A6A17 for ; Thu, 22 Jul 2010 02:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.195 X-Spam-Level: X-Spam-Status: No, score=-5.195 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, 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 89mmRVm063BP for ; Thu, 22 Jul 2010 02:06:43 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id C1A433A69F8 for ; Thu, 22 Jul 2010 02:06:42 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6M96qRk020888; Thu, 22 Jul 2010 11:06:52 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 11:06:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Jul 2010 11:06:51 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C0466A852@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <1279775716.9026.41.camel@acorde.it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcspXMo26hdyqxngQnW/AB9KpNxUMQAHylLg References: <1279641996.2828.314.camel@acorde.it.uc3m.es> <1279775716.9026.41.camel@acorde.it.uc3m.es> From: "MELIA TELEMACO" To: , "Tran Minh Trung" X-OriginalArrivalTime: 22 Jul 2010 09:06:52.0794 (UTC) FILETIME=[39D285A0:01CB297D] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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: Thu, 22 Jul 2010 09:06:45 -0000 Hi all, The ID Carlos posted proposes a network based signaling to achieve flow = mobility. As Juan Carlos stated earlier the LMA takes flow mobility = decisions based on external triggers and while these triggers are out of = scope for the solution design document people might feel free to adopt = any of them. Although achieving the same goal, the proposed method is = semantically different from the one specified for DSMIP. We should not = mix things. telemaco -----Message d'origine----- De=A0: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Carlos Jes=FAs Bernardos Cano Envoy=E9=A0: jeudi 22 juillet 2010 07:15 =C0=A0: Tran Minh Trung Cc=A0: netext@ietf.org Objet=A0: Re: [netext] Comments & Questions on the I-D: = draft-bernardos-netext-pmipv6-flowmob-00 Hi Tran Minh, Some comments inline below... On Wed, 2010-07-21 at 19:17 +0900, Tran Minh Trung wrote: > Hi Bernardos, >=20 > Thank you for your reply. > Pls. see my replies inline. >=20 > 2010/7/21 Carlos Jes=FAs Bernardos Cano : > > Hi Tran Minh, > > > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote: > >> Hi Bernardos and all, > >> > >> I have some comments and questions on the I-D > >> draft-bernardos-netext-pmipv6-flowmob-00 as follows: > > > > Thanks a lot for the feedback. Please see some comments inline = below. > > > >> > >> 1) I think the LMA can decide to move down-link flows only. The > >> up-link flows should be moved by the MN (eg. the MN is aware of the > >> attachment status via each IF and decide which IF is better for > >> sending up-link flows). The MAG should be aware of the movement of > > > > Our assumption is that the MN does implement the logical interface = (as > > explained in draft-melia-netext-logical-interface-support-01). The = LMA > > has of course the direct control of how downlink flows are routed, = but > > an MN implementing the logical interface will just mirror that = behavior > > with the uplink packets. Therefore, the LMA is the only entity > > controlling flow mobility both in downlink and uplink directions. > > >=20 >=20 > >> up-link flows and inform the LMA to update information. > > > > In the current draft, the MAG is informed about flow mobility = operations > > by the LMA. There is signaling defined for that purpose. > > >=20 > Let's consider the case that the MN performs a handoff. I think it is > a special case of flow mobility when all flows are moved from an > interface to another. The MAG is aware of that event and informs the > LMA by using handoff indicator. So I think that we may consider the > same for the case that flows are moved by the MN. The MAG can be aware > of this movement by analyzing the packets received from the MN and > inform the LMA. I think the case of an MN handoff should not be tackled as a particular case of flow mobility. I'd try to explain why is so IMHO. There are two different cases: simultaneous attachment to different access technologies and sequential attachment. The first case is the one I think you are referring to, and for that I think we cannot assume the MN can easily control the movement of flows. With current charter, we are not allowed to define any signaling between the MN and the MAG, and therefore -- how Pierrick said in another e-mail -- it is quite hard to define an MN-centric solution for flow mobility. The second case is really what I understand as inter-tech handoff, and for that we probably need to tackle that in a different way than flow mobility. Using the logical interface, that case actually can be supported quite easily, as we just basically need to follow RFC5213, but benefiting from the fact that the address(es) that the MN is using remains the same (it can be seen as an intra-technology handover from the viewpoint of the MN). >=20 > In real network both operator (the LMA) and user (the MN) can set and > perform the rules to select the best interface (access technologies) > for serving a specific service flow. So we may better support for both > of them. See above. >=20 >=20 > >> > >> 2) It is necessary to discuss about the flow mobility triggers. The > >> signaling procedure between MAG/LMA depends on trigger. With = different > >> kind of trigger we have to use different signaling procedure. > > > > The trigger is out of the scope of the solution draft. Any kind of > > trigger could be supported. For example a central policy entity can = make > > the decisions based on the overall state of the network and trigger = the > > LMA. IMHO, which entity triggers the LMA can be left out of the = scope, > > as it does not have an impact on the protocol (with current design). > > >=20 > I agree that it is not necessary to discuss detail about trigger in > the solution draft. > However, we have to mention about where do triggers come from?. Basing > on the source of trigger we have to use different signaling procedure. Why do we need to know where the triggers come from? If the LMA knows that it has to move flow X from MN's interface a to MN's interface b... does it really matter where this flow mobility decision come from (from the viewpoint of the solution design)? >=20 > For examples: >=20 > - The MN performs new attachment -> The MAG is aware of that event and > informs the LMA about new attachment and asks the LMA whether to move > some exiting flows to new attachment. In the drafted solution, the LMA is aware of this event. However that event is not the trigger itself for moving flows. The deciding entity (which could be the LMA itself, or even the MAG) should be aware of the interfaces through which the MN is attached to the PMIPv6 domain, so it can use that information when deciding to move flows. > - The MAG receives new flows from an interface of the MN -> The MAG > informs and asks LMA to check whether this flow is a new flow or just > a flow moved from another interface of the MN. Why do we need this? I don't understand. > - The LMA sees some changes in the network conditions or service > profile of the MN -> The LMA decides to move some flows to get better > services and inform MAGs. It can be the LMA or any other entity. The LMA is the entity signaling and managing the mobility of flows, but it is not necessarily the entity making the decisions about flow mobility. >=20 >=20 > >> > >> 3) The proposed solution requires new signaling messages and new > >> caching table. It makes more complicated for implementing and > >> combining with the existing standard than just extending the = current > >> PBU/PBA messages as well as BCE and BULE caching table. > > >=20 > > Well, this was a design decision (there might be of course others). = We > > preferred not to overload existing signaling. Regarding the data > > structures, they are just logical ones, they could also even be > > implemented by extending BCE and BUL. > > > >> > >> 4) What are the necessary requirements of the logical interface to > >> support flow mobility? > > > > This should be covered by > > draft-melia-netext-logical-interface-support-01. > > >=20 > I get some confuses about the logical interface described in the I-D > "draft-melia-netext-logical-interface-support-" and the logical > interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob-00" >=20 > IMHO, when we use logical interface, the (set of) prefix(es) is > assigned to the logical interface only, not to physical interface. The > LMA, at layer 3, may see only the logical interface. I don't agree with that. The logical interface is an artifact at the MN side, to avoid requiring changes at the host stack. The network can -- and in my opinion must -- know about the different physical interfaces that the mobile has, so it can handle the movement of flows. >=20 > From this point, I think the 'Unique prefix per physical interface' > scenario is not necessary. This is not exactly the same that saying that the LMA sees at layer 3 only the logical interface, IMHO. We still need to discuss and agree about whether this "unique (set of) prefix(es) per physical interface" model is required or not. >=20 > However if we consider this scenario, then we can justify why we need > it as Julien suggested. And also we can discuss to make clear that why > we use the logical interface to hide the physical interfaces but we > still separate prefix(es) assignment basing on physical interfaces. See above. Thanks, Carlos >=20 > --- > Tran Minh Trung >=20 > >> > >> I hope that we can have more discussion on these issues before = making > >> it as a WG document. > > > > Sure, useful discussion as this is very very welcome. Thanks! > > > > Kind Regards, > > > > Carlos > > > >> > >> Regards, > >> Tran Minh Trung > >> > > > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > >=20 >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From rkoodli@cisco.com Thu Jul 22 11:05:16 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 4F76F3A684A for ; Thu, 22 Jul 2010 11:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, 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 cdxkWwruBa4n for ; Thu, 22 Jul 2010 11:05:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B74FE3A6883 for ; Thu, 22 Jul 2010 11:05:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFALUkSEytJV2Y/2dsb2JhbACfHVVxpzybG4U2BIQAhFmCOQ Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 18:05:31 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o6MI5VuA008662; Thu, 22 Jul 2010 18:05:31 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jul 2010 14:03:58 -0400 Received: from 10.21.66.86 ([10.21.66.86]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jul 2010 18:03:59 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 22 Jul 2010 11:12:41 -0700 From: Rajeev Koodli To: , Tran Minh Trung Message-ID: Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcspyXlG1mxHYNBgIk6TQ10x+F5wHA== In-Reply-To: <1279775716.9026.41.camel@acorde.it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2010 18:03:58.0816 (UTC) FILETIME=[42073E00:01CB29C8] Cc: netext@ietf.org Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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: Thu, 22 Jul 2010 18:05:16 -0000 On 7/21/10 10:15 PM, "Carlos Jes=FAs Bernardos Cano" wrote: > Hi Tran Minh, >> Let's consider the case that the MN performs a handoff. I think it is >> a special case of flow mobility when all flows are moved from an >> interface to another. The MAG is aware of that event and informs the >> LMA by using handoff indicator. So I think that we may consider the >> same for the case that flows are moved by the MN. The MAG can be aware >> of this movement by analyzing the packets received from the MN and >> inform the LMA. >=20 > I think the case of an MN handoff should not be tackled as a particular > case of flow mobility. I'd try to explain why is so IMHO. Yes, flow mobility is for simultaneous access. We have discussed this durin= g multiple meetings prior to re-chartering. Handover typically involves relinquishing an interface for another. -Rajeev From rkoodli@cisco.com Thu Jul 22 11:07: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 4608E3A6832 for ; Thu, 22 Jul 2010 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.18 X-Spam-Level: X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, 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 XfP6aVeUe1Rb for ; Thu, 22 Jul 2010 11:07:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 292873A67C3 for ; Thu, 22 Jul 2010 11:07:52 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN4lSEytJV2Z/2dsb2JhbACfcnGnM5sbhTYEhACEWYI5 Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 18:08:07 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o6MI86IK031179; Thu, 22 Jul 2010 18:08:06 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jul 2010 14:06:34 -0400 Received: from 10.21.66.86 ([10.21.66.86]) by exchtewks3.starentnetworks.com ([10.2.4.31]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jul 2010 18:06:33 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 22 Jul 2010 11:15:15 -0700 From: Rajeev Koodli To: "Laganier, Julien" , "cjbc@it.uc3m.es" Message-ID: Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcsoWwKL4E1k4RC610C22R8Kh2cqwQAAMJUwAFuEDKk= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Jul 2010 18:06:34.0251 (UTC) FILETIME=[9EACBDB0:01CB29C8] Cc: "netext@ietf.org" , Tran Minh Trung Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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: Thu, 22 Jul 2010 18:07:53 -0000 Yes, I think it would be necessary to maintain/manage state for each session. If there is a way to do this without signaling, please elaborate. -Rajeev On 7/20/10 3:55 PM, "Laganier, Julien" wrote: > Rajeev Koodli wrote: >>=20 >> On 7/20/10 3:02 PM, "Carlos Jes=FAs Bernardos Cano" >> wrote: >>=20 >>> Well, the draft does not detail any requirement, but this does not >>> necessarily mean there is not (I'm not saying either way). I think >>> this deserves a second thought, because when I looked at existing >>> solutions, there were some that assumed that model, so I'd say that >>> we need to at least understand why. Maybe people can comment on this >>> particular issue... I'd fine to removing this if there is no real need >>> for supporting the two models. >>=20 >> I think both the models need to be captured. >=20 > Engineering is about designing solutions to problems. Thus seems prematur= e to > capture more than one model without having captured requirements that jus= tify > the need for those. >=20 >> Having a separate /64 can >> be a subscription issue - the provider may want to maintain separate >> sessions for the multi-access. And, a MAG needs to have the session stat= e >> as well for such purposes as QoS, policy and accounting. So, signaling i= s >> necessary regardless of whether the same /64 is used or not. >=20 > If we can agree that there's a requirement that separate session be maint= ained > for each of the accesses, then we can discuss how to best fulfill this > requirements, including, but not necessarily relying on, signaling. >=20 > I do not know yet how that would relate to the use of one (set of) prefix= (es) > per physical interface. >=20 > --julien=20 From trungtm2909@gmail.com Fri Jul 23 03:12:50 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 65F4D3A6A77 for ; Fri, 23 Jul 2010 03:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 CnHTickw1nzF for ; Fri, 23 Jul 2010 03:12:49 -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 5C76C3A6853 for ; Fri, 23 Jul 2010 03:12:49 -0700 (PDT) Received: by iwn38 with SMTP id 38so31501iwn.31 for ; Fri, 23 Jul 2010 03:13:07 -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; bh=gQflSDalaOsaCJH81x/GmcJd5g4PaJNtYcxefD5vhVo=; b=mSvPbC+/jbuCdBZtkOhzV0aiL9f6vyO2HR5rxurskiyEUccaB0jNwozanGFxY6hL1T JVyAuGRZsTZ37Vc7Gs2KSMw5xipvako5BMSBb6nQUFqggnVvwnEo1VSq/A98yfw6ctga +VI11MElW3LVlaFx27pKOkvXxruP5Z+n2RfIc= 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; b=WLnn42RPMh3Cn/nc+rZRbpzqRd8C7KLNZ0BakV1GVIetpZZenVVI7lopBGTeYq4veR d6S/d5DqiOHypuOpfswZeplmgeW6x1QCatos9WVxJ3wKrfzw+tKFiOpFhxXxRVtfeU/h ra70ygacUcunz49Y4hw10/3UYX4Y3SUfINXYo= MIME-Version: 1.0 Received: by 10.231.14.136 with SMTP id g8mr3354486iba.146.1279879986952; Fri, 23 Jul 2010 03:13:06 -0700 (PDT) Sender: trungtm2909@gmail.com Received: by 10.231.185.32 with HTTP; Fri, 23 Jul 2010 03:13:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Jul 2010 19:13:06 +0900 X-Google-Sender-Auth: 88SafruwWE74HLELkFUxEKp4nEY Message-ID: From: Tran Minh Trung To: Rajeev Koodli Content-Type: text/plain; charset=ISO-8859-1 Cc: "netext@ietf.org" , "Laganier, Julien" Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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, 23 Jul 2010 10:12:50 -0000 Hi Carlos, Pierrick, Rajeev and all Thank you very much for your comments. I agree with Pierrick and Carlos that in the first step we just focus on a routing decision driven by the LMA as drafted in draft-bernardos-netext-pmipv6-flowmob-00. I do hope that in the next step we can clarify the requirement for handover triggers to be processed at the MN side only. About the unique prefix(es) per physical interface model for separating session issue, I think we still need more discussion. See all of you at IETF78 meeting next week. Regards, Tran Minh Trung From xiayangsong@huawei.com Fri Jul 23 15:26:32 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 7260C3A67D4 for ; Fri, 23 Jul 2010 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 RMFvN-Vgmq6a for ; Fri, 23 Jul 2010 15:26:31 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3D4943A67FB for ; Fri, 23 Jul 2010 15:26:31 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6100GUP7OFSX@szxga01-in.huawei.com> for netext@ietf.org; Sat, 24 Jul 2010 06:26:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L61007TU7OFWB@szxga01-in.huawei.com> for netext@ietf.org; Sat, 24 Jul 2010 06:26:39 +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 <0L6100MI27OCH6@szxml06-in.huawei.com> for netext@ietf.org; Sat, 24 Jul 2010 06:26:39 +0800 (CST) Date: Fri, 23 Jul 2010 15:26:34 -0700 From: Frank Xia In-reply-to: To: 'Rajeev Koodli' , netext@ietf.org Message-id: <000001cb2ab6$1d43ace0$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: multipart/alternative; boundary="Boundary_(ID_WxYaNWbVwzNgaHWt5iMfcw)" Thread-index: AcsdUqVrO8fBUqLvpkmK+HWtlsKSHgKF1LRBANMCaSA= References: Subject: Re: [netext] WG LC on draft-ietf-netext-redirect-03 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, 23 Jul 2010 22:26:32 -0000 This is a multi-part message in MIME format. --Boundary_(ID_WxYaNWbVwzNgaHWt5iMfcw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I agree to advance this document. BR Frank _____ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli Sent: Monday, July 19, 2010 10:44 AM To: netext@ietf.org Subject: Re: [netext] WG LC on draft-ietf-netext-redirect-03 Folks, Reminder about the LC. We need input, please provide. Thanks, -Rajeev On 7/6/10 2:31 PM, "Rajeev Koodli" wrote: Hello folks, We would like to progress this draft. This is a three week LC on the draft. Please provide your input by July 27. Hopefully, we can discuss the input during the meeting on the 28th. Look forward to your reviews. ID URL: http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt Thanks, -Rajeev (for chairs) _____ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --Boundary_(ID_WxYaNWbVwzNgaHWt5iMfcw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable Re: [netext] WG LC on draft-ietf-netext-redirect-03

I agree to = advance this document.

 <= /span>

BR

Frank

 <= /span>

From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Rajeev Koodli
Sent: Monday, July 19, = 2010 10:44 AM
To: netext@ietf.org
Subject: Re: [netext] WG = LC on draft-ietf-netext-redirect-03

 


Folks,

Reminder about the LC. We need input, please provide.

Thanks,

-Rajeev



On 7/6/10 2:31 PM, "Rajeev Koodli" <rkoodli@cisco.com> wrote:


Hello folks,

We would like to progress this draft. This is a three week LC on the = draft.
Please provide your input by July 27. Hopefully, we can discuss the = input during the meeting on the 28th.

Look forward to your reviews.

ID URL: http://= www.ietf.org/id/draft-ietf-netext-redirect-03.txt

Thanks,

-Rajeev (for chairs)


 

_________________________= ______________________
netext mailing list
netext@ietf.org
https://www.ietf.or= g/mailman/listinfo/netext

--Boundary_(ID_WxYaNWbVwzNgaHWt5iMfcw)-- From julienl@qualcomm.com Sat Jul 24 05:52: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 A8C403A69D8 for ; Sat, 24 Jul 2010 05:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 xkRjAlg2CYkd for ; Sat, 24 Jul 2010 05:52:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 826163A68C2 for ; Sat, 24 Jul 2010 05:52:03 -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=1279975940; x=1311511940; 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:=20Rajeev=20Koodli=20,=20"cjbc@it. uc3m.es"=20|CC:=20"netext@ietf.org"=20,=20Tran=20Minh=20Trung=20|Date:=20Sat,=2024=20Jul=202010=2005:50:11=20-0700 |Subject:=20RE:=20[netext]=20Comments=20&=20Questions=20o n=20the=20I-D:=0D=0A=20draft-bernardos-netext-pmipv6-flow mob-00|Thread-Topic:=20[netext]=20Comments=20&=20Question s=20on=20the=20I-D:=0D=0A=20draft-bernardos-netext-pmipv6 -flowmob-00|Thread-Index:=20AcsoWwKL4E1k4RC610C22R8Kh2cqw QAAMJUwAFuEDKkAWRNcQA=3D=3D|Message-ID:=20 |References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-U S|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=21kce93ZITbjRvgnNoRYSM5aedbU8JyhPVm5Qg6FkCc=; b=nq/Uedl4G+vaNoK0p+QNtDfvIrK96LxudLh5iBVLwbmqC7nutEcFq+PV Z9+tiqFJmJqXfTc/4d7+rpIRbUiCYu+yS5c1svbip4BfYkRzp7E0hKxhc XYBPVefm+QOZzQJgsjilOHAJKDa7inJWnxlr0DnRunFSchhuqSy93jpBu o=; X-IronPort-AV: E=McAfee;i="5400,1158,6052"; a="48423005" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 24 Jul 2010 05:50:13 -0700 X-IronPort-AV: E=Sophos;i="4.55,250,1278313200"; d="scan'208";a="46575006" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 24 Jul 2010 05:50:13 -0700 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 24 Jul 2010 05:50:15 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.0.694.0; Sat, 24 Jul 2010 05:50:15 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Sat, 24 Jul 2010 05:50:15 -0700 From: "Laganier, Julien" To: Rajeev Koodli , "cjbc@it.uc3m.es" Date: Sat, 24 Jul 2010 05:50:11 -0700 Thread-Topic: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 Thread-Index: AcsoWwKL4E1k4RC610C22R8Kh2cqwQAAMJUwAFuEDKkAWRNcQA== 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 Cc: "netext@ietf.org" , Tran Minh Trung Subject: Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00 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: Sat, 24 Jul 2010 12:52:04 -0000 For example, the LMA knows that there are different MAGs so it can distingu= ish packets coming from one MAG from the others. --julien Rajeev Koodli wrote: >=20 >=20 > Yes, I think it would be necessary to maintain/manage state for each > session. > If there is a way to do this without signaling, please elaborate. >=20 > -Rajeev >=20 >=20 > On 7/20/10 3:55 PM, "Laganier, Julien" wrote: >=20 > > Rajeev Koodli wrote: > >> > >> On 7/20/10 3:02 PM, "Carlos Jes=FAs Bernardos Cano" > >> wrote: > >> > >>> Well, the draft does not detail any requirement, but this does not > >>> necessarily mean there is not (I'm not saying either way). I think > >>> this deserves a second thought, because when I looked at existing > >>> solutions, there were some that assumed that model, so I'd say that > >>> we need to at least understand why. Maybe people can comment on > this > >>> particular issue... I'd fine to removing this if there is no real > need > >>> for supporting the two models. > >> > >> I think both the models need to be captured. > > > > Engineering is about designing solutions to problems. Thus seems > premature to > > capture more than one model without having captured requirements that > justify > > the need for those. > > > >> Having a separate /64 > can > >> be a subscription issue - the provider may want to maintain separate > >> sessions for the multi-access. And, a MAG needs to have the session > state > >> as well for such purposes as QoS, policy and accounting. So, > signaling is > >> necessary regardless of whether the same /64 is used or not. > > > > If we can agree that there's a requirement that separate session be > maintained > > for each of the accesses, then we can discuss how to best fulfill > this > > requirements, including, but not necessarily relying on, signaling. > > > > I do not know yet how that would relate to the use of one (set of) > prefix(es) > > per physical interface. > > > > --julien From cjbc@it.uc3m.es Sat Jul 24 14:30: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 245303A67B5 for ; Sat, 24 Jul 2010 14:30:54 -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=[AWL=-0.000, 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 fHSneuxtnHgu for ; Sat, 24 Jul 2010 14:30:53 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id C41F13A67B8 for ; Sat, 24 Jul 2010 14:30:52 -0700 (PDT) X-uc3m-safe: yes Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 62B40843C44; Sat, 24 Jul 2010 23:31:11 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Basavaraj.Patil@nokia.com In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-0UGXKpxpho2RcutIKaQo" Organization: Universidad Carlos III de Madrid Date: Sat, 24 Jul 2010 23:29:40 +0200 Message-ID: <1280006980.4108.95.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17526.002 Cc: netext@ietf.org Subject: Re: [netext] Localized routing Solution I-D 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: Sat, 24 Jul 2010 21:30:54 -0000 --=-0UGXKpxpho2RcutIKaQo Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, I've read the draft and overall it seems OK for WG adoption, I support that. I have just a few comments/questions/suggestions: - Page 7: /s/Entries(LREs)/Entries (LREs)/ - Page 7: /s/next- hop/next-hop/ - Page 8: /is unable to make deliver/is unable to deliver/ - In the figures, it might be helpful to use <=3D=3D=3D=3D=3D> for tunneled= data - Page 13: In the last figure of section 6, I think the last data exchange between MAG and LMA1 should be removed, as there data traffic is routed locally without traversing the LMAs, right? One maybe more important comment is the following: we need to ensure that the different extensions being standardized now, such as localized routing and flow mobility are compatible and interoperate nicely. For example, the localized routing solution defines Localized Routing Entries that override the BUL entries. The flow mobility solution also requires default BUL entries be override, so we need to be careful on ensuring that the flow mobility solution and localized routing solution work properly when simultaneously enabled (or at the very least, we need to analyze the potential issues). Thanks, Carlos On Wed, 2010-07-14 at 01:13 +0200, Basavaraj.Patil@nokia.com wrote: > Hello, >=20 > We would like to propose the adoption of I-D: > http://tools.ietf.org/html/draft-krishnan-netext-pmip-lr-02 as the WG > baseline document. >=20 > Please review and provide feedback. We will ask WG consensus for making t= his > the WG document at IETF78. >=20 > -Basavaraj >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-0UGXKpxpho2RcutIKaQo 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) iEYEABECAAYFAkxLW0QACgkQNdy6TdFwT2cJWQCffc6kgORnZbM4en9edOUhPyuN CVwAoOHeqE67fOgeH5plQurVVCGwEKRZ =VDsW -----END PGP SIGNATURE----- --=-0UGXKpxpho2RcutIKaQo-- From adutta@research.telcordia.com Sat Jul 24 14:45:33 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 CD93B3A6829 for ; Sat, 24 Jul 2010 14:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhWLGYztXQaZ for ; Sat, 24 Jul 2010 14:45:32 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id B19FA3A683A for ; Sat, 24 Jul 2010 14:45:32 -0700 (PDT) Received: from [127.0.0.1] (vpntnlA16.research.telcordia.com [128.96.58.16]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id o6OLjNvs013015; Sat, 24 Jul 2010 17:45:25 -0400 (EDT) Message-ID: <4C4B5EF2.304@research.telcordia.com> Date: Sat, 24 Jul 2010 17:45:22 -0400 From: Ashutosh Dutta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Rajeev Koodli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] WG LC on draft-ietf-netext-redirect-03 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: Sat, 24 Jul 2010 21:45:33 -0000 Dear Chairs and WG members, I have read the draft. This draft is very useful and could be used for many PMIP related deployment. I support to advance this document. Regards Ashutosh On 7/6/2010 5:31 PM, Rajeev Koodli wrote: > > Hello folks, > > We would like to progress this draft. This is a three week LC on the draft. > Please provide your input by July 27. Hopefully, we can discuss the > input during the meeting on the 28th. > > Look forward to your reviews. > > ID URL: http://www.ietf.org/id/draft-ietf-netext-redirect-03.txt > > Thanks, > > -Rajeev (for chairs) > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Wed Jul 28 01:02:38 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 39E503A69D1 for ; Wed, 28 Jul 2010 01:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.3 X-Spam-Level: X-Spam-Status: No, score=-10.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, 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 FAppqeMy7eqJ for ; Wed, 28 Jul 2010 01:02:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 91E1328C106 for ; Wed, 28 Jul 2010 01:02:29 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQGAFiBT0ytJV2c/2dsb2JhbACTGYxScaRjmw+FNgSLKA X-IronPort-AV: E=Sophos;i="4.55,272,1278288000"; d="scan'208";a="140107841" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2010 08:02:51 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6S82ptw021775; Wed, 28 Jul 2010 08:02:51 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jul 2010 04:01:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jul 2010 04:01:08 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26661212E66E@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Note takers, Jabber scribes Thread-Index: AcsuKwkeJ4ZrTvqzTd+WJr9AfWiQxw== From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 28 Jul 2010 08:01:10.0574 (UTC) FILETIME=[0A8DFCE0:01CB2E2B] Cc: netext-chairs@ietf.org Subject: [netext] Note takers, Jabber scribes 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, 28 Jul 2010 08:02:38 -0000 Hello folks, could you please let us know if you would volunteer by responding to = this e-mail? We can save some meeting time..=20 Thanks! -Chairs From suresh.krishnan@ericsson.com Wed Jul 28 02:06:09 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 6F4333A687D for ; Wed, 28 Jul 2010 02:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 rKk3L9MShDWP for ; Wed, 28 Jul 2010 02:06:07 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 685593A67AE for ; Wed, 28 Jul 2010 02:06:07 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o6S96SVF024755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Jul 2010 04:06:29 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.134]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 28 Jul 2010 05:06:27 -0400 From: Suresh Krishnan To: "cjbc@it.uc3m.es" , "Basavaraj.Patil@nokia.com" Date: Wed, 28 Jul 2010 05:06:27 -0400 Thread-Topic: [netext] Localized routing Solution I-D Thread-Index: Acsrd5VsIu7KZX6JR3SudkZpP1KqtwCZaN7g Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150AD8FD93C@EUSAACMS0703.eamcs.ericsson.se> References: <1280006980.4108.95.camel@acorde.it.uc3m.es> In-Reply-To: <1280006980.4108.95.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 Cc: "netext@ietf.org" Subject: Re: [netext] Localized routing Solution I-D 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, 28 Jul 2010 09:06:09 -0000 Hi Carlos, Thanks for the comments. > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of Carlos Jes=FAs=20 > Bernardos Cano > Sent: Saturday, July 24, 2010 11:30 PM > To: Basavaraj.Patil@nokia.com > Cc: netext@ietf.org > Subject: Re: [netext] Localized routing Solution I-D >=20 > Hi, >=20 > I've read the draft and overall it seems OK for WG adoption,=20 > I support that. >=20 > I have just a few comments/questions/suggestions: >=20 > - Page 7: /s/Entries(LREs)/Entries (LREs)/ > - Page 7: /s/next- hop/next-hop/ > - Page 8: /is unable to make deliver/is unable to deliver/ > - In the figures, it might be helpful to use <=3D=3D=3D=3D=3D> for tunnel= ed data > - Page 13: In the last figure of section 6, I think the last=20 > data exchange between MAG and LMA1 should be removed, as=20 > there data traffic is routed locally without traversing the=20 > LMAs, right? Will make these changes in the next revision. >=20 > One maybe more important comment is the following: we need to=20 > ensure that the different extensions being standardized now,=20 > such as localized routing and flow mobility are compatible=20 > and interoperate nicely. For example, the localized routing=20 > solution defines Localized Routing Entries that override the=20 > BUL entries. The flow mobility solution also requires default=20 > BUL entries be override, so we need to be careful on ensuring=20 > that the flow mobility solution and localized routing=20 > solution work properly when simultaneously enabled (or at the=20 > very least, we need to analyze the potential issues). I think compatibility across extensions is very important as well.=20 Let's analyze this carefully as soon as the flow mobility solution Gets clearer. Thanks Suresh= From yh21.han@gmail.com Wed Jul 28 05:42:49 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 666BB28C155 for ; Wed, 28 Jul 2010 05:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgwZJv2mmtcx for ; Wed, 28 Jul 2010 05:42:46 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 5ADC828C14E for ; Wed, 28 Jul 2010 05:42:46 -0700 (PDT) Received: by pzk6 with SMTP id 6so2395668pzk.31 for ; Wed, 28 Jul 2010 05:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=D+IwBNPI++lblDLtKbdVh38RPgYONQMzQYiEko0bkEI=; b=jwCVUWWtol0pY8XLboY/Qex+KM6fnrIS+7hWzmqpzR7Zxt1ocUKRHccDtPjJM+4JIn dFo2TtpgzErlOA4z5/6VOoPSg1CC5/L96EZfT9EL9Z7oIqFiCIW6Gge1F2SRuCaj9o6V 85rtquuCS7jIcS/jnbQ5TMqXOgK7LD/a8GhT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=qAfwVkCxqk533WoFBvoyVn/aw8WH1DNdpO2RMVugKnEcr2ismlsPSHmSb+k02i9ql7 Xm6YL226fi2aMBSypJ9CizAYgavJZCvEWJgaQ17/BYeCdnBnOSJd4VJ2T6qO24hiejQF u3lEDEfCLiovCxjUEQXjV5xFen5oVw1t0tTw0= Received: by 10.142.154.5 with SMTP id b5mr7709036wfe.30.1280320989239; Wed, 28 Jul 2010 05:43:09 -0700 (PDT) Received: from pc100 ([220.68.82.28]) by mx.google.com with ESMTPS id q27sm7071431wfc.18.2010.07.28.05.43.07 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 05:43:08 -0700 (PDT) From: "Youn-Hee Han" To: Date: Wed, 28 Jul 2010 21:43:04 +0900 Message-ID: <4c5025dc.1b768e0a.5695.6b00@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E8_01CB2E9D.DDDCCF50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsuUmxDyBXzBUAKRc6GkiTSw8BhGA== Content-Language: ko Subject: [netext] Needs of traffic spec. on MAG? 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, 28 Jul 2010 12:42:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03E8_01CB2E9D.DDDCCF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Bernardos, I'd like to ask a question about "draft-bernardos-netext-pmipv6-flowmob-00." In the call procedure figure, I noticed that traffic specification is delivered to MAG from LMA. I understand that the specification should be managed at LMA to do a traffic filtering. However, is such a traffic filtering still needed at MAG? IMHO, it is not needed at MAG. If so, why is the specification delivered to MAG? Isn't sufficient that the home network prefix related to the traffic is delivered to MAG? Youn-Hee Han ------=_NextPart_000_03E8_01CB2E9D.DDDCCF50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Bernardos,

 

I’d like to ask a question = about = “draft-bernardos-netext-pmipv6-flowmob-00.”=

In the call procedure figure, I = noticed that traffic specification is delivered to MAG from LMA. =

I understand that the = specification should be managed at LMA to do a traffic filtering.

 

However, is such a traffic = filtering still needed at MAG?

IMHO, it is not needed at MAG. = If so, why is the specification delivered to MAG?

Isn’t sufficient that the = home network prefix related to the traffic is delivered to MAG?

 

Youn-Hee = Han

 

------=_NextPart_000_03E8_01CB2E9D.DDDCCF50-- From behcetsarikaya@yahoo.com Wed Jul 28 05:43:24 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 867A328C14E for ; Wed, 28 Jul 2010 05:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] 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 FG01tQWgbQr9 for ; Wed, 28 Jul 2010 05:43:23 -0700 (PDT) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id 582C628C144 for ; Wed, 28 Jul 2010 05:43:23 -0700 (PDT) Received: (qmail 92858 invoked by uid 60001); 28 Jul 2010 12:43:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280321023; bh=WorMpPa7SNNM02wlGomEOpMqbTdXmDzVlnbnHP6rkbU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=yjY6tdWvhZrhPQXAQOhZ1TXBNT4d5R7EE7qrKNOODJwRqLewGLVuBtspUFSo0Ix4/8qBtrxcEbOKAmpNLpp3i6w8tfEJpFiHwtyZIHDbrcrNahCaeve2AkzdHLWgkbU8EgYChVsUfr3tYlzXbwenrua4EFe0v9PYZIALxDBdxBA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wNecDXqNa5baYspNEXlbyxpXVChEC9+c+29PH858F5K4CgSiubiQesLW2d2a4de84clfU9T2m92oSyB9y8brW2IdK28qE4diIxuw+QQw140L781Fr3qclwjOmAHbR1YJXirj5UVZicPFWG5oucXFAqSXEKo4xYAZyEBfLnpWZVU=; Message-ID: <357671.90981.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: zl2NJkEVM1mYXE.UMaRsjs7qoNbvCOzlpgfVHDivmIV.GaN accI49PGte_QIpWWSPbWQD.mkWhVbGkrkCdoi7wVPaWlxGvyKcnB_4dIGfOK YMkQFmlUDhf7.o1wsYoS6ywxDurPvAImtdikI.BZteszywbSyViqb0RL2QxK gGFSeCkePWg7JdQbDob58MEWFIlChrf1sv.Vg9DKc9iUYFIQRiGY4d.ICZX6 IOgrbXOQpLsiXozYpDaeprKF1oWBJLbbhUgsTCUbZBopBbceK2BVkDiwp9wU 4X2SiNnYcGtS16yXLR.la33cYJRCevKzGLPEJA.Prt3MCQpjpj2M3bNV..Ba Cusx2_mtzSs6O..Y5qJRcD2x2zg-- Received: from [130.129.112.247] by web111406.mail.gq1.yahoo.com via HTTP; Wed, 28 Jul 2010 05:43:42 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.277674 Date: Wed, 28 Jul 2010 05:43:42 -0700 (PDT) From: Behcet Sarikaya To: netext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netext] Prefix Sharing Issue in Flow Mobility 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: Wed, 28 Jul 2010 12:43:24 -0000 Hi Raj, As has been pointed out today in the session, WG has concerns on this issue. In fact it is not a new issue. We had a draft http://tools.ietf.org/id/draft-sarikaya-netext-fb-support-extensions-00.txt Earlier Conny has a draft. All these works have been somehow ignored/gone undiscussed. Now all of a sudden we are talking about it in the context of Carlos' draft. I think that's where the problem is. I wish Carlos would have included some information on this rather than making some assumptions. After all, the above draft was selected as one of the contributing drafts. Regards, Behcet From alexandru.petrescu@gmail.com Wed Jul 28 05:44: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 CE39B28C130 for ; Wed, 28 Jul 2010 05:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh2WJwJ2a9Xo for ; Wed, 28 Jul 2010 05:44:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B3A0C28C148 for ; Wed, 28 Jul 2010 05:44:13 -0700 (PDT) Received: by bwz7 with SMTP id 7so4630353bwz.31 for ; Wed, 28 Jul 2010 05:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=KM5Cs5hnPhJ9DATZrDVsUMgQnSJMCos8I1+pFH3Kj8g=; b=q5BDpwBiM8JK2QHf0D9psxJquUkJ4ERAQoeFhGJXAXtV3I1leghIRHPSP4++03uRt9 NgslSBWipcDb/VyP7c3VMZ4Xy4+YER9DGmkktQKUnoa5C90E2mbwboGfXfpbl++XG4Q8 oooMNijClM/AfpeKMOBaRV6U8LG9lspO1fSBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pS0fKh7OjZ3t6FdHkloz41IVf6G3KdHHSmixqHosZrRsnVelp9XRgtGyp9ie0NBj6r bA9ac4KBT2bG21CbujEq6NZ85Iuodh1FvyHxohLZ2W4EO67Et+mrbi1E+eV70P9ErHNq Jqm2u24dr9oV7diaweQtc6nw9gKn8bp7N9WMg= MIME-Version: 1.0 Received: by 10.204.47.99 with SMTP id m35mr7862647bkf.106.1280321075912; Wed, 28 Jul 2010 05:44:35 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Wed, 28 Jul 2010 05:44:35 -0700 (PDT) Date: Wed, 28 Jul 2010 14:44:35 +0200 Message-ID: From: Alexandru Petrescu To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [netext] Is logical interface the interface of the default route? 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, 28 Jul 2010 12:44:14 -0000 Regarding today's presentation on logical interfaces, I had a question - is the logical interface corresponding precisely to the default route? I would have raised this question when Carlos showed the routing tables on slides. If not - should applications be modified or are we still keeping applications unmodified in order to work with PMIP flow mobility presented by Carlos. (for example, in the demo announced to happen soon - is the bonding ("bridging" kind) interface corresponding to the default route?). Alex From telemaco.melia@alcatel-lucent.com Wed Jul 28 05:49:26 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 413F228C163 for ; Wed, 28 Jul 2010 05:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv+NLen8uGVW for ; Wed, 28 Jul 2010 05:49:25 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 9043228C15B for ; Wed, 28 Jul 2010 05:49:24 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6SCncjI023813 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Jul 2010 14:49:46 +0200 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 28 Jul 2010 14:49:44 +0200 From: "MELIA, TELEMACO (TELEMACO)" To: Alexandru Petrescu , "netext@ietf.org" Date: Wed, 28 Jul 2010 14:48:14 +0200 Thread-Topic: [netext] Is logical interface the interface of the default route? Thread-Index: AcsuUqtnH1mfhCqgSYep3AaZo379XQAAHlyW Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE0AD004B@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [netext] Is logical interface the interface of the default route? 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, 28 Jul 2010 12:49:26 -0000 Hello, The default route is through the logical interface and applications do not = need to be modified, they perform standard routing table lookup. we can discuss more in front of the demo if you like. telemaco ________________________________________ From: netext-bounces@ietf.org [netext-bounces@ietf.org] On Behalf Of Alexan= dru Petrescu [alexandru.petrescu@gmail.com] Sent: Wednesday, July 28, 2010 2:44 PM To: netext@ietf.org Subject: [netext] Is logical interface the interface of the default route? Regarding today's presentation on logical interfaces, I had a question - is the logical interface corresponding precisely to the default route? I would have raised this question when Carlos showed the routing tables on slides. If not - should applications be modified or are we still keeping applications unmodified in order to work with PMIP flow mobility presented by Carlos. (for example, in the demo announced to happen soon - is the bonding ("bridging" kind) interface corresponding to the default route?). Alex _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext= From cjbc@it.uc3m.es Wed Jul 28 05:50:28 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 B4ABF28C104 for ; Wed, 28 Jul 2010 05:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[AWL=0.188, 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 IdZ1ZskQLHzB for ; Wed, 28 Jul 2010 05:50:26 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 91C4C28C15B for ; Wed, 28 Jul 2010 05:50:24 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.99.227] (dhcp-63e3.meeting.ietf.org [130.129.99.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E71E5BDE911; Wed, 28 Jul 2010 14:50:45 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-eIjFILC+M5dKZ5tCYXge" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Jul 2010 14:52:02 +0200 Message-ID: <1280321522.4001.7.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17534.007 Cc: netext@ietf.org Subject: Re: [netext] Is logical interface the interface of the default route? 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: Wed, 28 Jul 2010 12:50:28 -0000 --=-eIjFILC+M5dKZ5tCYXge Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Alex, On Wed, 2010-07-28 at 14:44 +0200, Alexandru Petrescu wrote: > Regarding today's presentation on logical interfaces, I had a question > - is the logical interface corresponding precisely to the default > route? >=20 > I would have raised this question when Carlos showed the routing > tables on slides. >=20 > If not - should applications be modified or are we still keeping > applications unmodified in order to work with PMIP flow mobility > presented by Carlos. >=20 > (for example, in the demo announced to happen soon - is the bonding > ("bridging" kind) interface corresponding to the default route?). Yes, it is. On the MN, the logical interface is the interface of the default route. Carlos >=20 > Alex > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-eIjFILC+M5dKZ5tCYXge 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) iEYEABECAAYFAkxQJ/IACgkQNdy6TdFwT2c8BgCgi53wITJ+ru1qr4Gc0MpVT4Ph Rm0An0VOlBXMv9W2oAY3T49Clv6ovC3p =vG15 -----END PGP SIGNATURE----- --=-eIjFILC+M5dKZ5tCYXge-- From adutta@research.telcordia.com Wed Jul 28 05:54:29 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 DF2A128C123 for ; Wed, 28 Jul 2010 05:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KncN4tw6ebe for ; Wed, 28 Jul 2010 05:54:29 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id E494528C0E8 for ; Wed, 28 Jul 2010 05:54:28 -0700 (PDT) Received: from [127.0.0.1] (vpntnlA16.research.telcordia.com [128.96.58.16]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id o6SCskp8015265; Wed, 28 Jul 2010 08:54:48 -0400 (EDT) Message-ID: <4C502899.9000004@research.telcordia.com> Date: Wed, 28 Jul 2010 08:54:49 -0400 From: Ashutosh Dutta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "MELIA, TELEMACO (TELEMACO)" References: <3D6C64F2D792B540BAAEBCEF6509363B0EE0AD004B@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> In-Reply-To: <3D6C64F2D792B540BAAEBCEF6509363B0EE0AD004B@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: [netext] Logical Interface Demo Place/Timing? 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, 28 Jul 2010 12:54:30 -0000 Telemaco, Where is the logical interface demo, day and time? Thanks Ashutosh On 7/28/2010 8:48 AM, MELIA, TELEMACO (TELEMACO) wrote: > Hello, > > The default route is through the logical interface and applications do not need to be modified, they perform standard routing table lookup. > > we can discuss more in front of the demo if you like. > > telemaco > > ________________________________________ > From: netext-bounces@ietf.org [netext-bounces@ietf.org] On Behalf Of Alexandru Petrescu [alexandru.petrescu@gmail.com] > Sent: Wednesday, July 28, 2010 2:44 PM > To: netext@ietf.org > Subject: [netext] Is logical interface the interface of the default route? > > Regarding today's presentation on logical interfaces, I had a question > - is the logical interface corresponding precisely to the default > route? > > I would have raised this question when Carlos showed the routing > tables on slides. > > If not - should applications be modified or are we still keeping > applications unmodified in order to work with PMIP flow mobility > presented by Carlos. > > (for example, in the demo announced to happen soon - is the bonding > ("bridging" kind) interface corresponding to the default route?). > > Alex > _______________________________________________ > 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 cjbc@it.uc3m.es Wed Jul 28 05:57:06 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 3D82428C123 for ; Wed, 28 Jul 2010 05:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=0.125, 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 aBpnJVmqWojJ for ; Wed, 28 Jul 2010 05:57:04 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id BFFC428C0E8 for ; Wed, 28 Jul 2010 05:57:04 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.99.227] (dhcp-63e3.meeting.ietf.org [130.129.99.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 07D4283653E; Wed, 28 Jul 2010 14:57:25 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Behcet Sarikaya In-Reply-To: <357671.90981.qm@web111406.mail.gq1.yahoo.com> References: <357671.90981.qm@web111406.mail.gq1.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Hy1kEL66uD1KfpKnEsnv" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Jul 2010 14:58:43 +0200 Message-ID: <1280321923.4001.13.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17534.007 Cc: netext@ietf.org Subject: Re: [netext] Prefix Sharing Issue in Flow Mobility 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: Wed, 28 Jul 2010 12:57:06 -0000 --=-Hy1kEL66uD1KfpKnEsnv Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Behcet, On Wed, 2010-07-28 at 05:43 -0700, Behcet Sarikaya wrote: > Hi Raj, > As has been pointed out today in the session, WG has concerns on this i= ssue.=20 > In fact it is not a new issue. We had a draft > http://tools.ietf.org/id/draft-sarikaya-netext-fb-support-extensions-00.t= xt >=20 > Earlier Conny has a draft. >=20 > All these works have been somehow ignored/gone undiscussed.=20 No, not ignored. Current draft is an initial version for discussion to get feedback so it can be improved. Quoting current version: "How the LMA decides whether to assign the same prefix or a different one is TBD". Therefore this has not been ignored, it is one of the topics identified where more details are yet required. >=20 > Now all of a sudden we are talking about it in the context of Carlos' dra= ft. I=20 > think that's where the problem is. I wish Carlos would have included some= =20 > information on this rather than making some assumptions. After all, the a= bove=20 > draft was selected as one of the contributing drafts. Current draft tries to come up with the simplest baseline protocol possible, following an approach that is based on the common mechanisms that have been proposed by different drafts. As mentioned, there are of course details to be worked out in future revisions. Carlos >=20 > Regards, >=20 > Behcet >=20 >=20 > =20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Hy1kEL66uD1KfpKnEsnv 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) iEYEABECAAYFAkxQKYMACgkQNdy6TdFwT2e4nwCcCGhvOEAOC9/hl6mDiAgZNkfC 68QAn0cxvrQamGCQixRmkPaQK8LwBFI8 =wNdj -----END PGP SIGNATURE----- --=-Hy1kEL66uD1KfpKnEsnv-- From telemaco.melia@alcatel-lucent.com Wed Jul 28 06:04:16 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 3D1B528C12F for ; Wed, 28 Jul 2010 06:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JpY1oA4rpbP for ; Wed, 28 Jul 2010 06:04:15 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 081793A67B2 for ; Wed, 28 Jul 2010 06:04:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6SD11Q3027590 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Jul 2010 15:04:34 +0200 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 28 Jul 2010 15:04:30 +0200 From: "MELIA, TELEMACO (TELEMACO)" To: Ashutosh Dutta Date: Wed, 28 Jul 2010 15:01:39 +0200 Thread-Topic: Logical Interface Demo Place/Timing? Thread-Index: AcsuVBdnoTwxAuUoSN6GO4W/M6bUBgAAO1CY Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE0AD004D@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> References: <3D6C64F2D792B540BAAEBCEF6509363B0EE0AD004B@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com>, <4C502899.9000004@research.telcordia.com> In-Reply-To: <4C502899.9000004@research.telcordia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "netext@ietf.org" Subject: Re: [netext] Logical Interface Demo Place/Timing? 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, 28 Jul 2010 13:04:16 -0000 Hello Ashutosh, Since we could not get a room we will be doing the setup in the terminal ro= om at 15:30H. It will end up pretty much in a ad-hpoc discussion in the hope to get peopl= e on the same page and push forward the work on flow mobility and inter-tec= hnology handoff. hope to discuss with you tomorrow telemaco ________________________________________ From: Ashutosh Dutta [adutta@research.telcordia.com] Sent: Wednesday, July 28, 2010 2:54 PM To: MELIA, TELEMACO (TELEMACO) Cc: Alexandru Petrescu; netext@ietf.org Subject: Logical Interface Demo Place/Timing? Telemaco, Where is the logical interface demo, day and time? Thanks Ashutosh On 7/28/2010 8:48 AM, MELIA, TELEMACO (TELEMACO) wrote: > Hello, > > The default route is through the logical interface and applications do no= t need to be modified, they perform standard routing table lookup. > > we can discuss more in front of the demo if you like. > > telemaco > > ________________________________________ > From: netext-bounces@ietf.org [netext-bounces@ietf.org] On Behalf Of Alex= andru Petrescu [alexandru.petrescu@gmail.com] > Sent: Wednesday, July 28, 2010 2:44 PM > To: netext@ietf.org > Subject: [netext] Is logical interface the interface of the default route= ? > > Regarding today's presentation on logical interfaces, I had a question > - is the logical interface corresponding precisely to the default > route? > > I would have raised this question when Carlos showed the routing > tables on slides. > > If not - should applications be modified or are we still keeping > applications unmodified in order to work with PMIP flow mobility > presented by Carlos. > > (for example, in the demo announced to happen soon - is the bonding > ("bridging" kind) interface corresponding to the default route?). > > Alex > _______________________________________________ > 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 cjbc@it.uc3m.es Wed Jul 28 06:04:59 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 3C88B28C17C for ; Wed, 28 Jul 2010 06:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=0.094, 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 xsqKp0tmFqZs for ; Wed, 28 Jul 2010 06:04:58 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 9EEED28C139 for ; Wed, 28 Jul 2010 06:04:57 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.99.227] (dhcp-63e3.meeting.ietf.org [130.129.99.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id B9FA483653E; Wed, 28 Jul 2010 15:05:19 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Youn-Hee Han In-Reply-To: <4c5025dc.1b768e0a.5695.6b00@mx.google.com> References: <4c5025dc.1b768e0a.5695.6b00@mx.google.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-RLLzMNKqp5twkEaR4EdT" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Jul 2010 15:06:37 +0200 Message-ID: <1280322397.4001.21.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17534.007 Cc: netext@ietf.org Subject: Re: [netext] Needs of traffic spec. on MAG? 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: Wed, 28 Jul 2010 13:04:59 -0000 --=-RLLzMNKqp5twkEaR4EdT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Youn-Hee, On Wed, 2010-07-28 at 21:43 +0900, Youn-Hee Han wrote: > Dear Bernardos, >=20 > =20 >=20 > I=E2=80=99d like to ask a question about > =E2=80=9Cdraft-bernardos-netext-pmipv6-flowmob-00.=E2=80=9D >=20 > In the call procedure figure, I noticed that traffic specification is > delivered to MAG from LMA.=20 >=20 > I understand that the specification should be managed at LMA to do a > traffic filtering.=20 >=20 > =20 >=20 > However, is such a traffic filtering still needed at MAG? The MAG needs to know the flow that is gonna be routed through it, so it can insert the required routing state. >=20 > IMHO, it is not needed at MAG. If so, why is the specification > delivered to MAG? This is something that can be discussed. The minimum info required is the MN's prefix of the moved flow, so the route is installed at the MAG. If finer control is required (e.g., prevent the MN send flows through a MAG that is not the one the LMA has setup flow mobility state, or other purposes), then the flow mobility (traffic selector, e.g., 5-tuple) should be delivered to the MAG. >=20 > Isn=E2=80=99t sufficient that the home network prefix related to the traf= fic > is delivered to MAG? That'd be the minimum info. As mentioned before, the MAG may need the whole flow definition, and in that case the LMA has to deliver that information to the MAG. Thanks, Carlos >=20 > =20 >=20 > Youn-Hee Han >=20 > =20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-RLLzMNKqp5twkEaR4EdT 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) iEYEABECAAYFAkxQK10ACgkQNdy6TdFwT2enbgCfYEiTYXBBZN0n50SyrEEVdyK/ oOoAnAwekykOeu+DPZqB34bXUPfgFTq/ =A/Q7 -----END PGP SIGNATURE----- --=-RLLzMNKqp5twkEaR4EdT-- From behcetsarikaya@yahoo.com Wed Jul 28 07:36: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 2A9223A68F6 for ; Wed, 28 Jul 2010 07:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jiF5wsRVn89N for ; Wed, 28 Jul 2010 07:36:12 -0700 (PDT) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id 8D66D3A687A for ; Wed, 28 Jul 2010 07:36:12 -0700 (PDT) Received: (qmail 36967 invoked by uid 60001); 28 Jul 2010 14:36:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280327792; bh=WRKZZOmeUWcRJ8jPAkrorshxxlWy5p/lrnllRFirT3Q=; 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=I/WbosYpt6N3NhS806h3nIr92tJEMkZoCl7u/JVAPrr/dSDetRwMPKzwn1wHbDf1MVjzIdQJn1Wvg6FyXU0ymSSBiHnDicza9+pUjTS9rT/CGrSQnYOfzpyELHWxzGP/CQV21/UabwSjO+sR8XZDgtzQk65B9hYDAxJV+oMGP1o= 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=TO3iqxTDX1TgVPiH44arZfRUZ5LMuHPuGPpSiZfdIU+/UCZ174CqWt8PuDQyApbTysf7VlEIwQJxByatqLApv9WQwdXE8Ufd0nq87gpZJNkLh+4/3OMfnwOx8xiG0dSXIlEg54tBOKx0UlBACJYYUf4SGgEKSKpRmZMysb9IPFA=; Message-ID: <668115.35404.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: BvbZs5gVM1lJ6S_lwa3zSNWlvxSP6SEKHDh3guLOksqkSVs 20XEzaVcQlO2akstn5qjTFmMt7pRopnaPQR4fkWCY8WcCieat2ULWJgg1PW0 lU_qv_aC7HJSCROi.7r9u057WW.HBeXrcbd3NN.7gUi7d0RLLg8CUr9YZ9KB kgdtYGxk71CC1o8EI8r5p_z1.v.BgyvS5EK1j2IKcGhufiQWpOXHu5IHSx3z vgwyPAwo4qJeJhb2d9Yto1i62Kjuq8kgfEB8njQGlvH7kiSyqNVGWA2FYBw2 50q2xNuZZo7qAuJV9lWQjmC9cEH8yxE18B4RLNe4cfjIqUtUV7POzyO2t5_N kOYBBqjE9Cqc2W18DAg9y2wI9iYUcWDMD Received: from [130.129.112.247] by web111410.mail.gq1.yahoo.com via HTTP; Wed, 28 Jul 2010 07:36:32 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.277674 References: <357671.90981.qm@web111406.mail.gq1.yahoo.com> <1280321923.4001.13.camel@acorde.it.uc3m.es> Date: Wed, 28 Jul 2010 07:36:32 -0700 (PDT) From: Behcet Sarikaya To: cjbc@it.uc3m.es In-Reply-To: <1280321923.4001.13.camel@acorde.it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Prefix Sharing Issue in Flow Mobility 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: Wed, 28 Jul 2010 14:36:18 -0000 Hi Carlos,=0A=0A=0A=0A----- Original Message ----=0A> From: Carlos Jes=FAs = Bernardos Cano =0A> To: Behcet Sarikaya =0A> Cc: netext@ietf.org=0A> Sent: Wed, July 28, 2010 7:58:43 AM=0A> Subje= ct: Re: [netext] Prefix Sharing Issue in Flow Mobility=0A> =0A> Hi Behcet,= =0A> =0A> On Wed, 2010-07-28 at 05:43 -0700, Behcet Sarikaya wrote:=0A> > = Hi Raj,=0A> > As has been pointed out today in the session, WG has conce= rns on this =0A>issue. =0A>=0A> > In fact it is not a new issue. We had= a draft=0A> > http://tools.ietf.org/id/draft-sarikaya-netext-fb-support-e= xtensions-00.txt=0A> > =0A> > Earlier Conny has a draft.=0A> > =0A> > All t= hese works have been somehow ignored/gone undiscussed. =0A> =0A> No, not i= gnored. Current draft is an initial version for discussion to=0A> get feed= back so it can be improved. Quoting current version: "How the=0A> LMA deci= des whether to assign the same prefix or a different one is=0A> TBD". Ther= efore this has not been ignored, it is one of the topics=0A> identified wh= ere more details are yet required.=0A> =0A=0AI wish you mentioned this duri= ng your presentation. Now it is clearer to me.=0A=0ARegards,=0A=0ABehcet=0A= =0A=0A=0A From cjbc@it.uc3m.es Wed Jul 28 08:16: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 28A733A6A9F for ; Wed, 28 Jul 2010 08:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.075, 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 cf7VZwzUAbv1 for ; Wed, 28 Jul 2010 08:16:48 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 707113A6A95 for ; Wed, 28 Jul 2010 08:16:42 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.99.227] (dhcp-63e3.meeting.ietf.org [130.129.99.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 720FB7F7D9E; Wed, 28 Jul 2010 17:17:04 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Youn-Hee Han In-Reply-To: <1280322397.4001.21.camel@acorde.it.uc3m.es> References: <4c5025dc.1b768e0a.5695.6b00@mx.google.com> <1280322397.4001.21.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SFyCKvsWMzGLyLXFhWqV" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Jul 2010 17:18:21 +0200 Message-ID: <1280330301.4001.87.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17536.000 Cc: netext@ietf.org Subject: Re: [netext] Needs of traffic spec. on MAG? 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: Wed, 28 Jul 2010 15:16:54 -0000 --=-SFyCKvsWMzGLyLXFhWqV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One more comment. As I mentioned in another e-mail to Julien, there might be the need of making the MAG aware of the flow descriptions (traffic selector) in case the MN is attached through different interfaces to the same MAG. In that case we might need some support and signaling to make the MAG aware of the interface that should be used to deliver packets of this flow to the MN. Opinions? Carlos On Wed, 2010-07-28 at 15:06 +0200, Carlos Jes=C3=BAs Bernardos Cano wrote: > Dear Youn-Hee, >=20 > On Wed, 2010-07-28 at 21:43 +0900, Youn-Hee Han wrote: > > Dear Bernardos, > >=20 > > =20 > >=20 > > I=E2=80=99d like to ask a question about > > =E2=80=9Cdraft-bernardos-netext-pmipv6-flowmob-00.=E2=80=9D > >=20 > > In the call procedure figure, I noticed that traffic specification is > > delivered to MAG from LMA.=20 > >=20 > > I understand that the specification should be managed at LMA to do a > > traffic filtering.=20 > >=20 > > =20 > >=20 > > However, is such a traffic filtering still needed at MAG? >=20 > The MAG needs to know the flow that is gonna be routed through it, so it > can insert the required routing state. >=20 > >=20 > > IMHO, it is not needed at MAG. If so, why is the specification > > delivered to MAG? >=20 > This is something that can be discussed. The minimum info required is > the MN's prefix of the moved flow, so the route is installed at the MAG. > If finer control is required (e.g., prevent the MN send flows through a > MAG that is not the one the LMA has setup flow mobility state, or other > purposes), then the flow mobility (traffic selector, e.g., 5-tuple) > should be delivered to the MAG. >=20 > >=20 > > Isn=E2=80=99t sufficient that the home network prefix related to the tr= affic > > is delivered to MAG? >=20 > That'd be the minimum info. As mentioned before, the MAG may need the > whole flow definition, and in that case the LMA has to deliver that > information to the MAG. >=20 > Thanks, >=20 > Carlos >=20 > >=20 > > =20 > >=20 > > Youn-Hee Han > >=20 > > =20 > >=20 > >=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 Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-SFyCKvsWMzGLyLXFhWqV 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) iEYEABECAAYFAkxQSj0ACgkQNdy6TdFwT2fd3ACfXGhJS3hu/lVmBalZMFpst0No xmkAnjgNEhfImuyRRQgv0/LZ1LFsIsVB =GtmB -----END PGP SIGNATURE----- --=-SFyCKvsWMzGLyLXFhWqV-- From julienl@qualcomm.com Thu Jul 29 04:49: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 5B6453A69E1 for ; Thu, 29 Jul 2010 04:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 KWCCwOLJMaxB for ; Thu, 29 Jul 2010 04:49:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3F5FE3A6980 for ; Thu, 29 Jul 2010 04:49:03 -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=1280404167; x=1311940167; 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:=20"cjbc@it.uc3m.es"=20,=20Youn-Hee =20Han=20|CC:=20"netext@ietf.org"=20< netext@ietf.org>|Date:=20Thu,=2029=20Jul=202010=2004:49:2 4=20-0700|Subject:=20RE:=20[netext]=20Needs=20of=20traffi c=20spec.=20on=20MAG?|Thread-Topic:=20[netext]=20Needs=20 of=20traffic=20spec.=20on=20MAG?|Thread-Index:=20AcsuVYqv NYwXeQEjQWuQSA8okNNVJAAvjVLQ|Message-ID:=20|References:=20<4c5025dc.1b768e0a.5695.6b00@mx.google.co m>=0D=0A=20<1280322397.4001.21.camel@acorde.it.uc3m.es> |In-Reply-To:=20<1280322397.4001.21.camel@acorde.it.uc3m. es>|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"utf-8 "|Content-Transfer-Encoding:=20base64|MIME-Version:=201.0; bh=CgXBXqTBMjlKWrPUFiRRJ65XH4sO4FaJWu/eyKUgCh8=; b=BDNXljlMuYYkXnjpYtiexG5MnatjNrbXqgC7127xxhRl7eotX6DiZYXi tYNCShZLJTMCSHNtiEMPar+ZrwFCSmU9hw7xVvJnoc+iSWsKWSlWt8cou +I7DHMYVom4YazWdZ8AtSebPKPOMdBDvenhjdEXAE9dmR9HKYfwhcdRds c=; X-IronPort-AV: E=McAfee;i="5400,1158,6057"; a="49055138" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 29 Jul 2010 04:49:27 -0700 X-IronPort-AV: E=Sophos;i="4.55,277,1278313200"; d="scan'208";a="70233082" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 29 Jul 2010 04:49:27 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Jul 2010 04:49:26 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.0.694.0; Thu, 29 Jul 2010 04:49:26 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 29 Jul 2010 04:49:26 -0700 From: "Laganier, Julien" To: "cjbc@it.uc3m.es" , Youn-Hee Han Date: Thu, 29 Jul 2010 04:49:24 -0700 Thread-Topic: [netext] Needs of traffic spec. on MAG? Thread-Index: AcsuVYqvNYwXeQEjQWuQSA8okNNVJAAvjVLQ Message-ID: References: <4c5025dc.1b768e0a.5695.6b00@mx.google.com> <1280322397.4001.21.camel@acorde.it.uc3m.es> In-Reply-To: <1280322397.4001.21.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] Needs of traffic spec. on MAG? 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: Thu, 29 Jul 2010 11:49:04 -0000 Q2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyB3cm90ZToNCj4gDQo+IERlYXIgWW91bi1IZWUs DQo+IA0KPiBPbiBXZWQsIDIwMTAtMDctMjggYXQgMjE6NDMgKzA5MDAsIFlvdW4tSGVlIEhhbiB3 cm90ZToNCj4gPiBEZWFyIEJlcm5hcmRvcywNCj4gPg0KPiA+DQo+ID4NCj4gPiBJ4oCZZCBsaWtl IHRvIGFzayBhIHF1ZXN0aW9uIGFib3V0DQo+ID4g4oCcZHJhZnQtYmVybmFyZG9zLW5ldGV4dC1w bWlwdjYtZmxvd21vYi0wMC7igJ0NCj4gPg0KPiA+IEluIHRoZSBjYWxsIHByb2NlZHVyZSBmaWd1 cmUsIEkgbm90aWNlZCB0aGF0IHRyYWZmaWMgc3BlY2lmaWNhdGlvbiBpcw0KPiA+IGRlbGl2ZXJl ZCB0byBNQUcgZnJvbSBMTUEuDQo+ID4NCj4gPiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgc3BlY2lm aWNhdGlvbiBzaG91bGQgYmUgbWFuYWdlZCBhdCBMTUEgdG8gZG8gYQ0KPiA+IHRyYWZmaWMgZmls dGVyaW5nLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEhvd2V2ZXIsIGlzIHN1Y2ggYSB0cmFmZmljIGZp bHRlcmluZyBzdGlsbCBuZWVkZWQgYXQgTUFHPw0KPiANCj4gVGhlIE1BRyBuZWVkcyB0byBrbm93 IHRoZSBmbG93IHRoYXQgaXMgZ29ubmEgYmUgcm91dGVkIHRocm91Z2ggaXQsIHNvDQo+IGl0IGNh biBpbnNlcnQgdGhlIHJlcXVpcmVkIHJvdXRpbmcgc3RhdGUuDQoNCklmIGEgc2luZ2xlIHByZWZp eCBpcyB1c2UgYWNyb3NzIGFsbCBvZiB0aGUgTU4gYWNjZXNzZXMgdGhlbiB0aGVyZSdzIG5vIG5l ZWQgZm9yIHRoaXMuDQoNCj4gPiBJTUhPLCBpdCBpcyBub3QgbmVlZGVkIGF0IE1BRy4gSWYgc28s IHdoeSBpcyB0aGUgc3BlY2lmaWNhdGlvbg0KPiA+IGRlbGl2ZXJlZCB0byBNQUc/DQo+IA0KPiBU aGlzIGlzIHNvbWV0aGluZyB0aGF0IGNhbiBiZSBkaXNjdXNzZWQuIFRoZSBtaW5pbXVtIGluZm8g cmVxdWlyZWQgaXMNCj4gdGhlIE1OJ3MgcHJlZml4IG9mIHRoZSBtb3ZlZCBmbG93LCBzbyB0aGUg cm91dGUgaXMgaW5zdGFsbGVkIGF0IHRoZSBNQUcuDQo+IElmIGZpbmVyIGNvbnRyb2wgaXMgcmVx dWlyZWQgKGUuZy4sIHByZXZlbnQgdGhlIE1OIHNlbmQgZmxvd3MgdGhyb3VnaCBhDQo+IE1BRyB0 aGF0IGlzIG5vdCB0aGUgb25lIHRoZSBMTUEgaGFzIHNldHVwIGZsb3cgbW9iaWxpdHkgc3RhdGUs IG9yIG90aGVyDQo+IHB1cnBvc2VzKSwgdGhlbiB0aGUgZmxvdyBtb2JpbGl0eSAodHJhZmZpYyBz ZWxlY3RvciwgZS5nLiwgNS10dXBsZSkNCj4gc2hvdWxkIGJlIGRlbGl2ZXJlZCB0byB0aGUgTUFH Lg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgbmVlZGVkLg0KDQo+ID4gSXNu4oCZdCBzdWZmaWNp ZW50IHRoYXQgdGhlIGhvbWUgbmV0d29yayBwcmVmaXggcmVsYXRlZCB0byB0aGUgdHJhZmZpYw0K PiA+IGlzIGRlbGl2ZXJlZCB0byBNQUc/DQo+IA0KPiBUaGF0J2QgYmUgdGhlIG1pbmltdW0gaW5m by4gQXMgbWVudGlvbmVkIGJlZm9yZSwgdGhlIE1BRyBtYXkgbmVlZCB0aGUNCj4gd2hvbGUgZmxv dyBkZWZpbml0aW9uLCBhbmQgaW4gdGhhdCBjYXNlIHRoZSBMTUEgaGFzIHRvIGRlbGl2ZXIgdGhh dA0KPiBpbmZvcm1hdGlvbiB0byB0aGUgTUFHLg0KDQpJZiBhIHNpbmdsZSBwcmVmaXggaXMgdXNl IGFjcm9zcyBhbGwgb2YgdGhlIE1OIGFjY2Vzc2VzIHRoZW4gdGhlcmUncyBubyBuZWVkIHRvIGRv IHRoaXMuDQoNCi0tanVsaWVuDQo= From yh21.han@gmail.com Thu Jul 29 06:00:47 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 551963A686A for ; Thu, 29 Jul 2010 06:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WswnSfHdGqns for ; Thu, 29 Jul 2010 06:00:43 -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 330AB28C221 for ; Thu, 29 Jul 2010 06:00:43 -0700 (PDT) Received: by vws10 with SMTP id 10so261724vws.31 for ; Thu, 29 Jul 2010 06:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=C6E5vk872w3VmL5HZPsUuPDkd6ilSI5Q9cw3Q/oJItk=; b=rGr9HoXYLFExu2nL/u19kWXRE/buE1JH8vO1ozpg3mM3RVof2uMYBuAkqclmFWnkwF RR89PFAmxHVf5VusTGBSiiMke4h0zJ+nJt+eQVcWZyRTZqrsp5ktY98Zfgmm8lffwriQ hYMiV+PlYZu+pbQhobAeKZu3C4Abiyp3UuwsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=qxj6NFRMZCJ9C1Qj0MklV+ROB3X+oY+97MJ6aZpzBVGTsJCFeCV4wyY8Pc8+XtCtfQ a9KB8FGe2OnR3BRnwynPMm62pArYzRDaRxGwLV67klwWCI46lmfE5hvW2g4FQIKh9VfY GVpLSk57R/wbhgKTRMaiTiFeXovyagYUwDxjM= Received: by 10.220.129.73 with SMTP id n9mr54882vcs.51.1280408462056; Thu, 29 Jul 2010 06:01:02 -0700 (PDT) Received: from pc100 ([220.68.82.28]) by mx.google.com with ESMTPS id i17sm54368vcr.3.2010.07.29.06.00.57 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 06:00:58 -0700 (PDT) From: "Youn-Hee Han" To: Date: Thu, 29 Jul 2010 22:00:54 +0900 Message-ID: <4c517b8a.d179dc0a.0618.0217@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsuVYlAiGgeKDWZRpeVyDEEOJJ6RAAEroHQAC1urpA= Content-Language: ko Subject: [netext] FW: Needs of traffic spec. on MAG? 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: Thu, 29 Jul 2010 13:00:47 -0000 Dear Bernardos, > Dear Youn-Hee, >=20 > On Wed, 2010-07-28 at 21:43 +0900, Youn-Hee Han wrote: > > Dear Bernardos, > > > > > > > > I=E2=80=99d like to ask a question about > > =E2=80=9Cdraft-bernardos-netext-pmipv6-flowmob-00.=E2=80=9D > > > > In the call procedure figure, I noticed that traffic specification = is > > delivered to MAG from LMA. > > > > I understand that the specification should be managed at LMA to do a > > traffic filtering. > > > > > > > > However, is such a traffic filtering still needed at MAG? >=20 > The MAG needs to know the flow that is gonna be routed through it, so = it > can insert the required routing state. > For example, if the 5-tuple sent by LMA is <*, IP1, *, Port1, UDP>,=20 what does MAG's routing module do with the information?=20 The 5-tuple is only useful at LMA for the traffic filtering.=20 When receiving a packet from LMA, MAG will just check if the destination = IP=20 includes the home network prefix which the MAG manages for a registered = MN. > > > > IMHO, it is not needed at MAG. If so, why is the specification > > delivered to MAG? >=20 > This is something that can be discussed. The minimum info required is = the > MN's prefix of the moved flow, so the route is installed at the MAG. IMHO, the MN's prefix of the moved flow is necessary and sufficient = info.=20 > If finer control is required (e.g., prevent the MN send flows through = a > MAG that is not the one the LMA has setup flow mobility state, or = other > purposes), then the flow mobility (traffic selector, e.g., 5-tuple) = should > be delivered to the MAG. Yes. If we want to support any finer control for flow mobility, IMHO,=20 we need to distinguish downlink flow from uplink flow.=20 Any type of flow, e.g., VoIP flow, has different 5-tuples for downlink = and uplink. For a downlink flow, LMA can put its 5-tuple on its flow filtering = module at will.=20 For a uplink flow, however, I am not sure that LMA can also put its = 5-tuple on MAG (or MN) at will. I am not saying that the two (uplink and downlink) 5-tuples will be not = related. Somehow, they are mirrored by each other... Thanks, Youn-Hee Han From yh21.han@gmail.com Thu Jul 29 06:01:12 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 648F228C1E7 for ; Thu, 29 Jul 2010 06:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 FRY51wSgdSzm for ; Thu, 29 Jul 2010 06:01:11 -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 0962228C221 for ; Thu, 29 Jul 2010 06:01:11 -0700 (PDT) Received: by mail-px0-f172.google.com with SMTP id 20so94182pxi.31 for ; Thu, 29 Jul 2010 06:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=4j6LDPOS/tCdAiKVcdTSSXfzziJvEj5pwbbol1EK76E=; b=eYFnbzkBlW0sO7yXgyIjCG/al5oLm+tSDDJyulqD7D5N3g4FEgK0O4H4esWmYRA83c bWNw37x7GZ459uexLhVEMlZmd+WxKcZdDk88EwkbJULnebOO3ay1fekYKvD5Z0XHIvm6 kmdov04Y8CpI6skYcKyEuzmoimDOWbieUMZzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=X6Q27ky+0amMcFhXwPP1oUhc/myowwUGnSuoTCD4ZtqGOfdDYTEeRuo5IoR4XILX4G JcreGjwy0kVgfsdtaL+B2ApDmfZTguoS4Evo+1Wal5+BV3c6VXVHTdxTNdHWQlR/XbAt zFfSqcXPqKnBJKR7uTm/R0ZKtpxaprO/qeeik= Received: by 10.142.48.18 with SMTP id v18mr63105wfv.101.1280408493678; Thu, 29 Jul 2010 06:01:33 -0700 (PDT) Received: from pc100 ([220.68.82.28]) by mx.google.com with ESMTPS id 33sm1008705wfg.9.2010.07.29.06.01.31 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 06:01:32 -0700 (PDT) From: "Youn-Hee Han" To: Date: Thu, 29 Jul 2010 22:01:29 +0900 Message-ID: <4c517bac.21078e0a.0a2b.3776@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsub/BrXn5EUdMWQ0edv0PIv0g8AwAKhA8gACEG6rA= Content-Language: ko Subject: [netext] FW: Needs of traffic spec. on MAG? 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: Thu, 29 Jul 2010 13:01:12 -0000 Hello Carlos, > > > If finer control is required (e.g., prevent the MN send flows > > > through a MAG that is not the one the LMA has setup flow mobility > > > state, or other purposes), then the flow mobility (traffic = selector, > > > e.g., 5-tuple) should be delivered to the MAG. > > > > Yes. If we want to support any finer control for flow mobility, = IMHO, > > we need to distinguish downlink flow from uplink flow. > > Any type of flow, e.g., VoIP flow, has different 5-tuples for = downlink > and uplink. >=20 > different 5-tuple? why? it is just the same, but reversing source and > destination, right? >=20 > Anyway, 5-tuple is just one way of specifying the flow, more ways can = be > considered, to also support different flow granularities. >=20 According to draft-ietf-mext-binary-ts-04 which is mentioned as one of=20 traffic selector in your draft, source IP and destination IP (and source = port=20 and destination port) are clearly divided in individual fields of = option. Therefore, exactly speaking, the 5-tuple of downlink traffic is = different=20 from the one of uplink. Do you mean that when an MAG receives an FMI message including one traffic selector (i.e., one 5-tuple), MAG will reverse the source = and=20 destination IP & Port and store the reversed information to the MAG's = traffic=20 filter module? If not so, do you mean that the LMA itself sends the reversed = information to MAG? Otherwise, do you mean that the LMA sends to MAG two traffic selectors, = the original=20 and reversed ones? Thanks, Youn-Hee han From rkoodli@cisco.com Thu Jul 29 15:47:00 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 67A7E3A6814 for ; Thu, 29 Jul 2010 15:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.337 X-Spam-Level: X-Spam-Status: No, score=-10.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, 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 AyvoJ15KYdVY for ; Thu, 29 Jul 2010 15:46:58 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BC5BF3A67E5 for ; Thu, 29 Jul 2010 15:46:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADyiUUytJV2c/2dsb2JhbACgGXGlXpsAhTgEizc X-IronPort-AV: E=Sophos;i="4.55,283,1278288000"; d="scan'208";a="140994785" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 29 Jul 2010 22:47:20 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6TMlJXf012247; Thu, 29 Jul 2010 22:47:19 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jul 2010 18:45:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 18:45:36 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26661212E67F@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Needs of traffic spec. on MAG? Thread-Index: AcsuVYqvNYwXeQEjQWuQSA8okNNVJAAvjVLQABbApSc= References: <4c5025dc.1b768e0a.5695.6b00@mx.google.com><1280322397.4001.21.camel@acorde.it.uc3m.es> From: "Koodli, Rajeev" To: "Laganier, Julien" , , "Youn-Hee Han" X-OriginalArrivalTime: 29 Jul 2010 22:45:36.0259 (UTC) FILETIME=[C294AD30:01CB2F6F] Cc: netext@ietf.org Subject: Re: [netext] Needs of traffic spec. on MAG? 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: Thu, 29 Jul 2010 22:47:00 -0000 Single prefix on multiple MAGs is clearly one choice.=20 We agree that the prefix has to be valid on an interface for the = corresponding flow to traverse the MAG. If MAG1 has prefix p1 and MAG2 has p2, then the simplest form is p1 and = p2 are valid on both MAG1 and MAG2. However, I should also be able to assign p3 to MAG2 (for example), which = you can do today with RFC 5213.=20 The prefix p3 does not have to be simultaneously assigned to MAG1. This = should be continued to be allowed with the flow mobility support. -Rajeev -----Original Message----- From: netext-bounces@ietf.org on behalf of Laganier, Julien Sent: Thu 7/29/2010 4:49 AM To: cjbc@it.uc3m.es; Youn-Hee Han Cc: netext@ietf.org Subject: Re: [netext] Needs of traffic spec. on MAG? =20 Carlos Jes=FAs Bernardos Cano wrote: >=20 > Dear Youn-Hee, >=20 > On Wed, 2010-07-28 at 21:43 +0900, Youn-Hee Han wrote: > > Dear Bernardos, > > > > > > > > I'd like to ask a question about > > "draft-bernardos-netext-pmipv6-flowmob-00." > > > > In the call procedure figure, I noticed that traffic specification = is > > delivered to MAG from LMA. > > > > I understand that the specification should be managed at LMA to do a > > traffic filtering. > > > > > > > > However, is such a traffic filtering still needed at MAG? >=20 > The MAG needs to know the flow that is gonna be routed through it, so > it can insert the required routing state. If a single prefix is use across all of the MN accesses then there's no = need for this. > > IMHO, it is not needed at MAG. If so, why is the specification > > delivered to MAG? >=20 > This is something that can be discussed. The minimum info required is > the MN's prefix of the moved flow, so the route is installed at the = MAG. > If finer control is required (e.g., prevent the MN send flows through = a > MAG that is not the one the LMA has setup flow mobility state, or = other > purposes), then the flow mobility (traffic selector, e.g., 5-tuple) > should be delivered to the MAG. I don't think this is needed. > > Isn't sufficient that the home network prefix related to the traffic > > is delivered to MAG? >=20 > That'd be the minimum info. As mentioned before, the MAG may need the > whole flow definition, and in that case the LMA has to deliver that > information to the MAG. If a single prefix is use across all of the MN accesses then there's no = need to do this. --julien _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Fri Jul 30 13:43:07 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 76EB43A6805 for ; Fri, 30 Jul 2010 13:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 b389omFhrGTa for ; Fri, 30 Jul 2010 13:43:05 -0700 (PDT) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id 38E823A66B4 for ; Fri, 30 Jul 2010 13:43:05 -0700 (PDT) Received: (qmail 10228 invoked by uid 60001); 30 Jul 2010 20:43:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280522610; bh=7eHgLrUHxucAhRX8FqFqbaarw3mLWuDp082R3LBViZw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ja+nWpyT/sa4PfXO5W3DJNS1b31urLsdiNpSZm7ee/+N7xwSMFVMdcHFQb6+qK+iW4dXrTA8maUVDWxTwRGJIcfHCgSdRbAEMBhpOvo/+q1QU1v1pI1e/J1XSjyc19HRWkTkwdjiWpNJzugYv6zcSyIw1RDkfNfC723DsjJ9jKg= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qXM3COdG/WqgKA2j/LT3aqTGrSvgTGEFzlqu3xT5o8miWm6Gah8RdRyQm7wBJBrl2VcMI7yrHq4Nqwiw/4b1FCVmV8Jj3/QYXhlAJrG5yhdcsSH9KKvxfNL93HEDLBw7v/CUJvpNjX42gIZ3npNSOuUeLRcVNRUWpeiAsnp19/c=; Message-ID: <201906.10057.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: TQVgdVQVM1lJVn17Kaz_Z0Rg5sqWjTANfkecR3xRnNJULK8 AnWXYjdd11A5n7aq5UGjIyIaK8M_GoLhY4K7eCMt90bVV0V.iBHDMnnfdxYx bn4qFYCmC_ol54Odi7zcNPQsKgRFMr_fxD.VRQq07zLxtSzPrFAlkEkQV1Tw Zq34YuClrdfpAQKDEmY0TRjY14GmjCGhvYJsW9zPO.eS21sw9DbtNe97A2Le dLNH5gSoBnG9j.4MbOF54G6ggakRlJpZdcgn.YLDS83NPjHEtCDfbGifS2IS ORNBZ0ctFyh5trV3cpN7fm0Oe9JLo6rKwBPnBEMFyyp_o.3ytUdCMkuqmO4V bXVDBpGETfSsu Received: from [79.220.163.144] by web111410.mail.gq1.yahoo.com via HTTP; Fri, 30 Jul 2010 13:43:29 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <4c517b8a.d179dc0a.0618.0217@mx.google.com> Date: Fri, 30 Jul 2010 13:43:29 -0700 (PDT) From: Behcet Sarikaya To: Youn-Hee Han , netext@ietf.org In-Reply-To: <4c517b8a.d179dc0a.0618.0217@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] FW: Needs of traffic spec. on MAG? 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: Fri, 30 Jul 2010 20:43:07 -0000 Hi Youn-Hee,=0A =0A MAG might need the flow binding info simply because i= t would relay it to MN =0Apossibly using some L2 means.=0A=0AI don't unders= tand your concerns on this. This info needs to be sends =0Adownstream.=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: Yo= un-Hee Han =0A> To: netext@ietf.org=0A> Sent: Thu, July= 29, 2010 8:00:54 AM=0A> Subject: [netext] FW: Needs of traffic spec. on M= AG?=0A> =0A> Dear Bernardos,=0A> =0A> > Dear Youn-Hee,=0A> > =0A> > On Wed,= 2010-07-28 at 21:43 +0900, Youn-Hee Han wrote:=0A> > > Dear Bernardos,=0A= > > >=0A> > >=0A> > >=0A> > > I=E2=80=99d like to ask a question about=0A= > > > =E2=80=9Cdraft-bernardos-netext-pmipv6-flowmob-00.=E2=80=9D=0A> > >= =0A> > > In the call procedure figure, I noticed that traffic specificatio= n is=0A> > > delivered to MAG from LMA.=0A> > >=0A> > > I understand that = the specification should be managed at LMA to do a=0A> > > traffic filteri= ng.=0A> > >=0A> > >=0A> > >=0A> > > However, is such a traffic filtering s= till needed at MAG?=0A> > =0A> > The MAG needs to know the flow that is go= nna be routed through it, so it=0A> > can insert the required routing stat= e.=0A> >=0A> =0A> For example, if the 5-tuple sent by LMA is <*, IP1, *, P= ort1, UDP>, =0A> what does MAG's routing module do with the information? = =0A> The 5-tuple is only useful at LMA for the traffic filtering. =0A> Whe= n receiving a packet from LMA, MAG will just check if the destination IP = =0A> includes the home network prefix which the MAG manages for a register= ed MN.=0A> =0A> > >=0A> > > IMHO, it is not needed at MAG. If so, why is t= he specification=0A> > > delivered to MAG?=0A> > =0A> > This is something = that can be discussed. The minimum info required is the=0A> > MN's prefix = of the moved flow, so the route is installed at the MAG.=0A> =0A> IMHO, th= e MN's prefix of the moved flow is necessary and sufficient info. =0A> =0A= > > If finer control is required (e.g., prevent the MN send flows through = a=0A> > MAG that is not the one the LMA has setup flow mobility state, or = other=0A> > purposes), then the flow mobility (traffic selector, e.g., 5-t= uple) should=0A> > be delivered to the MAG.=0A> =0A> Yes. If we want to su= pport any finer control for flow mobility, IMHO, =0A> we need to distingui= sh downlink flow from uplink flow. =0A> Any type of flow, e.g., VoIP flow,= has different 5-tuples for downlink and =0A>uplink.=0A> For a downlink flo= w, LMA can put its 5-tuple on its flow filtering module at =0A>will. =0A>= =0A> For a uplink flow, however, I am not sure that LMA can also put its 5= -tuple on =0A>MAG (or MN) at will.=0A> =0A> I am not saying that the two (= uplink and downlink) 5-tuples will be not =0A>related.=0A> Somehow, they a= re mirrored by each other...=0A> =0A> Thanks,=0A> =0A> Youn-Hee Han=0A> = =0A> =0A> _______________________________________________=0A> netext mailin= g list=0A> netext@ietf.org=0A> https://www.ietf.org/mailman/listinfo/netex= t=0A> =0A=0A=0A From behcetsarikaya@yahoo.com Fri Jul 30 13:49: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 9D3043A68BC for ; Fri, 30 Jul 2010 13:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 CteiOuoODSxT for ; Fri, 30 Jul 2010 13:49:20 -0700 (PDT) Received: from web111412.mail.gq1.yahoo.com (web111412.mail.gq1.yahoo.com [67.195.15.198]) by core3.amsl.com (Postfix) with SMTP id BA24E3A6B27 for ; Fri, 30 Jul 2010 13:49:18 -0700 (PDT) Received: (qmail 10848 invoked by uid 60001); 30 Jul 2010 20:49:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280522980; bh=dkGTTMlQeKPI/CcKfhDJjfKAtLip6qbwJA+MZCBb1NI=; 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=rOjkrq+XbyE4dmlErzY0pRhbU2GXoXGVjth0DrSkqstKsNwO5T+Nnt1KAnq0xKp0useTnWtammK9kUc7DlLrQTQuu4F3/9QLUA4duhrgmnDwhSpt0sjqflUn+WVE0BQHUAeM1sx2L8TXpueJ2kDUpPAfBJbbDZrYwgG/K/wAkmQ= 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=lUcmG8mnLGmW1vqyrMCiEWIyCHulLuqQgawPMYrvEpwuFoHJ/ystjKcaYtGtQ2nY5pwhCrLEIEolPMdKF5PHINBY9Csn089py2s/BEGyvuVCIq29jnLozsfJefundpSAGmGY8JouuWEA/E2qjoNANvA2o0du1WSVLpWvoXZbel0=; Message-ID: <678089.10791.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: q3ZYlp8VM1n6KSIR2UMiaXMusycyRL3kSq.JhCCkdzibrTR u7NIzVwedl9.eNEyHtZV9kpGBXxEKK1phwxxqhGzhPtpY751r8HfMecnZbfw R7hOrgXL7GcrGHe_CtItxs4YQuzRHrNxxgrKLRhSk1vzje.j65tb6._e2PRb r7v0U1U2klboNrQ.xNafIbgB8VRsOVlmtkbbOjWxwptCbihe1LOlcIkmxXOc _F.YiYSHQkRjlqdr9LwpmpxXjQ7epxMv8f7v_q81caTR0I.ULbSZ5UbsgphB ZVS52k3uJQ4ibP600zMqyUGWr.Ft_dP5054_K.dFmBXeuqF5Nor289go9yLn FFGwX03XXTy8e Received: from [79.220.163.144] by web111412.mail.gq1.yahoo.com via HTTP; Fri, 30 Jul 2010 13:49:40 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <4c5025dc.1b768e0a.5695.6b00@mx.google.com> <1280322397.4001.21.camel@acorde.it.uc3m.es> <1280330301.4001.87.camel@acorde.it.uc3m.es> Date: Fri, 30 Jul 2010 13:49:40 -0700 (PDT) From: Behcet Sarikaya To: cjbc@it.uc3m.es In-Reply-To: <1280330301.4001.87.camel@acorde.it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] Needs of traffic spec. on MAG? 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: Fri, 30 Jul 2010 20:49:22 -0000 Hi Carlos,=0A=0A What I don't understand is why we are not reusing great w= ork already done in =0AMext WG? They defined Flow Identification Mobility O= ption. What is wrong in =0Areusing this option? Many things are similar in = PMIPv6.=0A Why try to reinvent the wheel? Remember that one of the design = decisions made =0Afor PMIPv6 was to reuse Mobile IPv6 as much as possible. = There are a lot of =0Asynergies we can get from such reuse. If you look a f= ew years back, attempts to =0Adefine totally new protocol for netlmm was no= t favored, PMIPv6 was selected =0Ainstead.=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A=0A----- Original Message ----=0A> From: Carlos Jes=C3=BAs Bernardos Can= o =0A> To: Youn-Hee Han =0A> Cc: netex= t@ietf.org=0A> Sent: Wed, July 28, 2010 10:18:21 AM=0A> Subject: Re: [netex= t] Needs of traffic spec. on MAG?=0A> =0A> One more comment. As I mentioned= in another e-mail to Julien,=0A> there might be the need of making the MA= G aware of the flow descriptions=0A> (traffic selector) in case the MN is = attached through different=0A> interfaces to the same MAG. In that case we= might need some support and=0A> signaling to make the MAG aware of the in= terface that should be used to=0A> deliver packets of this flow to the MN.= =0A> =0A> Opinions?=0A> =0A> Carlos=0A> =0A> On Wed, 2010-07-28 at 15:06 +0= 200, Carlos Jes=C3=BAs Bernardos Cano wrote:=0A> > Dear Youn-Hee,=0A> > = =0A> > On Wed, 2010-07-28 at 21:43 +0900, Youn-Hee Han wrote:=0A> > > Dear= Bernardos,=0A> > > =0A> > > =0A> > > =0A> > > I=E2=80=99d like to ask a= question about=0A> > > =E2=80=9Cdraft-bernardos-netext-pmipv6-flowmob-00.= =E2=80=9D=0A> > > =0A> > > In the call procedure figure, I noticed that tr= affic specification is=0A> > > delivered to MAG from LMA. =0A> > > =0A> > = > I understand that the specification should be managed at LMA to do a=0A>= > > traffic filtering. =0A> > > =0A> > > =0A> > > =0A> > > However, is su= ch a traffic filtering still needed at MAG?=0A> > =0A> > The MAG needs to = know the flow that is gonna be routed through it, so it=0A> > can insert t= he required routing state.=0A> > =0A> > > =0A> > > IMHO, it is not needed= at MAG. If so, why is the specification=0A> > > delivered to MAG?=0A> > = =0A> > This is something that can be discussed. The minimum info required = is=0A> > the MN's prefix of the moved flow, so the route is installed at t= he MAG.=0A> > If finer control is required (e.g., prevent the MN send flow= s through a=0A> > MAG that is not the one the LMA has setup flow mobility = state, or other=0A> > purposes), then the flow mobility (traffic selector, = e.g., 5-tuple)=0A> > should be delivered to the MAG.=0A> > =0A> > > =0A> >= > Isn=E2=80=99t sufficient that the home network prefix related to the tr= affic=0A> > > is delivered to MAG?=0A> > =0A> > That'd be the minimum info= . As mentioned before, the MAG may need the=0A> > whole flow definition, a= nd in that case the LMA has to deliver that=0A> > information to the MAG.= =0A> > =0A> > Thanks,=0A> > =0A> > Carlos=0A> > =0A> > > =0A> > > =0A> > >= =0A> > > Youn-Hee Han=0A> > > =0A> > > =0A> > > =0A> > > =0A> > > ______= _________________________________________=0A> > > netext mailing list=0A> = > > netext@ietf.org=0A> > > https://www.ietf.org/mailman/listinfo/netext=0A= > > =0A> > _______________________________________________=0A> > netext ma= iling list=0A> > netext@ietf.org=0A> > https://www.ietf.org/mailman/listin= fo/netext=0A> =0A> -- =0A> Carlos Jes=C3=BAs Bernardos Cano http://www= .netcoms.net=0A> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F6= 7=0A> =0A=0A=0A