From mip4-bounces@ietf.org Sun Jan 4 17:01:04 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6103A681F; Sun, 4 Jan 2009 17:01:04 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8FE3A681F for ; Sun, 4 Jan 2009 17:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.643 X-Spam-Level: X-Spam-Status: No, score=0.643 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 xdVfggSyCuWI for ; Sun, 4 Jan 2009 17:01:02 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 478DE3A67B3 for ; Sun, 4 Jan 2009 17:01:02 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id n0510eGH008921; Mon, 5 Jan 2009 10:00:40 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id n0510ea04085; Mon, 5 Jan 2009 10:00:40 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili01) with ESMTP id n0510cW06278; Mon, 5 Jan 2009 10:00:38 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jan 2009 09:00:01 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD031134A1@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments for draft-gundavelli-mip4-multiple-tunnel-support-00.txt Thread-Index: Aclu0OxowtRXwbNVQu+fL2LcQ+8IOg== From: "Mohana Jeyatharan" To: "Sri Gundavelli" Cc: mip4@ietf.org Subject: [Mip4] Comments for draft-gundavelli-mip4-multiple-tunnel-support-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Sri, I read your draft Multiple Tunnel Support for Mobile IPv4. I think it is a very useful draft since multihoming is essential in any mobility protocol. This is an interesting work in MIPv4 but nevertheless, I have some questions. In page[4], only bulk re-registration is defined. Furthermore, in the draft bulk registration is not supported. Is there any reason for this? Or do you plan to have bulk registration support in future revisions. MONAMI6 MCoA draft has support for bulk registration and why is this not supported in your draft? Figure 1 in page 5 shows multiple interfaced MN making simultaneous attachment with and without using FA. Is the assumption such that the MN uses co-located care-of address when there is no FA present and uses FA care-of address when there is a FA present? Just a clarification question... It is mentioned in page 5 that the MIPv4 multiple CoA support informs the HA the type of interface and capacity and so on. What is the need for this? Current Monami6 MCoA draft which handles multiple CoA registration does not have this information. Do you think this information is useful for the network to set flow polices? It leads me to another question that in any case, the available capacity in the access network can be monitored by the network entities and informed to HA and why should the MN send these information? The term "throughput capacity" in page 5 is not very clear. Is it the used bandwidth per MN or the available spare bandwidth? I think it would be better if more clarity is given to this term. My understanding is the spare bandwidth. If it is the spare bandwidth then again, another question is how the MN gets such information. This is very much access technology specific. A small typo in page 5, "The throughput capacity of each of these tunnels is dependent on the access technology over which the mobile node is attached. The mobile node notifies the interface properties for each attached interface and the home agent can user this as a metric for it traffic policies." the home agent can use this as a metric for it.... In page 7 the length field is mentioned to have length 6 octets. Is it 10 octets or 6 octets? BID was defined in terminology section and it is again repeated in page 7. Possibly, such double definition can be removed. Again, it is mentioned in page 7 that the BID can be an interface index assigned by the operating system. Is this a preferred way of creating BID and moreover if there are multiple BIDs per interface then what is the way of generating the BIDs. In that case, it should not be tied to interface...Correct me if I am wrong. It is mentioned in page 7, that in deregistration request, the 'O' flag must be set to 0. What is the reason for this? My understanding is that deregistration has a special trigger to remove the bindings and what is the reason for such setting of the 'O' flag. In mobile node operation section, the first two bullets mentions about MN returning home. It is not very clear the methods disclosed in the first two bullets. Is there any difference between the first two bullets. Perhaps more clarity in the text is useful. Also, it is mentioned that simultaneously at home and away is not supported in section 5.1. Again is there any reason and do you plan to incorporate this simultaneously at home and away in the future revision. I think this scenario is essential considering some deployments in 3GPP. Even in the home network domain, such a scenario can exist due to different mobility management mechanisms to handle different interfaces. In "mobile node in foreign network" section in page 9, the first bullet is a "SHOULD". Why is this so? If the mobile node cannot see home prefix then it is in foreign link. Then it is a MUST. Am I right to say that? What is the reason for this configuration parameter "Enable Multiple Tunnel Support". Is it a static variable or dynamic. In page 9, there is a small typo error it should be "sought for". o If the value of the configuration variable, EnableMultipleTunnelSupport is set to a value of 1, then the mobile node SHOULD register a care-of address for each of those interfaces, by sending a Registration Request. Each of the requests sent MUST contain the care-of address of the respective interface and the Multiple Tunnel Request extension reflecting the interface properties. The mobile node MUST ensure that the Registration Request is routed through the specific interface for which the registration is sough for. In page 9, in one before the last bullet it says that the MN 'SHOULD" create a tunnel. I thought once it receives a positive ack, it MUST create a tunnel. In section 5.2 it is mentioned that the FA "should" check the configuration variable. I think it should be MUST because it has a Enable MultipleSupport variable enabled. In section 5.2 it is mentioned that a MN connected to a single FA using multiple interfaces. Is there a single tunnel for both interfaces or multiple tunnels? Moreover, it is better to introduce this scenario once supported configuration section is described. This is just a simple suggestion. In section 5.3 in HA operation, it is mentioned that MIPv4 RFC already has multiple bindings support. It is not very clear from the text how that is different from this multiple CoA address support disclosed in this draft. Perhaps it is better to clearly distinguish the difference. Sorry I haven't read the MIPv4 RFC in detail and was not very clear.... There is no clear differentiation between figure 4 and figure 5. What is the difference? How is the registration done? It would be beneficial to show how the multiple CoA support is achieved in such scenarios. This is a useful scenario and is used in some SDOs. For example in Figure 4, it seems single tunnel, so will the FA send all interface parameters in a single registration and so on needs to be explained. This will be useful for deployments. These are some of my comments. Thanks. BR, Mohana -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 5 02:40:18 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15903A690B; Mon, 5 Jan 2009 02:40:17 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F25C3A689E for ; Mon, 5 Jan 2009 02:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=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 7kAk6K4GfOeM for ; Mon, 5 Jan 2009 02:38:03 -0800 (PST) Received: from fermi.ina.uni-kassel.de (fermi.ina.uni-kassel.de [141.51.200.5]) by core3.amsl.com (Postfix) with ESMTP id 0054C3A6887 for ; Mon, 5 Jan 2009 02:38:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fermi.ina.uni-kassel.de (Postfix) with ESMTP id 606073A804E for ; Mon, 5 Jan 2009 11:37:49 +0100 (CET) X-Virus-Scanned: amavisd-new at ina.uni-kassel.de Received: from fermi.ina.uni-kassel.de ([127.0.0.1]) by localhost (fermi.ina.uni-kassel.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVJyC28CzRKg for ; Mon, 5 Jan 2009 11:37:49 +0100 (CET) Received: from tel-pc8.ina.uni-kassel.de (tel-pc8.ina.uni-kassel.de [141.51.200.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by fermi.ina.uni-kassel.de (Postfix) with ESMTP id 24EDB3A804D for ; Mon, 5 Jan 2009 11:37:49 +0100 (CET) From: Hubert Krause Organization: =?iso-8859-1?q?Universit=E4t?= Kassel, Technische Elektronik User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 5 Jan 2009 11:37:48 +0100 To: mip4@ietf.org Message-Id: <200901051137.48951.hubert.krause@ina.uni-kassel.de> Subject: [Mip4] Call For Papers INSS 2009 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org W091ciBhcG9sb2dpZXMgaWYgeW91IHJlY2VpdmUgbXVsdGlwbGUgcG9zdGluZ3Mgb2YgdGhpcyBD RlBdCgpQYXBlciBTdWJtaXNzaW9ucyBEdWU6IEphbnVhcnkgOXRoLCAyMDA5CgoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqCkNhbGwgRm9yIFBhcGVycwoKU2l4dGggSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9uIE5l dHdvcmtlZCBTZW5zaW5nIFN5c3RlbXMgKElOU1MgMjAwOSkKCmh0dHA6Ly93d3cuaW5zcy1jb25m Lm9yZy8yMDA5LwoKSnVuZSAxNyAtIDE5LCAyMDA5CkNhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5 LCBQaXR0c2J1cmdoLCBVU0EKCgpTcG9uc29yOiBUcmFuc2R1Y2VyIFJlc2VhcmNoIEZvdW5kYXRp b24KVGVjaG5pY2FsIFNwb25zb3I6IElFRUUKCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKCkR1cmluZyB0aGUgcGFz dCB5ZWFycywgdGhlIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBOZXR3b3JrZWQKU2Vuc2lu ZyBTeXN0ZW1zIChJTlNTKSBoYXMgZXN0YWJsaXNoZWQgaXRzZWxmIGFzIFRIRSBzY2llbnRpZmlj CmV2ZW50IHdoZXJlIGFjYWRlbWljIGFuZCBpbmR1c3RyaWFsIGV4cGVydHMgZnJvbSB0aGUgYXJl YXMgb2Ygc2Vuc29yCnN5c3RlbXMsIHdpcmVsZXNzIG5ldHdvcmtzLCBhbmQgc2Vuc29yIG5ldHdv cmsgYXBwbGljYXRpb25zIGNvbWUKdG9nZXRoZXIuIFRoZSBJTlNTIHByb3ZpZGVzIGEgZm9ydW0g dG8gaGVhciBhYm91dCB0aGUgbGF0ZXN0CmRldmVsb3BtZW50cyBpbiB0aGVzZSBhcmVhcywgdG8g ZXhjaGFuZ2UgaWRlYXMsIGFuZCB0byBzdGFydCB1cApjb2xsYWJvcmF0aW9ucyB3aXRoaW4gdGhl c2UgZmllbGRzIGFuZCBiZXR3ZWVuIGluZHVzdHJ5IGFuZAphY2FkZW1pYS4KCkNhbGwgZm9yIFNj aWVudGlmaWMgQ29udHJpYnV0aW9ucwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K SU5TUyAyMDA5IGlzIHRoZSBzaXh0aCBhbm51YWwgY29uZmVyZW5jZSBpbiB0aGUgc2VyaWVzLCBh bmQgZmVhdHVyZXMKYSBoaWdobHkgc2VsZWN0aXZlIHRlY2huaWNhbCBwcm9ncmFtLiBXZSBpbnZp dGUgb3V0c3RhbmRpbmcgcmVzZWFyY2gKcGFwZXJzIGZyb20gdGhlIGZpZWxkIG9mIHNlbnNvciB0 ZWNobm9sb2d5LCB3aXJlbGVzcyBuZXR3b3JraW5nLCBvcgphcHBsaWNhdGlvbiBvZiBuZXR3b3Jr ZWQgc2Vuc29yIHN5c3RlbXMuIFRoZSBjb25mZXJlbmNlIGVzcGVjaWFsbHkKZW5jb3VyYWdlcyBz dWJtaXNzaW9ucyB0aGF0IGludmVzdGlnYXRlIHJlc2VhcmNoIGlzc3VlcyBzaGFyZWQKYmV0d2Vl biBhbGwgdGhyZWUgYXJlYXMuCgpJTlNTIDIwMDkgaW52aXRlcyB0aGUgc3VibWlzc2lvbiBvZiBy ZWd1bGFyLCBzaG9ydCwgYW5kIGluZHVzdHJ5CnBhcGVycy4gQWxsIHN1Ym1pc3Npb25zIHdpbGwg YmUgcGVlci1yZXZpZXdlZCBhbmQgZXZhbHVhdGVkIG9uIHRoZQpiYXNpcyBvZiBvcmlnaW5hbGl0 eSwgc2lnbmlmaWNhbmNlIG9mIGNvbnRyaWJ1dGlvbiwgdGVjaG5pY2FsCmNvcnJlY3RuZXNzLCBh bmQgcHJlc2VudGF0aW9uLiBQYXBlcnMgc3VibWl0dGVkIG11c3Qgbm90IGJlIHVuZGVyCnNpbXVs dGFuZW91cyByZXZpZXcgZm9yIGFueSBvdGhlciBjb25mZXJlbmNlLCBqb3VybmFsLCB3b3Jrc2hv cCwgb3IKb3RoZXIgcHVibGljYXRpb24uIEFsbCBhY2NlcHRlZCBwYXBlcnMgd2lsbCBiZSBwdWJs aXNoZWQgZnJvbSB0aGUKU29jaWV0eSBvZiBJbnN0cnVtZW50IGFuZCBDb250cm9sIEVuZ2luZWVy cyAoU0lDRSksIGFuZCBhbHNvIGZyb20KSUVFRSBFeHBsb3JlLgoKClJlZ3VsYXIvU2hvcnQgUGFw ZXIgVHJhY2sKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClJlZ3VsYXIgcGFwZXJz IG11c3QgYmUgNC04IHBhZ2VzIGxvbmcgKHR3by1jb2x1bW4gZm9ybWF0KSBhbmQKaW5jbHVkZSBh biBhYnN0cmFjdCBvZiAxMDAtMTUwIHdvcmRzLiBTaG9ydCBwYXBlcnMgbXVzdCBiZSAyLTQgcGFn ZXMKbG9uZyAodHdvLWNvbHVtbiBmb3JtYXQpIGFuZCBpbmNsdWRlIGFuIGFic3RyYWN0IG9mIDEw MC0xNTAgd29yZHMuCkFsbCBwYXBlcnMgc2hvdWxkIGJlIGZvcm1hdHRlZCBhY2NvcmRpbmcgdG8g dGhlICJJRUVFIHRyYW5zYWN0aW9ucyIKZm9ybWF0LiBTaG9ydCBwYXBlcnMgYXJlIHN1aXRhYmxl IGZvciBpbnRlcmFjdGl2ZSBkaXNjdXNzaW9uczsgdGhlCnByZXNlbnRlcnMgb2YgYWNjZXB0ZWQg c2hvcnQgcGFwZXJzIGFyZSBnaXZlbiBzaG9ydCBvcmFsCnByZXNlbnRhdGlvbiB0aW1lcy4gVG9w aWNzIG9mIHJlZ3VsYXIgcGFwZXIgdHJhY2sgaW5jbHVkZSBidXQgYXJlCm5vdCBsaW1pdGVkIHRv OgoKKiBBcHBsaWNhdGlvbnMgb2YgTmV0d29ya2VkIFNlbnNpbmcgU3lzdGVtcwoqIFByb3RvdHlw ZXMsIEZpZWxkIFN0dWRpZXMgJiBUZXN0YmVkcyBmb3IgTmV0d29ya2VkIFNlbnNpbmcgU3lzdGVt cwoqIFNhZmV0eSBhbmQgU2VjdXJpdHkgb2YgTmV0d29ya2VkIFNlbnNpbmcgU3lzdGVtcwoqIERh dGEgTWFuYWdlbWVudCBmb3IgTmV0d29ya2VkIFNlbnNpbmcgU3lzdGVtcwoqIE1pZGRsZXdhcmUg Zm9yIE5ldHdvcmtlZCBTZW5zaW5nIFN5c3RlbXMKKiBDb21tdW5pY2F0aW9uIFByb3RvY29scwoq IFNlbnNvciBQaGVub21lbmEgYW5kIE1vZGVsaW5nCiogU2Vuc29ycyBhbmQgU2Vuc2luZyBTeXN0 ZW1zCiogTWF0ZXJpYWxzLCBGYWJyaWNhdGlvbiwgYW5kIFBhY2thZ2luZyBvZiBTZW5zb3JzCgoK SW5kdXN0cnkgUGFwZXIgVHJhY2sKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpJ TlNTIDIwMDkgY29udGludWVzIHRoZSBpbmR1c3RyeSB0cmFjay4gRXhwZXJ0cyBmcm9tIGluZHVz dHJ5IGFyZQplbmNvdXJhZ2VkIHRvIHB1Ymxpc2ggdGhlaXIgd29yayBhdCBJTlNTIDIwMDkgYW5k IHRvIGhhdmUgYSBsaXZlbHkKZXhjaGFuZ2Ugb2YgdGhlaXIgZXhwZXJpZW5jZXMgd2l0aCBjb25m ZXJlbmNlIGF0dGVuZGVlcy4gwqBJbmR1c3RyeQpwYXBlcnMgYXJlIHN1aXRhYmxlIGZvciBpbmR1 c3RyeSByZXNlYXJjaGVycyB0byBwcmVzZW50IG5vdCBvbmx5CnRlY2huaWNhbCwgYnV0IGFsc28g cHJhY3RpY2FsIGlzc3VlcyBzdXJyb3VuZGluZyBwcm9kdWN0aW9uLApkZXBsb3ltZW50LCBhbmQg Y29tbWVyY2lhbGl6YXRpb24gb2YgbmV0d29ya2VkIHNlbnNpbmcgdGVjaG5vbG9neS4KSW5kdXN0 cnkgcGFwZXJzIG11c3QgYmUgMi00IHBhZ2VzIGxvbmcgKHR3by1jb2x1bW4gZm9ybWF0KSBhbmQg aW5jbHVkZQphbiBhYnN0cmFjdCBvZiAxMDAtMTUwIHdvcmRzLiBBbGwgcGFwZXJzIHNob3VsZCBi ZSBmb3JtYXR0ZWQgYWNjb3JkaW5nCnRvIHRoZSAiSUVFRSB0cmFuc2FjdGlvbnMiIGZvcm1hdC4g VGhlIHN1Ym1pdHRlZCBpbmR1c3RyeSBwYXBlcnMgd2lsbApiZSByZXZpZXdlZCBieSBpbmR1c3Ry eSB0cmFjayBUUEMgbWVtYmVycy4gQWNjZXB0ZWQgaW5kdXN0cnkgcGFwZXJzCndpbGwgYmUgcHJl c2VudGVkIGluIHRoZSBtYWluIGNvbmZlcmVuY2UncyBpbmR1c3RyeSB0cmFjayBzZXNzaW9uCmdp dmVuIGZ1bGwgb3JhbCBwcmVzZW50YXRpb24gdGltZXMuIFRoZSBpbmR1c3RyeSB0cmFjayBhaW1z IGF0CnByb3ZpZGluZyBhIGZvcnVtIGFtb25nIHByYWN0aXRpb25lcnMsIGRldmVsb3BlcnMsIGFu ZCByZXNlYXJjaGVycyB0bwpkaXNjdXNzIHByYWN0aWNhbCBpc3N1ZXMgaW5jbHVkaW5nIGJ1dCBu b3QgbGltaXRlZCB0bzoKCiogRGVzaWduaW5nIG5ldHdvcmtlZCBzZW5zaW5nIHN5c3RlbXMgZm9y IGNvbW1lcmNpYWwgYXBwbGljYXRpb25zCiogU2VydmljZSBtb2RlbHMgYW5kIGFyY2hpdGVjdHVy ZXMgZm9yIHN1Y2Nlc3NmdWwgZGVwbG95bWVudHMKKiBQcm9kdWN0aW9uIGVuZ2luZWVyaW5nIGZv ciBuZXR3b3JrZWQgc2Vuc2luZyBzeXN0ZW1zIEV2YWx1YXRpb24gb2YKKiBOZXR3b3JrZWQgc2Vu c2luZyBzeXN0ZW1zIGluIHByYWN0aWNhbCBhcHBsaWNhdGlvbnMKCkltcG9ydGFudCBEYXRlcwot LS0tLS0tLS0tLS0tLS0KClBhcGVyIFJlZ2lzdHJhdGlvbnMgRHVlOiBKYW51YXJ5IDl0aCwgMjAw OSAoSU1QT1JUQU5UISkKUGFwZXIgVXBsb2FkIER1ZTogSmFudWFyeSA5dGgsIDIwMDkKTm90aWZp Y2F0aW9uIG9mIEFjY2VwdGFuY2U6IEFwcmlsIDFzdCwgMjAwOQpDYW1lcmEtUmVhZHkgUGFwZXJz OiBBcHJpbCAxN3RoLCAyMDA5CkNvbmZlcmVuY2UgRGF0ZXM6IEp1bmUgMTcgLSAxOSwgMjAwOQoK SW1wb3J0YW50IERhdGVzIGZvciBJbmR1c3RyeSBUcmFjawotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KClBhcGVyIFN1Ym1pc3Npb25zIER1ZTogSmFudWFyeSAxNywgMjAwOQpO b3RpZmljYXRpb24gb2YgQWNjZXB0YW5jZTogQXByaWwgMXN0LCAyMDA5CkNhbWVyYS1SZWFkeSBQ YXBlcnM6IEFwcmlsIDE3dGgsIDIwMDkKCgpPcmdhbml6YXRpb24KLS0tLS0tLS0tLS0tCkdlbmVy YWwgQ28tY2hhaXJzOgpSYWogUmFqa3VtYXIsIENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5LCBV U0EKSGlkZSBUb2t1ZGEsIEtlaW8gVW5pdmVyc2l0eSwgSmFwYW4KClByb2dyYW0gQ28tQ2hhaXJz OgpUaWFuIEhlLCBVbml2ZXJzaXR5IG9mIE1pbm5lc290YSwgVVNBClRhbWFsIE11a2hlcmplZSwg Q2FybmVnaWUgTWVsbG9uIFVuaXZlcnNpdHksIFVTQQoKUHJvZ3JhbSBWaWNlLWNoYWlyczoKSGlk ZWthdGEgSG9udGFuaSwgTmFnb3lhIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5LCBKYXBhbgpDaHJp c3RpYW4gRGVja2VyLCBVbml2ZXJzaXR5IG9mIEthcmxzcnVoZSwgR2VybWFueQoKUHVibGljaXR5 IENoYWlyczoKUmFodWwgTWFuZ2hhcmFtLCBVbml2ZXJzaXR5IG9mIFBlbm5zeWx2YW5pYSwgVVNB Ckhpcm95dWtpIFNoaW5vZGEsIFVuaXZlcnNpdHkgb2YgVG9reW8sIEphcGFuCkhhcnRtdXQgSGls bG1lciwgVW5pdmVyc2l0YXQgS2Fzc2VsLCBHZXJtYW55CgpJbmR1c3RyeSBUcmFjayBQcm9ncmFt IENoYWlyczoKRGFycmluIFlvdW5nLCBDYXNlIFdlc3Rlcm4gUmVzZXJ2ZSBVbml2ZXJzaXR5LCBV U0EKTmFyaXRvIEt1cmF0YSwgS2FqaW1hLCBKYXBhbgpQZXRlciBCb2RhLCBOb2tpYSBSZXNlYXJj aCBDZW50ZXIgUGFsbyBBbHRvLCBVU0EKClB1YmxpY2F0aW9uIENoYWlyClJhenZhbiBCZXVyYW4s IE5JQ1QsIEphcGFuCgpQcm9ncmFtIENvbW1pdHRlZToKVGFyZWsgQWJkZWx6YWhlciwgVW5pdmVy c2l0eSBvZiBJbGxpbm9pcywgVXJiYW5hIENoYW1wYWlnbiwgVVNBCk1pY2hhZWwgQmVpZ2wsIFRV IEJyYXVuc2Nod2VpZywgR2VybWFueQpKYW4gQmV1dGVsLCBFVEggWnVyaWNoLCBTd2l0emVybGFu ZApTcmRqYW4gQ2Fwa3VuLCBFVEggWnVyaWNoLCBTd2l0emVybGFuZApBcmphbiBEdXJyZXNpLCBM b3Vpc2lhbmEgU3RhdGUgVW5pdmVyc2l0eSwgVVNBClN0ZXZlbiBHYXJ2ZXJpY2ssIENhc2UgV2Vz dGVybiBSZXNlcnZlIFVuaXZlcnNpdHksIFVTQQpMaW4gR3UsIEhvbmcgS29uZyBVbml2ZXJzaXR5 IG9mIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3kKSGFydG11dCBIaWxsbWVyLCBVbml2ZXJzaXR5IG9m IEthc3NlbCwgR2VybWFueQpTYXRvc2hpIEhvbmRhLCBLZWlvIFVuaXZlcnNpdHksIEphcGFuCkhp ZGVrYXRhIEhvbnRhbmksIE5hZ295YSBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neSwgSmFwYW4KSGlk ZXRvIEl3YW9rYSwgS2FuYXphd2EgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3ksIEphcGFuCllvc2hp aGlybyBLYXdhaGFyYSwgVGhlIFVuaXZlcnNpdHkgb2YgVG9reW8sIEphcGFuCkhpZGV5dWtpIEth d2FzaGltYSwgVW5pdmVyc2l0eSBvZiBUc3VrdWJhLCBKYXBhbgpEYWV5b3VuZyBLaW0sIEluZm9y bWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBVbml2ZXJzaXR5LCBLb3JlYQpTYXRvc2hpIEt1cmlo YXJhLCBPc2FrYSBVbml2ZXJzaXR5LCBKYXBhbgpNYXJjIExhbmdoZWlucmljaCwgRVRIIFp1cmlj aCwgU3dpdHplcmxhbmQKSHl1bnlvdW5nIExlZSwgVW5pdmVyc2l0eSBvZiBEZW52ZXIsIFVTQQpZ b25naGUgTGl1LCBVVCBBcmxpbmd0b24sIFVTQQpQZWRybyBKb3NlIE1hcnJvbiwgVW5pdmVyc2l0 eSBvZiBCb25uLCBHZXJtYW55Ck1hc2F0ZXJ1IE1pbmFtaSwgVW5pdmVyc2l0eSBvZiBUb2t5bywg SmFwYW4KSmluIE5ha2F6YXdhLCBLZWlvIFVuaXZlcnNpdHksIEphcGFuCkFkcmlhbiBQZXJyaWcs IENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5LCBVU0EKTWFyY2VsbyBQaWFzLCBDYW1icmlkZ2Ug VW5pdmVyc2l0eSwgVUsKS2F5IFJvZW1lciwgRVRIIFp1cmljaCwgU3dpdHplcmxhbmQKU2lsdmlh IFNhbnRpbmksIEVUSCBadXJpY2gsIFN3aXR6ZXJsYW5kClNoaXZha3VtYXIgU2FzdHJ5LCBUaGUg VW5pdmVyc2l0eSBvZiBBa3JvbiwgVVNBCkpvY2hlbiBTY2hpbGxlciwgRlUgQmVybGluLCBHZXJt YW55Ckhpcm95dWtpIFNoaW5vZGEsIFVuaXZlcnNpdHkgb2YgVG9reW8sIEphcGFuClNhbmcgU29u LCBVbml2ZXJzaXR5IG9mIFZpcmdpbmlhLCBVU0EKTml3YXQgVGhlcHZpbG9qYW5hcG9uZywgVG9r eW8gRGVua2kgVW5pdmVyc2l0eSwgSmFwYW4KWW9zaGl0byBUb2JlLCBUb2t5byBEZW5raSBVbml2 ZXJzaXR5LCBKYXBhbgpLcmlzdG9mIFZhbiBMYWVyaG92ZW4sIFRVIERhcm1zdGFkdCwgR2VybWFu eQpEYW4gV2FuZywgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVuaXZlcnNpdHksIEhvbmcgS29uZwpM YW4gV2FuZywgVW5pdmVyc2l0eSBvZiBNZW1waGlzLCBVU0EKS2FtaW4gV2hpdGVob3VzZSwgVW5p dmVyc2l0eSBvZiBWaXJnaW5pYSwgVVNBCkhvbmd5aSBXdSBVbml2ZXJzaXR5IG9mIExvdWlzaWFu YSBhdCBMYWZheWV0dGUsVVNBCkJpbiBYaWFvLCBIb25nIEtvbmcgUG9seXRlY2huaWMgVW5pdmVy c2l0eSwgSG9uZyBLb25nCkFuZHJldyBZZWgsIE5hdGlvbmFsIFRzaW5nIEh1YSBVbml2ZXJzaXR5 LCBUYWl3YW4KRGFycmluIFlvdW5nLCBDYXNlIFdlc3Rlcm4gUmVzZXJ2ZSBVbml2ZXJzaXR5LCBV U0EKWmhpLUxpIFpoYW5nLCBVbml2ZXJzaXR5IG9mIE1pbm5lc290YSwgVVNBCkdhbmcgWmhvdSwg Q29sbGVnZSBvZiBXaWxsaWFtIGFuZCBNYXJ5LFVTQQotLQpNaXA0IG1haWxpbmcgbGlzdDogTWlw NEBpZXRmLm9yZwogICAgV2ViIGludGVyZmFjZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9taXA0CiAgICAgQ2hhcnRlciBwYWdlOiBodHRwOi8vd3d3LmlldGYub3JnL2h0 bWwuY2hhcnRlcnMvbWlwNC1jaGFydGVyLmh0bWwKU3VwcGxlbWVudGFsIHNpdGU6IGh0dHA6Ly93 d3cubWlwNC5vcmcvCg== From mip4-bounces@ietf.org Mon Jan 5 15:14:36 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A720F3A6A22; Mon, 5 Jan 2009 15:14:36 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EDE93A6A22 for ; Mon, 5 Jan 2009 15:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 DjP89CkwXFx7 for ; Mon, 5 Jan 2009 15:14:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D6BC83A69B0 for ; Mon, 5 Jan 2009 15:14:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,334,1228089600"; d="scan'208";a="125101920" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 05 Jan 2009 23:14:08 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n05NE8Wl031801; Mon, 5 Jan 2009 15:14:08 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n05NE7xQ026542; Mon, 5 Jan 2009 23:14:08 GMT Date: Mon, 5 Jan 2009 15:14:07 -0800 (PST) From: Sri Gundavelli To: Mohana Jeyatharan In-Reply-To: <5F09D220B62F79418461A978CA0921BD031134A1@pslexc01.psl.local> Message-ID: References: <5F09D220B62F79418461A978CA0921BD031134A1@pslexc01.psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8630; t=1231197248; x=1232061248; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20Comments=20for=20draft-gundavelli-mip4- multiple-tunnel-support-00.txt |Sender:=20; bh=VFn3Tb9QdQabsa2B2MaNN/Lmu/fngRrPk25bFXW7XvA=; b=fq0Z7HfQ2tvuY/zsFdH2mSgMqFybnBqZjMdgJ8uNF4DXKQbQiWGL7QqQIe 9UGxloP1xI/G7dz/JTAjUSOHLZDD31hbUNWttRe1E15mFVM8OpsF9UI9nuhz QIkXxJ8uXM; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mip4@ietf.org Subject: Re: [Mip4] Comments for draft-gundavelli-mip4-multiple-tunnel-support-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Mohana, Thanks for the review. Please see inline. On Mon, 5 Jan 2009, Mohana Jeyatharan wrote: > Hi Sri, > > I read your draft Multiple Tunnel Support for Mobile IPv4. > I think it is a very useful draft since multihoming is essential in any > mobility protocol. > > This is an interesting work in MIPv4 but nevertheless, I have some > questions. > > In page[4], only bulk re-registration is defined. Furthermore, in the > draft bulk registration is not supported. Is there any reason for this? > Or do you plan to have bulk registration support in future revisions. > MONAMI6 MCoA draft has support for bulk registration and why is this > not supported in your draft? > Support for bulk registration is within the scope of re-registration. We want the registration message for a given CoA to be sent through the same access network to which the given interface is attached. This will ensure, it will work even in the presence of NAT and when supporting RFC-3519. If we allow this for initial registration, that request will go through only one specific path, which we dont want. So, the spec allows bulk reg only for reregs, when nothing changes on the MN. > > > Figure 1 in page 5 shows multiple interfaced MN making simultaneous > attachment with and without using FA. Is the assumption such that the MN > uses co-located care-of address when there is no FA present and uses FA > care-of address when there is a FA present? Just a clarification > question... > > > > It is mentioned in page 5 that the MIPv4 multiple CoA support informs > the HA the type of interface and capacity and so on. What is the need > for this? Current Monami6 MCoA draft which handles multiple CoA > registration does not have this information. Do you think this > information is useful for the network to set flow polices? It leads me > to another question that in any case, the available capacity in the > access network can be monitored by the network entities and informed to > HA and why should the MN send these information? > Access type is an important parameter for enabling any traffic policies. The home agent cannot always monitor the characterstics of the access network, specially in a unmanaged network, or for client-based mobility. In the mobile router deployments for which this is more useful, the home network will have no clue about access networks to which the mobile router is attached. Registering the access type, will provide the link characterstics to the home network. It knows about each of tunnel paths and how it is tied to the air link on the mobile. > > > The term "throughput capacity" in page 5 is not very clear. Is it the > used bandwidth per MN or the available spare bandwidth? I think it would > be better if more clarity is given to this term. My understanding is the > spare bandwidth. If it is the spare bandwidth then again, another > question is how the MN gets such information. This is very much access > technology specific. > Ok. Will clarify this. > > > A small typo in page 5, > "The throughput capacity of each of these tunnels is dependent on > the access technology over which the mobile node is attached. The > mobile node notifies the interface properties for each attached > interface and the home agent can user this as a metric for it > traffic policies." > the home agent can use this as a metric for it.... > Ok. > > In page 7 the length field is mentioned to have length 6 octets. Is it > 10 octets or 6 octets? > > Thanks. It should be 10, excluding Type and Length fields. > > BID was defined in terminology section and it is again repeated in page > 7. Possibly, such double definition can be removed. Again, it is > mentioned in page 7 that the BID can be an interface index assigned by > the operating system. Is this a preferred way of creating BID and > moreover if there are multiple BIDs per interface then what is the way > of generating the BIDs. In that case, it should not be tied to > interface...Correct me if I am wrong. > > Ok. Will fix it. > > It is mentioned in page 7, that in deregistration request, the 'O' flag > must be set to 0. What is the reason for this? My understanding is that > deregistration has a special trigger to remove the bindings and what is > the reason for such setting of the 'O' flag. > Since, for dereg all bindings are removed, the 'O' flag has little purpose in that case and hence such restrction. > In mobile node operation section, the first two bullets mentions about > MN returning home. It is not very clear the methods disclosed in the > first two bullets. Is there any difference between the first two > bullets. Perhaps more clarity in the text is useful. > > Ok > > Also, it is mentioned that simultaneously at home and away is not > supported in section 5.1. Again is there any reason and do you plan to > incorporate this simultaneously at home and away in the future revision. > I think this scenario is essential considering some deployments in 3GPP. > Even in the home network domain, such a scenario can exist due to > different mobility management mechanisms to handle different interfaces. > > > > In "mobile node in foreign network" section in page 9, the first bullet > is a "SHOULD". Why is this so? If the mobile node cannot see home > prefix then it is in foreign link. Then it is a MUST. Am I right to say > that? > The support for multiple interfaces/tunnels, requires some additional clarity on when a mobile can be considered its at home. Sure, if the home prefix is not seen, ie. if none of the interfaces are attached to the home link. Will clarify. > > What is the reason for this configuration parameter "Enable Multiple > Tunnel Support". Is it a static variable or dynamic. > Its a knob to turn off the feature. Its a protocol config variable. > > > In page 9, there is a small typo error it should be "sought for". > o If the value of the configuration variable, > EnableMultipleTunnelSupport is set to a value of 1, then the > mobile node SHOULD register a care-of address for each of those > interfaces, by sending a Registration Request. Each of the > requests sent MUST contain the care-of address of the respective > interface and the Multiple Tunnel Request extension reflecting the > interface properties. The mobile node MUST ensure that the > Registration Request is routed through the specific interface for > which the registration is sough for. > Ok > > In page 9, in one before the last bullet it says that the MN 'SHOULD" > create a tunnel. I thought once it receives a positive ack, it MUST > create a tunnel. > Ok. > > > In section 5.2 it is mentioned that the FA "should" check the > configuration variable. I think it should be MUST because it has a > Enable MultipleSupport variable enabled. > > Ok > > In section 5.2 it is mentioned that a MN connected to a single FA using > multiple interfaces. Is there a single tunnel for both interfaces or > multiple tunnels? Moreover, it is better to introduce this scenario once > supported configuration section is described. This is just a simple > suggestion. > > There is only tunnel on the network side, if the FA-COA is the same. Will clarify. > > In section 5.3 in HA operation, it is mentioned that MIPv4 RFC already > has multiple bindings support. It is not very clear from the text how > that is different from this multiple CoA address support disclosed in > this draft. Perhaps it is better to clearly distinguish the difference. > Sorry I haven't read the MIPv4 RFC in detail and was not very clear.... > There is simultaneous binding support, where every packet is sent on all tunnels. Its different from that sense. > There is no clear differentiation between figure 4 and figure 5. What is > the difference? How is the registration done? It would be beneficial to There is a tunnel for each CoA, so the difference is 2 tunnels vs 1 tunnel. > show how the multiple CoA support is achieved in such scenarios. This is > a useful scenario and is used in some SDOs. For example in Figure 4, it > seems single tunnel, so will the FA send all interface parameters in a > single registration and so on needs to be explained. This will be useful > for deployments. > > > These are some of my comments. Thanks for the review. Regards Sri > Thanks. > > BR, > Mohana > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 5 19:05:38 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F683A6955; Mon, 5 Jan 2009 19:05:38 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C03828B56A for ; Mon, 5 Jan 2009 19:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 OSvqA5yF4QoU for ; Mon, 5 Jan 2009 19:05:36 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id EE4493A6954 for ; Mon, 5 Jan 2009 19:05:33 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id n0635KpR021679 for ; Tue, 6 Jan 2009 12:05:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id n0635K028793 for ; Tue, 6 Jan 2009 12:05:20 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id n0635Jb07092 for ; Tue, 6 Jan 2009 12:05:19 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jan 2009 11:04:34 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03113744@pslexc01.psl.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Comments fordraft-gundavelli-mip4-multiple-tunnel-support-00.txt Thread-Index: Aclvi0ZHKTn4Z0MWRXeTDzqhXfpJRwAHeNKA References: <5F09D220B62F79418461A978CA0921BD031134A1@pslexc01.psl.local> From: "Mohana Jeyatharan" To: "Sri Gundavelli" Cc: mip4@ietf.org Subject: Re: [Mip4] Comments fordraft-gundavelli-mip4-multiple-tunnel-support-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Sri, Thanks for reply. Please see in-line. BR, Mohana > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of Sri Gundavelli > Sent: Tuesday, January 06, 2009 7:14 AM > To: Mohana Jeyatharan > Cc: mip4@ietf.org > Subject: Re: [Mip4] Comments > fordraft-gundavelli-mip4-multiple-tunnel-support-00.txt > > Hi Mohana, > > Thanks for the review. Please see inline. > > > On Mon, 5 Jan 2009, Mohana Jeyatharan wrote: > > > Hi Sri, > > > > I read your draft Multiple Tunnel Support for Mobile IPv4. > > I think it is a very useful draft since multihoming is essential in > > any mobility protocol. > > > > This is an interesting work in MIPv4 but nevertheless, I have some > > questions. > > > > In page[4], only bulk re-registration is defined. > Furthermore, in the > > draft bulk registration is not supported. Is there any > reason for this? > > Or do you plan to have bulk registration support in future > revisions. > > MONAMI6 MCoA draft has support for bulk registration and > why is this > > not supported in your draft? > > > > Support for bulk registration is within the scope of re-registration. > We want the registration message for a given CoA to be sent > through the same access network to which the given interface > is attached. This will ensure, it will work even in the > presence of NAT and when supporting RFC-3519. If we allow > this for initial registration, that request will go through > only one specific path, which we dont want. So, the spec > allows bulk reg only for reregs, when nothing changes on the MN. > [Mohana] Ok, Understand. Specially, since this is IPv4 addresses and highliy likely that NATs will be present, it may be advisable to avoid bulk registration. > > > > Figure 1 in page 5 shows multiple interfaced MN making simultaneous > > attachment with and without using FA. Is the assumption > such that the > > MN uses co-located care-of address when there is no FA present and > > uses FA care-of address when there is a FA present? Just a > > clarification question... > > > > > > > > It is mentioned in page 5 that the MIPv4 multiple CoA > support informs > > the HA the type of interface and capacity and so on. What > is the need > > for this? Current Monami6 MCoA draft which handles multiple CoA > > registration does not have this information. Do you think this > > information is useful for the network to set flow polices? > It leads me > > to another question that in any case, the available capacity in the > > access network can be monitored by the network entities and > informed > > to HA and why should the MN send these information? > > > > Access type is an important parameter for enabling any > traffic policies. > The home agent cannot always monitor the characterstics of > the access network, specially in a unmanaged network, or for > client-based mobility. > In the mobile router deployments for which this is more > useful, the home network will have no clue about access > networks to which the mobile router is attached. Registering > the access type, will provide the link characterstics to the > home network. It knows about each of tunnel paths and how it > is tied to the air link on the mobile. > > [Mohana] Agree, I was thinking more interms of MN in home network domain. I agree in foreign domain, access link specific characetristics cannot be sent to the home agent by foreign network entities and such information is useful. My true feeling is that this access technology specific information is useful (as you have mentioned) for home agent to set some traffic policies. > > > > The term "throughput capacity" in page 5 is not very clear. > Is it the > > used bandwidth per MN or the available spare bandwidth? I think it > > would be better if more clarity is given to this term. My > > understanding is the spare bandwidth. If it is the spare bandwidth > > then again, another question is how the MN gets such > information. This > > is very much access technology specific. > > > > Ok. Will clarify this. [Mohana] thanks. > > > > > > > A small typo in page 5, > > "The throughput capacity of each of these tunnels is dependent on > > the access technology over which the mobile node is > attached. The > > mobile node notifies the interface properties for each attached > > interface and the home agent can user this as a metric for it > > traffic policies." > > the home agent can use this as a metric for it.... > > > > Ok. > > > > > In page 7 the length field is mentioned to have length 6 > octets. Is it > > 10 octets or 6 octets? > > > > > > Thanks. It should be 10, excluding Type and Length fields. > > > > > BID was defined in terminology section and it is again repeated in > > page 7. Possibly, such double definition can be removed. > Again, it is > > mentioned in page 7 that the BID can be an interface index > assigned by > > the operating system. Is this a preferred way of creating BID and > > moreover if there are multiple BIDs per interface then what > is the way > > of generating the BIDs. In that case, it should not be tied to > > interface...Correct me if I am wrong. > > > > > > Ok. Will fix it. > > > > > > It is mentioned in page 7, that in deregistration request, the 'O' > > flag must be set to 0. What is the reason for this? My > understanding > > is that deregistration has a special trigger to remove the bindings > > and what is the reason for such setting of the 'O' flag. > > > > Since, for dereg all bindings are removed, the 'O' flag has > little purpose in that case and hence such restrction. [Mohana] Ok, understand. > > > In mobile node operation section, the first two bullets > mentions about > > MN returning home. It is not very clear the methods > disclosed in the > > first two bullets. Is there any difference between the first two > > bullets. Perhaps more clarity in the text is useful. > > > > > > Ok > > > > > Also, it is mentioned that simultaneously at home and away is not > > supported in section 5.1. Again is there any reason and do > you plan to > > incorporate this simultaneously at home and away in the > future revision. > > I think this scenario is essential considering some > deployments in 3GPP. > > Even in the home network domain, such a scenario can exist due to > > different mobility management mechanisms to handle > different interfaces. > > > > > > > > In "mobile node in foreign network" section in page 9, the first > > bullet is a "SHOULD". Why is this so? If the mobile node > cannot see > > home prefix then it is in foreign link. Then it is a MUST. > Am I right > > to say that? > > > > > The support for multiple interfaces/tunnels, requires some > additional clarity on when a mobile can be considered its at > home. Sure, if the home prefix is not seen, ie. if none of > the interfaces are attached to the home link. Will clarify. > > > > > What is the reason for this configuration parameter "Enable > Multiple > > Tunnel Support". Is it a static variable or dynamic. > > > > Its a knob to turn off the feature. Its a protocol config variable. [Mohana]Ok, fine... > > > > > > In page 9, there is a small typo error it should be "sought for". > > o If the value of the configuration variable, > > EnableMultipleTunnelSupport is set to a value of 1, then the > > mobile node SHOULD register a care-of address for each of those > > interfaces, by sending a Registration Request. Each of the > > requests sent MUST contain the care-of address of the > respective > > interface and the Multiple Tunnel Request extension > reflecting the > > interface properties. The mobile node MUST ensure that the > > Registration Request is routed through the specific > interface for > > which the registration is sough for. > > > > Ok > > > > > In page 9, in one before the last bullet it says that the > MN 'SHOULD" > > create a tunnel. I thought once it receives a positive ack, it MUST > > create a tunnel. > > > > Ok. > > > > > > > > In section 5.2 it is mentioned that the FA "should" check the > > configuration variable. I think it should be MUST because it has a > > Enable MultipleSupport variable enabled. > > > > > > Ok > > > > > In section 5.2 it is mentioned that a MN connected to a single FA > > using multiple interfaces. Is there a single tunnel for both > > interfaces or multiple tunnels? Moreover, it is better to introduce > > this scenario once supported configuration section is > described. This > > is just a simple suggestion. > > > > > > There is only tunnel on the network side, if the FA-COA is the same. > Will clarify. > [Mohana] Ok, thanks. This scenario is very interesting. > > > > In section 5.3 in HA operation, it is mentioned that MIPv4 > RFC already > > has multiple bindings support. It is not very clear from > the text how > > that is different from this multiple CoA address support > disclosed in > > this draft. Perhaps it is better to clearly distinguish the > difference. > > Sorry I haven't read the MIPv4 RFC in detail and was not > very clear.... > > > > There is simultaneous binding support, where every packet is > sent on all tunnels. Its different from that sense. [Mohana] Ok, when I read back can see the difference.. > > There is no clear differentiation between figure 4 and > figure 5. What > > is the difference? How is the registration done? It would be > > beneficial to > > There is a tunnel for each CoA, so the difference is 2 > tunnels vs 1 tunnel. [Mohana] Agree, the diagram clearly shows the tunnel separation but wanted to see more On protocol operation. Maybe in future revisions you can use this scenario for more protocol operation.... > > > show how the multiple CoA support is achieved in such > scenarios. This is > > a useful scenario and is used in some SDOs. For example in > Figure 4, it > > seems single tunnel, so will the FA send all interface > parameters in a > > single registration and so on needs to be explained. This > will be useful > > for deployments. > > > > > > > These are some of my comments. > > Thanks for the review. > > Regards > Sri > > > > > > Thanks. > > > > BR, > > Mohana > > > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 8 06:15:03 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F1628C168; Thu, 8 Jan 2009 06:15:03 -0800 (PST) X-Original-To: mip4@ietf.org Delivered-To: mip4@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4484E28C0F4; Thu, 8 Jan 2009 06:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090108141501.4484E28C0F4@core3.amsl.com> Date: Thu, 8 Jan 2009 06:15:01 -0800 (PST) Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-dsmipv4-09.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mip4-dsmipv4-09.txt Pages : 22 Date : 2009-01-08 This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-09.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-mip4-dsmipv4-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-08060255.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Thu Jan 8 06:26:48 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34CC3A6859; Thu, 8 Jan 2009 06:26:48 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1E23A6859 for ; Thu, 8 Jan 2009 06:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 RJYic1oa+V75 for ; Thu, 8 Jan 2009 06:26:46 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 409C63A679F for ; Thu, 8 Jan 2009 06:26:45 -0800 (PST) Received: by bwz14 with SMTP id 14so27316264bwz.13 for ; Thu, 08 Jan 2009 06:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=CZFkJBG0PK5oj7ph/OyWCOQuRjwGrORLerCJbpfJN5w=; b=YRIZnASz5vIpuJ6mjpHWDgBuvxWEQ4wG3Nw0d+K+6f0Mu9Gn09Vj9ZHTvkZBclGPY9 BZUBePqnUgA8OLQOqeBCkN5GPARrET0qPa0Hy0zhD/A1faxykih+MFA9CCGfzEsUVJtp EhMkrTmTPuvndMsnQdQdRQ/CU2S3sIRQBALCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vOApp5abpQ1Vv33oWgjcAAzhJ5kvRxF1yMf+avwZCBOfqy6KTSSTUShB63m7GSDf9S Lvvq7D2u2EyXq7knXsomP9dvSDKIdfXgOonuMdLtrUd2TyY16WN9hI2biFYcXzZyzc/t 3x2ZjS0NbF7Kl+sVVidx/wdwGIbV9qqFmW8s8= Received: by 10.103.240.5 with SMTP id s5mr8762157mur.133.1231424790395; Thu, 08 Jan 2009 06:26:30 -0800 (PST) Received: by 10.103.49.5 with HTTP; Thu, 8 Jan 2009 06:26:30 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2009 14:26:30 +0000 From: "George Tsirtsis" To: mip4@ietf.org In-Reply-To: <20090108141501.4484E28C0F4@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20090108141501.4484E28C0F4@core3.amsl.com> Cc: Jari Arkko , Pasi Eronen Subject: Re: [Mip4] I-D Action:draft-ietf-mip4-dsmipv4-09.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Pasi/Jari, To gain some time I took the initiative and implemented the changes I summarized in my last e-mail response to Pasi. In this version I also REMOVED the option of tunneling IPv6 to the FA CoA. Now all IPv6 traffic always goes to the MN's HoA or the MN's CoA (In co-located mode only). Thanks George 2009/1/8 : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility for IPv4 Working Group of the IETF. > > > Title : Dual Stack Mobile IPv4 > Author(s) : G. Tsirtsis, et al. > Filename : draft-ietf-mip4-dsmipv4-09.txt > Pages : 22 > Date : 2009-01-08 > > This specification provides IPv6 extensions to the Mobile IPv4 > protocol. The extensions allow a dual stack node to use IPv4 and > IPv6 home addresses as well as to move between IPv4 and dual stack > network infrastructures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-09.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. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 8 16:26:37 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8F53A68DB; Thu, 8 Jan 2009 16:26:37 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC8628C0EB for ; Thu, 8 Jan 2009 16:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 pqPLGh7B4QET for ; Thu, 8 Jan 2009 16:26:35 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5002A3A68DB for ; Thu, 8 Jan 2009 16:26:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,236,1231113600"; d="scan'208";a="120998830" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Jan 2009 00:26:22 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n090QM7i028329; Thu, 8 Jan 2009 16:26:22 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n090QLSn021625; Fri, 9 Jan 2009 00:26:21 GMT Date: Thu, 8 Jan 2009 16:26:21 -0800 (PST) From: Sri Gundavelli To: Mohana Jeyatharan In-Reply-To: <5F09D220B62F79418461A978CA0921BD03113743@pslexc01.psl.local> Message-ID: References: <5F09D220B62F79418461A978CA0921BD031134A1@pslexc01.psl.local> <5F09D220B62F79418461A978CA0921BD03113743@pslexc01.psl.local> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10756; t=1231460782; x=1232324782; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[Mip4]=20Comments=20fordraft-gundavelli -mip4-multiple-tunnel-support-00.txt |Sender:=20; bh=XPSB4EqBzUJ5I8k2OQ1cTA7nrUAs9GEZaOqlwDJ63ZQ=; b=VFdKLE2IMHzAyL1Pt2w6jlp2KNix3xA2Xn/sjOKeieqjmWURsy/Y3lrjsF 2OYOKcO9fNx4SI7s+8p1XMg1mfWV/ulXlyx7cQkskr0m+BPFGwkKwCGU737h MU7NHZ+MNC7Cm2dUQG99+mc2pN/VhphkNxSnf4M5YW3XiJPDB3m8g=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mip4@ietf.org Subject: Re: [Mip4] Comments fordraft-gundavelli-mip4-multiple-tunnel-support-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Mohana, Please see inline .. On Tue, 6 Jan 2009, Mohana Jeyatharan wrote: > Hi Sri, > > Thanks for reply. Please see in-line. > > BR, > Mohana > >> -----Original Message----- >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >> Behalf Of Sri Gundavelli >> Sent: Tuesday, January 06, 2009 7:14 AM >> To: Mohana Jeyatharan >> Cc: mip4@ietf.org >> Subject: Re: [Mip4] Comments >> fordraft-gundavelli-mip4-multiple-tunnel-support-00.txt >> >> Hi Mohana, >> >> Thanks for the review. Please see inline. >> >> >> On Mon, 5 Jan 2009, Mohana Jeyatharan wrote: >> >>> Hi Sri, >>> >>> I read your draft Multiple Tunnel Support for Mobile IPv4. >>> I think it is a very useful draft since multihoming is essential in >>> any mobility protocol. >>> >>> This is an interesting work in MIPv4 but nevertheless, I have some >>> questions. >>> >>> In page[4], only bulk re-registration is defined. >> Furthermore, in the >>> draft bulk registration is not supported. Is there any >> reason for this? >>> Or do you plan to have bulk registration support in future >> revisions. >>> MONAMI6 MCoA draft has support for bulk registration and >> why is this >>> not supported in your draft? >>> >> >> Support for bulk registration is within the scope of re-registration. >> We want the registration message for a given CoA to be sent >> through the same access network to which the given interface >> is attached. This will ensure, it will work even in the >> presence of NAT and when supporting RFC-3519. If we allow >> this for initial registration, that request will go through >> only one specific path, which we dont want. So, the spec >> allows bulk reg only for reregs, when nothing changes on the MN. >> > [Mohana] Ok, Understand. Specially, since this is IPv4 addresses and > highliy likely that NATs will > be present, it may be advisable to avoid bulk registration. > >>> >>> Figure 1 in page 5 shows multiple interfaced MN making simultaneous >>> attachment with and without using FA. Is the assumption >> such that the >>> MN uses co-located care-of address when there is no FA present and >>> uses FA care-of address when there is a FA present? Just a >>> clarification question... >>> >>> >>> >>> It is mentioned in page 5 that the MIPv4 multiple CoA >> support informs >>> the HA the type of interface and capacity and so on. What >> is the need >>> for this? Current Monami6 MCoA draft which handles multiple CoA >>> registration does not have this information. Do you think this >>> information is useful for the network to set flow polices? >> It leads me >>> to another question that in any case, the available capacity in the >>> access network can be monitored by the network entities and >> informed >>> to HA and why should the MN send these information? >>> >> >> Access type is an important parameter for enabling any >> traffic policies. >> The home agent cannot always monitor the characterstics of >> the access network, specially in a unmanaged network, or for >> client-based mobility. >> In the mobile router deployments for which this is more >> useful, the home network will have no clue about access >> networks to which the mobile router is attached. Registering >> the access type, will provide the link characterstics to the >> home network. It knows about each of tunnel paths and how it >> is tied to the air link on the mobile. >> >> > [Mohana] Agree, I was thinking more interms of MN in home network > domain. I agree > in foreign domain, access link specific characetristics cannot be sent > to > the home agent by foreign network entities and such information is > useful. My true feeling is that > this access technology specific information is useful (as you have > mentioned) for home agent to set some traffic policies. Yes >>> >>> The term "throughput capacity" in page 5 is not very clear. >> Is it the >>> used bandwidth per MN or the available spare bandwidth? I think it >>> would be better if more clarity is given to this term. My >>> understanding is the spare bandwidth. If it is the spare bandwidth >>> then again, another question is how the MN gets such >> information. This >>> is very much access technology specific. >>> >> >> Ok. Will clarify this. > [Mohana] thanks. >> >>> >>> >>> A small typo in page 5, >>> "The throughput capacity of each of these tunnels is dependent on >>> the access technology over which the mobile node is >> attached. The >>> mobile node notifies the interface properties for each attached >>> interface and the home agent can user this as a metric for it >>> traffic policies." >>> the home agent can use this as a metric for it.... >>> >> >> Ok. >> >>> >>> In page 7 the length field is mentioned to have length 6 >> octets. Is it >>> 10 octets or 6 octets? >>> >>> >> >> Thanks. It should be 10, excluding Type and Length fields. >> >>> >>> BID was defined in terminology section and it is again repeated in >>> page 7. Possibly, such double definition can be removed. >> Again, it is >>> mentioned in page 7 that the BID can be an interface index >> assigned by >>> the operating system. Is this a preferred way of creating BID and >>> moreover if there are multiple BIDs per interface then what >> is the way >>> of generating the BIDs. In that case, it should not be tied to >>> interface...Correct me if I am wrong. >>> >>> >> >> Ok. Will fix it. >> >> >>> >>> It is mentioned in page 7, that in deregistration request, the 'O' >>> flag must be set to 0. What is the reason for this? My >> understanding >>> is that deregistration has a special trigger to remove the bindings >>> and what is the reason for such setting of the 'O' flag. >>> >> >> Since, for dereg all bindings are removed, the 'O' flag has >> little purpose in that case and hence such restrction. > > [Mohana] Ok, understand. > >> >>> In mobile node operation section, the first two bullets >> mentions about >>> MN returning home. It is not very clear the methods >> disclosed in the >>> first two bullets. Is there any difference between the first two >>> bullets. Perhaps more clarity in the text is useful. >>> >>> >> >> Ok >> >>> >>> Also, it is mentioned that simultaneously at home and away is not >>> supported in section 5.1. Again is there any reason and do >> you plan to >>> incorporate this simultaneously at home and away in the >> future revision. >>> I think this scenario is essential considering some >> deployments in 3GPP. >>> Even in the home network domain, such a scenario can exist due to >>> different mobility management mechanisms to handle >> different interfaces. >>> >>> >>> >>> In "mobile node in foreign network" section in page 9, the first >>> bullet is a "SHOULD". Why is this so? If the mobile node >> cannot see >>> home prefix then it is in foreign link. Then it is a MUST. >> Am I right >>> to say that? >>> >> >> >> The support for multiple interfaces/tunnels, requires some >> additional clarity on when a mobile can be considered its at >> home. Sure, if the home prefix is not seen, ie. if none of >> the interfaces are attached to the home link. Will clarify. >> >>> >>> What is the reason for this configuration parameter "Enable >> Multiple >>> Tunnel Support". Is it a static variable or dynamic. >>> >> >> Its a knob to turn off the feature. Its a protocol config variable. > [Mohana]Ok, fine... >>> >>> >>> In page 9, there is a small typo error it should be "sought for". >>> o If the value of the configuration variable, >>> EnableMultipleTunnelSupport is set to a value of 1, then the >>> mobile node SHOULD register a care-of address for each of those >>> interfaces, by sending a Registration Request. Each of the >>> requests sent MUST contain the care-of address of the >> respective >>> interface and the Multiple Tunnel Request extension >> reflecting the >>> interface properties. The mobile node MUST ensure that the >>> Registration Request is routed through the specific >> interface for >>> which the registration is sough for. >>> >> >> Ok >> >>> >>> In page 9, in one before the last bullet it says that the >> MN 'SHOULD" >>> create a tunnel. I thought once it receives a positive ack, it MUST >>> create a tunnel. >>> >> >> Ok. >> >> >>> >>> >>> In section 5.2 it is mentioned that the FA "should" check the >>> configuration variable. I think it should be MUST because it has a >>> Enable MultipleSupport variable enabled. >>> >>> >> >> Ok >> >>> >>> In section 5.2 it is mentioned that a MN connected to a single FA >>> using multiple interfaces. Is there a single tunnel for both >>> interfaces or multiple tunnels? Moreover, it is better to introduce >>> this scenario once supported configuration section is >> described. This >>> is just a simple suggestion. >>> >>> >> >> There is only tunnel on the network side, if the FA-COA is the same. >> Will clarify. >> > [Mohana] Ok, thanks. This scenario is very interesting. >>> >>> In section 5.3 in HA operation, it is mentioned that MIPv4 >> RFC already >>> has multiple bindings support. It is not very clear from >> the text how >>> that is different from this multiple CoA address support >> disclosed in >>> this draft. Perhaps it is better to clearly distinguish the >> difference. >>> Sorry I haven't read the MIPv4 RFC in detail and was not >> very clear.... >>> >> >> There is simultaneous binding support, where every packet is >> sent on all tunnels. Its different from that sense. > > [Mohana] Ok, when I read back can see the difference.. >>> There is no clear differentiation between figure 4 and >> figure 5. What >>> is the difference? How is the registration done? It would be >>> beneficial to >> >> There is a tunnel for each CoA, so the difference is 2 >> tunnels vs 1 tunnel. > > [Mohana] Agree, the diagram clearly shows the tunnel separation but > wanted to see more > On protocol operation. Maybe in future revisions you can use this > scenario for more protocol operation.... >> Sure. Will fix it. >>> show how the multiple CoA support is achieved in such >> scenarios. This is >>> a useful scenario and is used in some SDOs. For example in >> Figure 4, it >>> seems single tunnel, so will the FA send all interface >> parameters in a >>> single registration and so on needs to be explained. This >> will be useful >>> for deployments. >>> >> >>> >>> These are some of my comments. >> Thanks again for the review comments. Sri -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 12 19:06:20 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A53F3A6A42; Mon, 12 Jan 2009 19:06:20 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E833A67EA for ; Mon, 12 Jan 2009 14:28:52 -0800 (PST) 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 M7wBF+oi5fON for ; Mon, 12 Jan 2009 14:28:51 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 4A7E03A68D0 for ; Mon, 12 Jan 2009 14:28:50 -0800 (PST) Received: by bwz14 with SMTP id 14so32984336bwz.13 for ; Mon, 12 Jan 2009 14:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:to:content-type :content-transfer-encoding:mime-version:subject:date:x-mailer:from; bh=mA0RgUd+vTSL8qGCF8wSY45RODi/YwjAoARI0MQtRtw=; b=eA45AYKbgRz+7Qjzp+G8I2hz36hTGJ88yf1dw5FXNNC7XBi03v0nhKjeBBsDvVXTlm g67LYBtVCilR4uHJszfwieq7whyRM47lfGYg8m5CA1VC+pGSC3X2Bo7Fx7q6rx93ft/1 RI/A4CZF2pnVR9Zt5icWwRC+DrYG7huqUaqEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:to:content-type:content-transfer-encoding:mime-version :subject:date:x-mailer:from; b=objTBw3crjbxmw1G7Rrq3IgfiWR6A0D/0YQy/fJV5LY2vtA+ZQA+yTBa4SCbptqJet p5M8PifiGQWgVX4aBje/llbmPrZhjhhGZs3r3LmvXXgkvE03RwFzDfQPPZUTgTtOQkSm XZVDv64HqzdWrdwqlqhn0PZuMs+MeTSoSY3NQ= Received: by 10.103.221.5 with SMTP id y5mr11015432muq.66.1231799314107; Mon, 12 Jan 2009 14:28:34 -0800 (PST) Received: from a88-112-141-126.elisa-laajakaista.fi (a88-112-141-126.elisa-laajakaista.fi [88.112.141.126]) by mx.google.com with ESMTPS id 14sm60979801muo.9.2009.01.12.14.28.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 14:28:32 -0800 (PST) Message-Id: <7E7E6561-7061-4EA3-A1E1-9A0918F27956@gmail.com> To: mip4@ietf.org, Sri Gundavelli Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 13 Jan 2009 00:28:29 +0200 X-Mailer: Apple Mail (2.929.2) From: jouni korhonen X-Mailman-Approved-At: Mon, 12 Jan 2009 19:06:19 -0800 Subject: [Mip4] Comments on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Sri, authors, Here are my initial comments/review of the draft-gundavelli-mip4- multiple-tunnel-support-00. Comments are prefixed with [JiK]. I found this draft rather interesting. Cheers, Jouni Abstract ... agent, each through a different interface path. This capability is required for enabling a mobile node to utilize all the available wireless access links and build an higher aggregated data pipe to the home agent by setting the home address reachability over all of those tunnel paths. [JiK] Although this I-D might be motivated by wireless host, I would not mention it as the only use case. The same comment concerns also the first paragraph of the Introduction. Section 1. 2nd paragraph ... attached. In both of these modes, there will only be one interface on the mobile node that is receiving the traffic from the home agent. However, this is not efficient and requires an approach where the mobile node can use more than one interfaces for reaching the home network. The objective being efficient use of all available links to obtain higher aggregated bandwidth for the tunneled traffic between the home agent and the mobile node. [JiK] Doesn't this hold for one HoA.. A mobile could have different HoAs per a set of interface etc.. Or is there a specific restriction of not allowing more than one HoA per mobile node? I would clarify what "constitutes" a mobile node within this specification. Is it a HoA or a mobile node identity (that could be other than HoA.. and a mobile node could have multiple identities). Section 1. 3rd paragraph This document presents extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care- of address for each of those active interfaces and establish overlay network of tunnels to the home agent over those interface paths. ... [JiK] Is there an assumption that an interface is always a separate physical interface? Or can an interface be an alias interface as well? Section 2.2. ... are given a unique identifier and this identifier is called the binding identifier. The identifier is unique within all the bindings for a given mobile node. [JiK] Unique for a mobile node or one HoA? If a mobile node had multiple HoAs BIDs would still be unique? How this would be done? Section 3. ... The mobile node registers to the home agent through each of the available roaming interfaces. As part of the registration, the ... [JiK] A "roaming interface" is...? ... The home agent sets up the routing for the mobile node's home address. The home address will be reachable over any of the established tunnels for that mobile node. Based on the enabled traffic policies, the home agent can distribute the data traffic over any of those tunnels in any fashion. When there are no explicit traffic policies in place, the default routing policy of per-flow load balancing will be in affect. [JiK] I would like to see similar text from a mobile node point of view. Section 4.1. ... This extension is a non-skippable extension and MAY be added to the Registration Request message by the mobile node. There MUST not be more than one instance of this extension present in the message. [JiK] s/MUST not/MUST NOT Interface-Type (If-Type) Type of interface through which the mobile node is connected. The permitted values for this are from the Access Technology Type registry. [JiK] Where are these interface types defined? I could not find any mention of a registry etc. Binding-Id (BID) This 16-bit field is the binding identifier. It uniquely identifies a specific binding of the mobile node, with which ... [JiK] Is it actually per HoA, not per mobile node? Interface Bandwidth (If-BW) This 16-bit unsigned integer is used for conveying the available bandwidth of the interface associated with this request. The bandwidth is specified in kilo-bytes, fractions are to be rounded to the nearest integer. [JiK] How does the mobile node get this information? If it is just the "nominal" speed of the interface, this information can be very misleading and optimistic.. For example a 54MB WLAN behind a 1M xDSL. Section 5.1. o If the mobile node for connecting to the home link, uses either a designated interface or any of the available interfaces to connect to the home link and if it detects its home link through any of those interfaces, then it MUST consider its on the home link and SHOULD perform the deregistration procedure. [JiK] Did I get it right that if any of the interfaces is on the home link, then all the other links have to de-register as well? Or is it only that interface that happens to be on the home link? Section 5.3. ... node when it is supporting simultaneous bindings for that registration. When the home agent allows simultaneous bindings, it will tunnel a separate copy of each arriving datagram to each of those care-of addresses, and the mobile node will receive multiple copies of datagrams destined to it. The operation defined in this specification allows a mobile node to register from multiple interfaces using different care-of addresses and have multiple tunnels from the home agent to each of those care-of addresses and for distributing the traffic load across those tunnels. This is a different model than the simultaneous bindings when it comes to the ... [JiK] Does the mechanism in this specification work with "traditional" simultaneous bindings? Section 8. When the value for this flag is set to value of 0, multiple tunnel support SHOULD be disabled. [JiK] Why just SHOULDs ? Isn't it MUST for disabling? In what occasion the multiple tunnel support could be allowed if it is disabled? Section 9. [JiK] Interface type registry is missing? Also, maybe it could be useful to describe what range of error codes are used for both MULTIPLE_TUNNEL_REQUEST_DENIED_BY_HA & MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA. Section 10. [JiK] Well, if you DoS a mobile node that has multiple tunnels connected, you can DoS the mobile node way harder than just through one interface & tunnel ;) -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jan 12 19:07:52 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AB83A6A4A; Mon, 12 Jan 2009 19:07:52 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C343A6905; Wed, 7 Jan 2009 16:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 QtO-+E9hSOI3; Wed, 7 Jan 2009 16:43:53 -0800 (PST) Received: from smtp.dei.uc.pt (smtp2.dei.uc.pt [193.137.203.233]) by core3.amsl.com (Postfix) with ESMTP id F38483A682D; Wed, 7 Jan 2009 16:43:51 -0800 (PST) MailScanner-NULL-Check: 1231979630.69071@iXEA6C5co8LdVIvbwZWgLg Received: from your1ca50768ba ([83.240.184.110]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.3/8.14.3) with ESMTP id n080DCkC004708; Thu, 8 Jan 2009 00:30:57 GMT From: =?iso-8859-1?Q?Jorge_S=E1_Silva?= To: "Undisclosed recipients" Date: Thu, 8 Jan 2009 00:17:53 -0000 Message-ID: <00ea01c97128$be33b4e0$3a9b1ea0$@uc.pt> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclxJhUdoWPviOucRH+FfKxNLziDLA== Content-Language: pt X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-MailScanner-ID: n080DCkC004708 X-FCTUC-DEI-SIC-MailScanner: Not scanned: please contact helpdesk@dei.uc.pt for details X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-33.841, required 3.5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 17.96, BAYES_50 0.00, HTML_MESSAGE 0.00, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: sasilva@dei.uc.pt X-Mailman-Approved-At: Mon, 12 Jan 2009 19:07:51 -0800 Subject: [Mip4] EWSN 2009/CONET Master and PhD Thesis Awards X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0990938958==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Esta i uma mensagem com varias partes no formato MIME. --===============0990938958== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01C97128.BE33B4E0" Content-Language: pt Esta i uma mensagem com varias partes no formato MIME. ------=_NextPart_000_00EB_01C97128.BE33B4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable EWSN 2009/CONET Master and PhD Thesis Awards =20 The Chairs of the 6th European Conference on Wireless Sensor Networks = (EWSN 2009) and the CONET Consortium are pleased to announce the Master and = PhD Thesis Award Competitions in the area of Cooperating Objects. The prize = is donated by CONET, the Cooperating Objects Network of Excellence, which = is an EU-funded project under ICT, Framework 7 (for more information refer to http://www.cooperating-objects.eu). =20 Cooperating Objects combine the strong functional aspects of embedded systems, pervasive computing and wireless sensor networks and consist, therefore, of individual entities or objects that jointly strive to = reach a common goal, which will typically be a goal in sensing or control, and = are dynamically and loosely federating themselves for cooperation, taking = care not to overtax their available resources. =20 Theses eligible for the competition have to be completed at an official European university (EU and EFTA) between 1/JAN and 31/DEC/2008. = Candidates must submit the following materials (in English) in electronic format = until 23/JAN/2009: =95 Application letter, including the name of the student, = the title of the thesis and its date of completion, the date of the defense = and the overall grade, and a report on the outstanding contributions of the thesis discriminating the list of publications derived from research = related to the thesis and of which the candidate is the sole or primary author (mandatory for PhD Theses, optional for Master Theses). =95 Letter of recommendation from Advisor. =95 The thesis itself. =20 Submission of a single document file in PDF format must be done thru = EDAS at http://www.edas.info.=20 =20 The award will be assessed by CONET members. Criteria for selecting the winner are scientific originality, scientific significance for the field = of Cooperating Objects, quality of the presentation and potential for = practical application. Each category of thesis (MSc or PhD) will have separate = prizes assigned by separate academic and industrial juries, for a total of 4 prizes: =95 MSc Academic =96 250 Euros =95 MSc Industrial =96 250 Euros =95 PhD Academic =96 500 Euros =95 PhD Industrial =96 500 Euros =20 The jury can decide not to award some of the prizes if the quality or significance of the submitted works is not relevant.=20 The winners of each category will be awarded at the EWSN 2009 dinner on February 12th.=20 =20 No virus found in this outgoing message. Checked by AVG.=20 Version: 7.5.552 / Virus Database: 270.10.3/1879 - Release Date: = 06-01-2009 17:16 =20 ------=_NextPart_000_00EB_01C97128.BE33B4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

EWSN 2009/CONET Master and PhD Thesis = Awards

 

The Chairs of the 6th European Conference on = Wireless Sensor Networks (EWSN 2009) and the CONET Consortium are pleased to announce = the Master and PhD Thesis Award Competitions in the area of Cooperating = Objects. The prize is donated by CONET, the Cooperating Objects Network of = Excellence, which is an EU-funded project under ICT, Framework 7 (for more = information refer to http://www.cooperating-objects.eu).

 

Cooperating Objects combine the strong functional = aspects of embedded systems, pervasive computing and wireless sensor networks and = consist, therefore, of individual entities or objects that jointly strive to = reach a common goal, which will typically be a goal in sensing or control, and = are dynamically and loosely federating themselves for cooperation, taking = care not to overtax their available resources.

 

Theses eligible for the competition have to be = completed at an official European university (EU and EFTA) between 1/JAN and = 31/DEC/2008. Candidates must submit the following materials (in English) in = electronic format until 23/JAN/2009:

•=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Application letter, including the name of the student, the title of the thesis and its date of completion, the = date of the defense and the overall grade, and a report on the outstanding contributions of the thesis discriminating the list of publications = derived from research related to the thesis and of which the candidate is the = sole or primary author (mandatory for PhD Theses, optional for Master = Theses).

•=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Letter = of recommendation from Advisor.

•=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The = thesis itself.

 

Submission of a single document file in PDF format = must be done thru EDAS at http://www.edas.info.

 

The award will be assessed by CONET members. = Criteria for selecting the winner are scientific originality, scientific significance = for the field of Cooperating Objects, quality of the presentation and = potential for practical application. Each category of thesis (MSc or PhD) will have = separate prizes assigned by separate academic and industrial juries, for a total = of 4 prizes:

•=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MSc Academic = – 250 Euros

•=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MSc Industrial = – 250 Euros

•=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PhD Academic = – 500 Euros

•=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PhD Industrial = – 500 Euros

 

The jury can decide not to award some of the prizes = if the quality or significance of the submitted works is not relevant. =

The winners of each category will be awarded at the = EWSN 2009 dinner on February 12th.

 


No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.552 / Virus Database: 270.10.3/1879 - Release Date: = 06-01-2009 17:16

------=_NextPart_000_00EB_01C97128.BE33B4E0-- --===============0990938958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0990938958==-- From mip4-bounces@ietf.org Mon Jan 12 23:39:54 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3356B3A68F6; Mon, 12 Jan 2009 23:39:54 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CA13A68F6 for ; Mon, 12 Jan 2009 23:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 E1YZgSn07Dv7 for ; Mon, 12 Jan 2009 23:39:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C56FA3A67D1 for ; Mon, 12 Jan 2009 23:39:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,258,1231113600"; d="scan'208";a="30693869" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Jan 2009 07:39:33 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0D7dXGf031809; Tue, 13 Jan 2009 08:39:33 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0D7dX3Q008844; Tue, 13 Jan 2009 07:39:33 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jan 2009 08:39:33 +0100 Received: from sgundavewxp ([10.32.246.214]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jan 2009 08:39:32 +0100 From: "Sri Gundavelli" To: "'jouni korhonen'" , References: <7E7E6561-7061-4EA3-A1E1-9A0918F27956@gmail.com> Date: Mon, 12 Jan 2009 23:39:30 -0800 Message-ID: <004b01c97552$132c2cc0$d6f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acl1K+FBGYd/vt2bTSy5u1Kyf6RfyQAIr91g In-Reply-To: <7E7E6561-7061-4EA3-A1E1-9A0918F27956@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 13 Jan 2009 07:39:32.0644 (UTC) FILETIME=[132FD640:01C97552] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9167; t=1231832373; x=1232696373; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip4]=20Comments=20on=20draft-gundavel li-mip4-multiple-tunnel-support-00 |Sender:=20; bh=WMS1PWFsawidkBgVeNUFT+5e9g0ZRteUZ+cN2pMepIw=; b=AwtF001eN+ZbrkAzf/MpdlVozMyNY76Ug/IHMWzjnVgw9wkKLrmhlrsqy2 39JyedeuD+lsVAeBEbHZkGyXzop4Zm9qs1lQHdS1GmtiKgqjvVY7RZhN4rBj BvVGuL3KdP; Authentication-Results: ams-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Mip4] Comments on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Jouni, Thanks for the review comments. Please see inline. > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of jouni korhonen > Sent: Monday, January 12, 2009 2:28 PM > To: mip4@ietf.org; Sri Gundavelli > Subject: [Mip4] Comments on > draft-gundavelli-mip4-multiple-tunnel-support-00 > > Hi Sri, authors, > > Here are my initial comments/review of the draft-gundavelli-mip4- > multiple-tunnel-support-00. > Comments are prefixed with [JiK]. I found this draft rather > interesting. > > Cheers, > Jouni > > > > > Abstract > > ... > agent, each through a different interface path. This > capability is > required for enabling a mobile node to utilize all the available > wireless access links and build an higher aggregated data > pipe to > the > home agent by setting the home address reachability over all of > those > tunnel paths. > > [JiK] Although this I-D might be motivated by wireless host, > I would not > mention it as the only use case. The same comment I agree. Its certainly not the only use case. May be the most obvious one. Will reword it. > concerns also > the > first paragraph of the Introduction. > > Section 1. 2nd paragraph > > ... > attached. In both of these modes, there will only be one > interface > on the mobile node that is receiving the traffic from the home > agent. > However, this is not efficient and requires an approach where the > mobile node can use more than one interfaces for reaching the home > network. The objective being efficient use of all > available links > to > obtain higher aggregated bandwidth for the tunneled > traffic between > the home agent and the mobile node. > > [JiK] Doesn't this hold for one HoA.. A mobile could have > different HoAs > per a set of interface etc.. Or is there a specific > restriction > of > not allowing more than one HoA per mobile node? I would clarify > what "constitutes" a mobile node within this > specification. Is it > a HoA or a mobile node identity (that could be other > than HoA.. > and > a mobile node could have multiple identities). > There should not be any restrictions when supporting multiple HoA's. The HoA set is reachable via any of these routing paths. Will clarify this. > Section 1. 3rd paragraph > > This document presents extensions to the Mobile IP protocol for > allowing a mobile node with multiple interfaces to > register a care- > of > address for each of those active interfaces and establish overlay > network of tunnels to the home agent over those interface paths. > ... > > [JiK] Is there an assumption that an interface is always a separate > physical interface? Or can an interface be an alias interface > as well? > It should not matter, if the interface is physical or some other form such as a tunnel. From the mobile perspective, that interface can be used for sending L2/L3 traffic out. For CCOA case, this interface has a valid CcoA address. In chained cases, this interface can be a tunnel. > Section 2.2. > > ... > are given a unique identifier and this identifier is called the > binding identifier. The identifier is unique within all the > bindings for a given mobile node. > > [JiK] Unique for a mobile node or one HoA? If a mobile node > had multiple > HoAs BIDs would still be unique? How this would be done? > The binding associates the HoA, interface and the HA. This will be different, if any of these parameters change. So, between the MN and the HA, when using one HoA or more HoA's, a given binding always identifies one set. The MN will not propose the binding id, for one HoA, if the same id is in use for the other HoA. But, it makes sense to change it to "unique per HoA", I agree. > Section 3. > > ... > The mobile node registers to the home agent through each of the > available roaming interfaces. As part of the registration, the > ... > > [JiK] A "roaming interface" is...? > Ok. > ... > The home agent sets up the routing for the mobile node's home > address. The home address will be reachable over any of the > established tunnels for that mobile node. Based on the enabled > traffic policies, the home agent can distribute the > data traffic > over any of those tunnels in any fashion. When there are no > explicit traffic policies in place, the default > routing policy of > per-flow load balancing will be in affect. > > [JiK] I would like to see similar text from a mobile node > point of view. > Sure. > Section 4.1. > > ... > This extension is a non-skippable extension and MAY be > added to the > Registration Request message by the mobile node. There > MUST not be > more than one instance of this extension present in the message. > > [JiK] s/MUST not/MUST NOT > Ok > Interface-Type (If-Type) > > Type of interface through which the mobile node is > connected. > The permitted values for this are from the Access Technology > Type registry. > > [JiK] Where are these interface types defined? I could not find any > mention of a registry etc. > May be 5213 ATT registry. Will add the pointer. > Binding-Id (BID) > > This 16-bit field is the binding identifier. It uniquely > identifies a specific binding of the mobile node, with which > ... > > [JiK] Is it actually per HoA, not per mobile node? > Ok > Interface Bandwidth (If-BW) > > This 16-bit unsigned integer is used for conveying the > available bandwidth of the interface associated with this > request. The bandwidth is specified in kilo-bytes, > fractions > are to be rounded to the nearest integer. > > [JiK] How does the mobile node get this information? If it is just the > "nominal" speed of the interface, this information can be very > misleading and optimistic.. For example a 54MB WLAN behind a 1M > xDSL. > With 802.21, there are IE's to carry such information. > Section 5.1. > > o If the mobile node for connecting to the home link, > uses either a > designated interface or any of the available interfaces to > connect > to the home link and if it detects its home link through any of > those interfaces, then it MUST consider its on the > home link and > SHOULD perform the deregistration procedure. > > [JiK] Did I get it right that if any of the interfaces is on the home > link, then all the other links have to de-register as > well? Or > is it > only that interface that happens to be on the home link? > > Section 5.3. > > ... > node when it is supporting simultaneous bindings for that > registration. When the home agent allows simultaneous > bindings, it > will tunnel a separate copy of each arriving datagram to each of > those care-of addresses, and the mobile node will receive multiple > copies of datagrams destined to it. The operation defined in this > specification allows a mobile node to register from multiple > interfaces using different care-of addresses and have multiple > tunnels from the home agent to each of those care-of addresses and > for distributing the traffic load across those tunnels. This is a > different model than the simultaneous bindings when it > comes to the > ... > > [JiK] Does the mechanism in this specification work with "traditional" > simultaneous bindings? > Yes. The simulcast has no bearing on this. > Section 8. > > When the value for this flag is set to value of 0, multiple > tunnel > support SHOULD be disabled. > > [JiK] Why just SHOULDs ? Isn't it MUST for disabling? In what occasion > the multiple tunnel support could be allowed if it is disabled? > Sure. > Section 9. > > [JiK] Interface type registry is missing? Also, maybe it > could be useful > to describe what range of error codes are used for both > MULTIPLE_TUNNEL_REQUEST_DENIED_BY_HA & > MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA. > Ok > Section 10. > > [JiK] Well, if you DoS a mobile node that has multiple tunnels > connected, > you can DoS the mobile node way harder than just through one > interface & > tunnel ;) > :) Well, I see the positive side :) Thanks for the review. Sri > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 13 16:18:19 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A543A6932; Tue, 13 Jan 2009 16:18:18 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B173A6851 for ; Tue, 13 Jan 2009 01:08:34 -0800 (PST) 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 nQZCRZXS60FH for ; Tue, 13 Jan 2009 01:08:34 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id B2D4A3A677C for ; Tue, 13 Jan 2009 01:08:33 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id b39so291376ugd.15 for ; Tue, 13 Jan 2009 01:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=R/ve/Z4a+aVYu2HweHR2aE21dIrj5GNwY84xisrsYfk=; b=L12bncUzAN0qIF/ZzLdpqE/6tf75hrFYVR3t8cSl6SLSISAK5R3kWYDnroYPyDE7f8 I2gtXLOIRJewbg4uijRKrStpUMB3ikWKiC9LIyQKirUKuSrXI1sRl/oAAfa/MdnXTvJu oJoB7tKiN2XpZ2YL97biTgXVvSG4DGHrbY3d0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=P2Hyk1AkJ6TdheC4cZp0AB9KJCFv3qAbVkv65NOUpYyTn9MFUne4N3Se4KIxT9XTom y+f0M5AADxNBu+lvFhwPO/ingGXlHl8AWa6Qenw1IfPoV99LJ5t4HcV8K9mT9c+Qo7eS BV7yhoAta8Jx/m2ThGzyQ+jXQ8J7TwJo4ji3k= Received: by 10.66.220.12 with SMTP id s12mr1833852ugg.22.1231837697326; Tue, 13 Jan 2009 01:08:17 -0800 (PST) Received: from ke-hupnet229-27.hupnet.helsinki.fi (vallila-gw.hupnet.helsinki.fi [128.214.20.122]) by mx.google.com with ESMTPS id 30sm1125604ugf.13.2009.01.13.01.08.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Jan 2009 01:08:16 -0800 (PST) Message-Id: From: jouni korhonen To: Sri Gundavelli In-Reply-To: <004b01c97552$132c2cc0$d6f6200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 13 Jan 2009 11:08:04 +0200 References: <7E7E6561-7061-4EA3-A1E1-9A0918F27956@gmail.com> <004b01c97552$132c2cc0$d6f6200a@amer.cisco.com> X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Tue, 13 Jan 2009 16:18:18 -0800 Cc: mip4@ietf.org Subject: Re: [Mip4] Comments on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Sri, Thanks for the replies. Got few more things to comment. On Jan 13, 2009, at 9:39 AM, Sri Gundavelli wrote: > Hi Jouni, > > Thanks for the review comments. Please see inline. [snip] > > > >> Interface Bandwidth (If-BW) >> >> This 16-bit unsigned integer is used for conveying the >> available bandwidth of the interface associated with this >> request. The bandwidth is specified in kilo-bytes, >> fractions >> are to be rounded to the nearest integer. >> >> [JiK] How does the mobile node get this information? If it is just >> the >> "nominal" speed of the interface, this information can be very >> misleading and optimistic.. For example a 54MB WLAN behind a 1M >> xDSL. >> > > With 802.21, there are IE's to carry such information. 802.21 would still deliver a local view of the information, which would still be something different than e2e path information. Unless one can assume certain rather closed deployment. I'd like to document to state that If-BW is just an indicative guess at best. > >> Section 5.1. >> >> o If the mobile node for connecting to the home link, >> uses either a >> designated interface or any of the available interfaces to >> connect >> to the home link and if it detects its home link through any of >> those interfaces, then it MUST consider its on the >> home link and >> SHOULD perform the deregistration procedure. >> >> [JiK] Did I get it right that if any of the interfaces is on the home >> link, then all the other links have to de-register as >> well? Or >> is it >> only that interface that happens to be on the home link? >> Seems you missed this? [snap] Cheers, Jouni -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 13 16:23:39 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C103A68FE; Tue, 13 Jan 2009 16:23:39 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EE03A68FE for ; Tue, 13 Jan 2009 16:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 dEQ3EEayZtp6 for ; Tue, 13 Jan 2009 16:23:38 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 317193A684D for ; Tue, 13 Jan 2009 16:23:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,261,1231113600"; d="scan'208";a="59394774" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2009 00:23:23 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0E0NNBO021801; Tue, 13 Jan 2009 16:23:23 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0E0NNms000207; Wed, 14 Jan 2009 00:23:23 GMT Date: Tue, 13 Jan 2009 16:23:23 -0800 (PST) From: Sri Gundavelli To: jouni korhonen In-Reply-To: Message-ID: References: <7E7E6561-7061-4EA3-A1E1-9A0918F27956@gmail.com> <004b01c97552$132c2cc0$d6f6200a@amer.cisco.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2701; t=1231892603; x=1232756603; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[Mip4]=20Comments=20on=20draft-gundavel li-mip4-multiple-tunnel-support-00 |Sender:=20; bh=U9OcoWCeylOWi0Me9Ggg8UIuCHzjXQJXDs0+2zWRXIg=; b=JuV1hcOSAgq+EWQn9wJQOLMoDaXzD3Z+UaV53OQo8W35wQjs+4S3Y/YrZd CcUNB/ilFsVbk4v0P784Ly4v4HaQLe5J5NAu1tUhHTEVinPNu6f4fjS5tgKm Fdo+GM4pJOVCajHDhW++rjAqKao0q8PnTbco/9qO9IL4oZdMDLMbw=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mip4@ietf.org Subject: Re: [Mip4] Comments on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Jouni, Please see inline. On Tue, 13 Jan 2009, jouni korhonen wrote: > Hi Sri, > > Thanks for the replies. Got few more things to comment. > > On Jan 13, 2009, at 9:39 AM, Sri Gundavelli wrote: > >> Hi Jouni, >> >> Thanks for the review comments. Please see inline. > > [snip] > >> >> >> >> > Interface Bandwidth (If-BW) >> > >> > This 16-bit unsigned integer is used for conveying the >> > available bandwidth of the interface associated with this >> > request. The bandwidth is specified in kilo-bytes, >> > fractions >> > are to be rounded to the nearest integer. >> > >> > [JiK] How does the mobile node get this information? If it is just the >> > "nominal" speed of the interface, this information can be very >> > misleading and optimistic.. For example a 54MB WLAN behind a 1M >> > xDSL. >> > >> >> With 802.21, there are IE's to carry such information. > > 802.21 would still deliver a local view of the information, which would > still be something different than e2e path information. Unless one can > assume certain rather closed deployment. I'd like to document to state > that If-BW is just an indicative guess at best. > If the information about the air link is predictable, this should be sufficient, as the bottle neck is in the airlink. I assume .21 can provide that information. However, as you say, its always an indicative guess. Sure, we can add as you suggested. >> >> > Section 5.1. >> > >> > o If the mobile node for connecting to the home link, >> > uses either a >> > designated interface or any of the available interfaces to >> > connect >> > to the home link and if it detects its home link through any of >> > those interfaces, then it MUST consider its on the >> > home link and >> > SHOULD perform the deregistration procedure. >> > >> > [JiK] Did I get it right that if any of the interfaces is on the home >> > link, then all the other links have to de-register as >> > well? Or >> > is it >> > only that interface that happens to be on the home link? >> > > > Seems you missed this? Simultaneous home and roam, I was not sure how important this will be. It can be supported, wanted to avoid too many changes on the HA just to support this feature. If this needed, we can cover this. Regards Sri > > > [snap] > > Cheers, > Jouni > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 13 23:16:15 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697943A6ABC; Tue, 13 Jan 2009 23:16:15 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2F728C153 for ; Tue, 13 Jan 2009 23:16:14 -0800 (PST) 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.688, 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 tNdOT05Nr4Zz for ; Tue, 13 Jan 2009 23:16:14 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id 75E153A6A61 for ; Tue, 13 Jan 2009 23:16:12 -0800 (PST) Received: by bwz14 with SMTP id 14so1291173bwz.13 for ; Tue, 13 Jan 2009 23:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SMO8gh9A6Ou1sszoJVoK3XRw9WCV8j1ClpyQJRRhJoQ=; b=t9kaj7zVTZmXDMwlN+MaxqOBCLrIzFQZ6fyTENRaEMjxHMqGc6y+Rt0TaMf+lHkOBq q0ZtecT5DQ/W2CMtf0JOHVHlwVLqY1ZbH4AcIWUqoXCF8sZkN2/r5u8gSoJOwQPdU6+P vd6d3AbC3SQznvJumOaLCGfLtONC4MDdSXg9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JdrG4cKpCEzR6twykMaa50NIIgX9U2zU6u8KKfVfC9qCw+IuFgjTQjqTXYFl8NYHCq c027F1ff4WWDCJRdLNHOZsKe/6NSPMk6Sn0VcE6k+8UeXk2dLY7kMxQU/NZQ9oMSWq1A JTZ1p+qnSmrUi6W44BL+nQOw10vz183udKzFE= Received: by 10.223.112.204 with SMTP id x12mr5301118fap.70.1231917356545; Tue, 13 Jan 2009 23:15:56 -0800 (PST) Received: by 10.223.108.211 with HTTP; Tue, 13 Jan 2009 23:15:56 -0800 (PST) Message-ID: <3fe59bfe0901132315t13001752m288fe4f546ae0c35@mail.gmail.com> Date: Wed, 14 Jan 2009 09:15:56 +0200 From: "jouni korhonen" To: "Sri Gundavelli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <7E7E6561-7061-4EA3-A1E1-9A0918F27956@gmail.com> <004b01c97552$132c2cc0$d6f6200a@amer.cisco.com> Cc: mip4@ietf.org, jouni korhonen Subject: Re: [Mip4] Comments on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Sri, On Wed, Jan 14, 2009 at 2:23 AM, Sri Gundavelli wrote: > > Hi Jouni, > > Please see inline. >>> >>> > Section 5.1. >>> > > o If the mobile node for connecting to the home link, >>> > uses either a >>> > designated interface or any of the available interfaces to >>> > connect >>> > to the home link and if it detects its home link through any of >>> > those interfaces, then it MUST consider its on the >>> > home link and >>> > SHOULD perform the deregistration procedure. >>> > > [JiK] Did I get it right that if any of the interfaces is on the home >>> > link, then all the other links have to de-register as >>> > well? Or >>> > is it >>> > only that interface that happens to be on the home link? >>> > >> >> Seems you missed this? > > Simultaneous home and roam, I was not sure how important this will be. > It can be supported, wanted to avoid too many changes on the HA just > to support this feature. If this needed, we can cover this. I see. Well, I don't have a strong preference of the final behavior. Minimizing changes to a HA is a good argument ;) However, the case I was thinking of is the following. The MN is registered to a HA via 4 interfaces (all roaming). Let us assume that if1-3 are high bandwidth and if4 is rather poor contributing ~10% of the aggregated bandwidth. If it happens that the if4 enters the home link, all if1-4 get de-registered but only the if4 can continue to exchange traffic between the MN and the HA. This would cause a significant degrease on the aggregated bandwidth... unnecessarily. Cheers, Jouni > > > Regards > Sri -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 14 02:55:17 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7873A6883; Wed, 14 Jan 2009 02:55:17 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68EB3A6883 for ; Wed, 14 Jan 2009 02:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 vL-Lq9LXVAad for ; Wed, 14 Jan 2009 02:55:15 -0800 (PST) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by core3.amsl.com (Postfix) with ESMTP id E1CDB3A686C for ; Wed, 14 Jan 2009 02:55:14 -0800 (PST) Received: by bwz14 with SMTP id 14so1535811bwz.13 for ; Wed, 14 Jan 2009 02:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+CMorY9bs3ERAzFStpUmrZKe1YksJMPSguxAkeGpNE4=; b=BkgdlsdBTOLPQERl1TEh5iCt1vHhFHNp+OXWPo90pFqHagpCEGomuHyIIWCWUuF8K3 /o0lnjT1JVlqD56oFEQX9aALJYqieKPwxrITj/6dQrscGpzj/LS4O3CAoU4bCcvbTPT7 3wE+3lKamzlEmo/5wbtpOa5NzUryEnErtgYOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Imx8iXoJlPoFZaZ38tLRyl8wK7xzW73d4fWNWglvGd3KB1CAUsKruHHt6CVmuMV32C SCfreKViO4lfrCpkfAWwadGAHF0FUDJ2qMOg+tDkK28ik/X2l6vmFsx/zqMBJTpnFhYF XfFRUV9ajLAFU1YcZTFjd71swh50UkWp7YH8Q= MIME-Version: 1.0 Received: by 10.103.172.9 with SMTP id z9mr11776247muo.39.1231930498128; Wed, 14 Jan 2009 02:54:58 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2009 10:54:58 +0000 Message-ID: From: George Tsirtsis To: Sri Gundavelli Cc: mip4@ietf.org Subject: Re: [Mip4] New Version Notification for draft-gundavelli-mip4-multiple-tunnel-support-00 (fwd) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Sri, I just had a look at the draft. Since I was not in the last IETF meeting could you summarize what the plan is with this draft? Is this something the WG considers taking up? If yes, I think it would be useful to spell out what the scope of this work is in comparison to the equivalent work in the MEXT (i.e., MCoA and Flow Movement). I did this early on for DSMIPv4 and it helped things significantly. BTW, I am not sure I like the whole notion of 'Interface bandwidth". This is something notoriously difficult to set right and make sense of, especially on wireless links. Instead the rough link priority adopted in MIPv6-MCoA is easier to deal with and should satisfy your needs, without turning this into a QoS protocol...which would be a nightmare.. Regards George On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli wrote: > > Please comment on this work item. We presented this > at Minneapolis. > > > Sri > > > ---------- Forwarded message ---------- > Date: Mon, 8 Dec 2008 00:51:42 -0800 (PST) > From: IETF I-D Submission Tool > To: sgundave@cisco.com > Cc: kleung@cisco.com > Subject: New Version Notification for > draft-gundavelli-mip4-multiple-tunnel-support-00 > > > A new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-00.txt > has been successfuly submitted by Sri Gundavelli and posted to the IETF > repository. > > Filename: draft-gundavelli-mip4-multiple-tunnel-support > Revision: 00 > Title: Multiple Tunnel Support for Mobile IPv4 > Creation_date: 2008-12-08 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > This document defines extensions to Mobile IPv4 protocol for allowing > a mobile node or a mobile router with multiple interfaces to register > a care-of address for each of the available interfaces and to > simultaneously establish multiple Mobile IP tunnels to the home > agent, each through a different interface path. This capability is > required for enabling a mobile node to utilize all the available > wireless access links and build an higher aggregated data pipe to the > home agent by setting the home address reachability over all of those > tunnel paths. > > > > The IETF Secretariat. > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 15 04:15:02 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BD728C1E3; Thu, 15 Jan 2009 04:15:02 -0800 (PST) X-Original-To: mip4@ietf.org Delivered-To: mip4@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6B6F628C1D8; Thu, 15 Jan 2009 04:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090115121501.6B6F628C1D8@core3.amsl.com> Date: Thu, 15 Jan 2009 04:15:01 -0800 (PST) Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-dsmipv4-10.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mip4-dsmipv4-10.txt Pages : 22 Date : 2009-01-15 This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-10.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-mip4-dsmipv4-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-15040515.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Sat Jan 17 01:51:01 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA2E28C144; Sat, 17 Jan 2009 01:51:00 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5821B28C148 for ; Sat, 17 Jan 2009 01:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 COQk9bri9HSd for ; Sat, 17 Jan 2009 01:50:58 -0800 (PST) Received: from n77a.bullet.mail.sp1.yahoo.com (n77a.bullet.mail.sp1.yahoo.com [98.136.45.24]) by core3.amsl.com (Postfix) with SMTP id 7ADA428C138 for ; Sat, 17 Jan 2009 01:50:58 -0800 (PST) Received: from [69.147.65.173] by n77.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jan 2009 09:50:42 -0000 Received: from [69.147.65.162] by t15.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jan 2009 09:50:42 -0000 Received: from [127.0.0.1] by omp407.mail.sp1.yahoo.com with NNFMP; 17 Jan 2009 09:50:42 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 665393.91835.bm@omp407.mail.sp1.yahoo.com Received: (qmail 70345 invoked by uid 60001); 17 Jan 2009 09:50:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=jGEUfR8TVdXagxw7hu1yBv8NcVAAgYWqe05xs8O4uTzBdUoog+5X8KTUKAPV4QSie/6ARziXCJVI18KcUrQ9GisVACpJfHLnHWuKlwcLhjNPidnLUGnu8ayKOC6PVbRP1qI2HZp7zOz7SE0WVWLKlZ5M5gMZ1rI/oupYhrszOgc=; X-YMail-OSG: iglPFzAVM1mBXb3Q3VlleoWe.Rx8T0BieISbYUh3VF502e4ZUYS7oCijnP0_bpDfFa_et7cM4izTPGars6fwW1oBatOBz2opy7.XUqTOpWxPe5HSicRPc6qjlj3klwtANV3Mj2ReK9QqaOKV4A8Ts4Ff_5AkPXW3rGMguBck_tHl9ZBCwlu1yp2r9KJU9JAzMRf.OYPBLw-- Received: from [67.233.188.239] by web45908.mail.sp1.yahoo.com via HTTP; Sat, 17 Jan 2009 01:50:41 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Sat, 17 Jan 2009 01:50:41 -0800 (PST) From: John Edward To: mip4@ietf.org MIME-Version: 1.0 Message-ID: <385066.70162.qm@web45908.mail.sp1.yahoo.com> Subject: [Mip4] Final call for papers: special session Mobile IP Protocols on at HPCNCS-09 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0482735601==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --===============0482735601== Content-Type: multipart/alternative; boundary="0-1446995686-1232185841=:70162" --0-1446995686-1232185841=:70162 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There is a special session on Mobile IP Protocols at=A02009 International C= onference on High Performance Computing, Networking and Communication Syste= ms (HPCNCS-09) (website: http://www.PromoteResearch.org ) that will be held= during July 13-16 2009 in Orlando, FL, USA. We invite draft paper submissi= ons. The conference will take place at the same time and venue where severa= l other international conferences are taking place. The other conferences i= nclude: =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Artificial Intellig= ence and Pattern Recognition (AIPR-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Automation, Robotic= s and Control Systems (ARCS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Bioinformatics, Com= putational Biology, Genomics and Chemoinformatics (BCBGC-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Enterprise Informat= ion Systems and Web Technologies (EISWT-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Information Securit= y and Privacy (ISP-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Recent Advances in = Information Technology and Applications (RAITA-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Software Engineerin= g Theory and Practice (SETP-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theory and Applicat= ions of Computational Science (TACS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theoretical and Mat= hematical Foundations of Computer Science (TMFCS-09) =A0 The website http://www.PromoteResearch.org contains more details. =A0 Sincerely John Edward Publicity committee =A0 =A0 =A0=0A=0A=0A --0-1446995686-1232185841=:70162 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

There is a special session on Mobile IP Protocols at 2009= International Conference on High Performance = Computing, Networking and Communication Systems (HPCNCS-09) (website= : http://www.PromoteResearch.org ) that will be held during July 13-16 2009 in Orlando= , FL, USA. We invite draft paper submissions. The conference will take plac= e at the same time and venue where several other international conferences = are taking place. The other conferences include:

=B7         <= /FONT>

=B7         =B7         =B7         =B7         =B7         =B7         =B7         =B7          

The website h= ttp://www.PromoteResearch.org contains more details.

 

Sincerely

John Edward

Publicity committee

 

 

 


=0A=0A= =0A=0A --0-1446995686-1232185841=:70162-- --===============0482735601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0482735601==-- From mip4-bounces@ietf.org Mon Jan 19 10:32:03 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D613A6834; Mon, 19 Jan 2009 10:32:03 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76AE3A6834 for ; Mon, 19 Jan 2009 10:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 CyjLJ2amso1r for ; Mon, 19 Jan 2009 10:32:01 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 82C8F3A67E2 for ; Mon, 19 Jan 2009 10:32:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,290,1231113600"; d="scan'208";a="130792746" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2009 18:31:46 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0JIVjmn021219; Mon, 19 Jan 2009 10:31:45 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0JIVjmc015356; Mon, 19 Jan 2009 18:31:45 GMT Date: Mon, 19 Jan 2009 10:31:45 -0800 (PST) From: Sri Gundavelli To: George Tsirtsis In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3820; t=1232389905; x=1233253905; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[Mip4]=20New=20Version=20Notification=2 0for=20draft-gundavelli-mip4-multiple-tunnel-support-00=0A=2 0=20(fwd) |Sender:=20; bh=E+Iu1IQ130zcvPWeo/DltpU9LJj0CpYmTBXBManvR9I=; b=PJ+lEwvapMrjI8yl/MnkmxEIS9yxmGuKCECz1Ztj9rmFBypW951aFYEAAW WCpRud59vT+wk3VocCGxMAz2xnMoTeTeqEiGpa/F2jXXzwIIV91MQ1C6qIEU FaIeU0JjaADdcdHO51JaR/BsnXWbUc+mdznmjhKd+OU5yq0HfVGEw=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mip4@ietf.org Subject: Re: [Mip4] New Version Notification for draft-gundavelli-mip4-multiple-tunnel-support-00 (fwd) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi George, Sorry for the late reply. Please see inline. On Wed, 14 Jan 2009, George Tsirtsis wrote: > Hi Sri, > > I just had a look at the draft. > Since I was not in the last IETF meeting could you summarize what the > plan is with this draft? Is this something the WG considers taking up? > I hope so. That's the plan and there is interest. We need this for our mobile router deployments. > If yes, I think it would be useful to spell out what the scope of this > work is in comparison to the equivalent work in the MEXT (i.e., MCoA > and Flow Movement). I did this early on for DSMIPv4 and it helped > things significantly. > Ok. The problem statement between MCOA4 and MCOA6 is similar. The ability for the mobile to setup multiple tunnels to the home agent through different interfaces, is largely same. The presence of foreign agent/types of registrations, NAT presence introduces some differences and issues. > BTW, I am not sure I like the whole notion of 'Interface bandwidth". > This is something notoriously difficult to set right and make sense > of, especially on wireless links. Instead the rough link priority > adopted in MIPv6-MCoA is easier to deal with and should satisfy your > needs, without turning this into a QoS protocol...which would be a > nightmare.. > The draft is exposing the information about the interface through which a mobile node is attached and marks the binding associated with this attach. The interface type (WiMAX, WiFI, LTE ..etc) will definetly provide a sufficient hint for the home agent. In some radio environments, if the link bandwidth is predictable, it can certainly expose the same to the home agent. I agree with you that its not always predictable, hence it is optional, making it useful only when present. The exposed parameters are sufficient for the tunnel peers to build efficient traffic policies and leverage the links in a much more efficient manner. Sri > Regards > George > > On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli wrote: >> >> Please comment on this work item. We presented this >> at Minneapolis. >> >> >> Sri >> >> >> ---------- Forwarded message ---------- >> Date: Mon, 8 Dec 2008 00:51:42 -0800 (PST) >> From: IETF I-D Submission Tool >> To: sgundave@cisco.com >> Cc: kleung@cisco.com >> Subject: New Version Notification for >> draft-gundavelli-mip4-multiple-tunnel-support-00 >> >> >> A new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-00.txt >> has been successfuly submitted by Sri Gundavelli and posted to the IETF >> repository. >> >> Filename: draft-gundavelli-mip4-multiple-tunnel-support >> Revision: 00 >> Title: Multiple Tunnel Support for Mobile IPv4 >> Creation_date: 2008-12-08 >> WG ID: Independent Submission >> Number_of_pages: 17 >> >> Abstract: >> This document defines extensions to Mobile IPv4 protocol for allowing >> a mobile node or a mobile router with multiple interfaces to register >> a care-of address for each of the available interfaces and to >> simultaneously establish multiple Mobile IP tunnels to the home >> agent, each through a different interface path. This capability is >> required for enabling a mobile node to utilize all the available >> wireless access links and build an higher aggregated data pipe to the >> home agent by setting the home address reachability over all of those >> tunnel paths. >> >> >> >> The IETF Secretariat. >> >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ >> > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 20 07:46:11 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE293A6B69; Tue, 20 Jan 2009 07:46:11 -0800 (PST) X-Original-To: mip4@ietf.org Delivered-To: mip4@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 372FF3A6B23; Tue, 20 Jan 2009 07:46:09 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090120154610.372FF3A6B23@core3.amsl.com> Date: Tue, 20 Jan 2009 07:46:10 -0800 (PST) Cc: mip4 chair , Internet Architecture Board , mip4 mailing list , RFC Editor Subject: [Mip4] Protocol Action: 'Dual Stack Mobile IPv4' to Proposed Standard X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org The IESG has approved the following document: - 'Dual Stack Mobile IPv4 ' as a Proposed Standard This document is the product of the Mobility for IPv4 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-10.txt Technical Summary This is a specification of a simple IPv6 support extension for Mobile IPv6. Full functionality as in Mobile IPv6 is not supported. Working Group Summary This is a product of the MIP4 WG, and a chartered work item in that group. Document Quality This specification has been reviewed by Jari Arkko for the IESG. Personnel The responsible Area Director is Jari Arkko. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jan 20 10:35:29 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E023A6814; Tue, 20 Jan 2009 10:35:29 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3253A6814 for ; Tue, 20 Jan 2009 10:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 lv6gWOJVcqlS for ; Tue, 20 Jan 2009 10:35:28 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 611F23A680B for ; Tue, 20 Jan 2009 10:35:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1232476511!14201514!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19584 invoked from network); 20 Jan 2009 18:35:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 20 Jan 2009 18:35:11 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id n0KIZB9G008618 for ; Tue, 20 Jan 2009 11:35:11 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id n0KIZBjJ021198 for ; Tue, 20 Jan 2009 12:35:11 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id n0KIZA8g021191 for ; Tue, 20 Jan 2009 12:35:10 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 13:35:01 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Host Configuration Thread-Index: Acl7Lc3MAP4oVB1iR82bZZbJgjqV1g== From: "McCann Peter-A001034" To: X-CFilter-Loop: Reflected Cc: Henrik Levkowetz Subject: [Mip4] Host Configuration X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, all, We still have not come to a satisfactory conclusion on the question of host configuration for MIP4 nodes. Recall that we had a working group draft on this topic: http://tools.ietf.org/html/draft-ietf-mip4-gen-ext-04 But we got a comment during last call that we could potentially solve this problem with DHCP. Hui was kind enough to write a draft on this approach: http://tools.ietf.org/html/draft-deng-mip4-host-configuration-00.html Please reply to this note if you have a preference for one draft over the other. We will most likely need to choose one of these approaches rather than standardize both. Thanks, -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 21 15:31:34 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622F628C12C; Wed, 21 Jan 2009 15:31:34 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B16328C12C for ; Wed, 21 Jan 2009 15:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 INJtM5km0Ncs for ; Wed, 21 Jan 2009 15:31:31 -0800 (PST) Received: from beta.eng.utah.edu (beta.eng.utah.edu [155.98.111.99]) by core3.amsl.com (Postfix) with ESMTP id AC87428C104 for ; Wed, 21 Jan 2009 15:31:31 -0800 (PST) Received: from patwari-laptop2.ece.utah.edu ([155.98.26.163]) by beta.eng.utah.edu with esmtpa (Exim 4.63) (envelope-from ) id 1LPlzm-0005Ia-2v for mip4@ietf.org; Wed, 21 Jan 2009 15:56:26 -0700 Message-ID: <4977B043.8000708@ece.utah.edu> Date: Wed, 21 Jan 2009 16:31:15 -0700 From: Neal Patwari User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: mip4@ietf.org Subject: [Mip4] Deadline Extended: DCOSS 2009 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org ** Deadline extended until Monday, 2 Feb ** *********************************************************************** ******* CALL FOR PAPERS ******* ******* The 5th IEEE/ACM International Conference on ******* ******* DISTRIBUTED COMPUTING IN SENSOR SYSTEMS (DCOSS) ******* ******* June 8 - 10, 2009, ******* ******* Marina Del Rey, CA, USA ******* ******* http://www.dcoss.org ******* *********************************************************************** IMPORTANT DATES Submission Deadline: 11:59PM EST Feb 2, 2009 [extended] Notification: March 24, 2009 Camera Ready: March 31, 2009 OVERVIEW Distributed sensor systems have become a highly active research area due to their potential for providing diverse new capabilities. Such systems allow intelligent dense monitoring of physical environments. The focus of this conference is on distributed computing issues in large-scale networked sensor systems (including algorithms, applications, systematic design techniques and tools, and in-network signal and information processing). Authors are invited to submit original unpublished manuscripts that demonstrate current research on computational aspects of distributed sensor systems. Topics of interest include but are not limited to: * Computation and programming models * Energy models, minimization, awareness * Distributed collaborative information processing * Detection and tracking * Theoretical performance analysis: complexity, correctness, scalability * Abstractions for modular design * Fault tolerance and security * Languages, operating systems * Task allocation, reprogramming and reconfiguration * Dynamic resource management * Scalable, heterogeneous architectures (node and system-level) * Middleware interfaces, communication and processing primitives * Design, simulation and optimization tools for deployment and operation * Design automation and application synthesis techniques * closed-loop control for sensing and actuation * Case studies: lessons from real world deployments * Network coding and compression Authors are invited to submit conference papers as described on http://www.dcoss.org/submission.php. Papers should be submitted in (Springer) LNCS format with maximum length 14 pages; this limit corresponds to 6-7 pages in the standard two-column IEEE conference format. GENERAL CO-CHAIRS Viktor K. Prasanna, Univ. of Southern California, USA Jie Wu, Florida Atlantic University, USA VICE GENERAL CHAIR Ivan Stojmenovic, Univ. of Ottawa, Canada PROGRAM CHAIR Bhaskar Krishnamachari, Univ. of Southern California, USA PROGRAM VICE-CHAIRS Subhash Suri (Algorithms and Performance Analysis), Univ. of California at Santa Barbara, USA Wendi Heinzelman (Systems and Applications), Univ. of Rochester, USA Urbashi Mitra (Signal Processing and Information Theory), Univ. of Southern California, USA PROGRAM COMMITTEE (ALGORITHMS AND PERFORMANCE ANALYSIS) * Pankaj Agarwal, Duke University, USA * Jim Aspnes, Yale University, USA * Jit Bose, Carleton University, Canada * Chiranjeeb Buragohain, Amazon, USA * Carla Chiasserini, Politecnico di Torino, Italy * Sandor Fekete, Braunschweig, Germany * Jie Gao, Stony Brook, USA * Martin Haenggi, Univ. of Notre Dame, USA * Ravi Kannan, Microsoft, India * Samir Khuller, Univ. of Maryland, USA * Steve LaValle, UIUC, USA * Mingyan Liu, Univ. of Michigan, USA * Paolo Santi, Univ. of Pisa, Italy * Sanjay Shakkottai, Univ. of Texas at Austin, USA * Peter Widmayer, ETH, Switzerland * Michele Zorzi, Univ. of Padova, Italy * Gil Zussman, Columbia University, USA PROGRAM COMMITTEE (APPLICATIONS AND SYSTEMS) * Tarek Abdelzaher, UIUC, USA * Nael Abu-Ghazaleh, SUNY Binghamton, USA * Stefano Basagni, Northeastern University, USA * Nirupama Bulusu, Portland State University, USA * Tracy Camp, Colorado School of Mines, USA * Andrew Campbell, Dartmouth College, USA * Mihaela Cardei, Florida Atlantic University, USA * Eylem Ekici, Ohio State University, USA * Salil Kanhere, Univ. of New South Wales, Australia * Holger Karl, Univ. of Paderborn, Germany * Dilip Krishnaswamy, Qualcomm, USA * Cecilia Mascolo, Cambridge University, UK * Chiara Petrioli, Univ. of Rome "La Sapienza", Italy * Joe Polastre, Sentilla, USA * Andreas Savvides, Yale University, USA * Curt Schurgers, UCSD, USA * Rajeev Shorey, GM Research, India * Krishna Sivalingam, UMBC, USA * Violet Syrotiuk, Arizona State University, USA * Sameer Tilak, San Diego Supercomputer, UCSD, USA * Cedric Westphal, DoCoMo Labs, USA * Ying Zhang, Xerox PARC, USA PROGRAM COMMITTEE (SIGNAL PROCESSING AND INFORMATION THEORY) * Jean Francois Chamberland, Texas A&M University, USA * Alex Dimakis, California Institute of Technology, USA * Stark Draper, Univ. of Wisconsin, Madison, USA * Emre Ertin, Ohio State University, USA * John Fisher, Massachusetts Institute of Technology, USA * Massimo Franceschetti, Univ. of California, San Diego, USA * Michael Gastpar, Univ. of California, Berkeley, USA * Dennis Goeckel, Univ. of Massachusetts, Amherst, USA * Prakash Ishwar, Boston University, USA * Tom Luo, Univ. of Minnesota, USA * Ivana Maric, Stanford University, USA * Rob Nowak, Univ. of Wisconsin, Madison, USA * Antonio Ortega, Univ. of Southern California, USA * Ashu Sabharwal, Rice University, USA * Anna Scaglione, Univ. of California, Davis, USA * Aaron Wagner, Cornell University, USA * Qing Zhao, Univ. of California, Davis, USA SPONSORED BY: IEEE Computer Society Technical Committee on Parallel Processing (TCPP) IEEE Computer Society Technical Committee on Distributed Processing (TCDP) Held in co-operation with ACM SIGARCH, ACM SIGBED, European Association for Theoretical Computer Science (EATCS) and IFIP WG 11.3. WORKSHOPS The following 7 Workshops have been confirmed for DCOSS '09: # Third International Workshop on Localized Algorithms and Protocols for Wireless Sensor Networks (LOCALGOS) Chair: Ivan Stojmenovic, University of Ottawa, Canada # Second International Workshop on Sensor Network Engineering (IWSNE) Co-Chairs: Stefan Fischer, University of Luebeck, Germany Dennis Pfisterer, University of Luebeck, Germany # Second Workshop on Energy in Wireless Sensor Networks (WEWSN) Chair: Christian Schindelhauer, University of Freiburg, Germany Co-Chair: Stefan Roehrup, University of Freiburg, Germany # Third International Workshop on Information Theory for Sensor Networks Chairs: Joao Barros, Universidade do Porto, Portugal Sandeep Pradhan, University of Michigan, USA # International Workshop on Robotic Wireless Sensor Networks Chairs: Andreas Terzis, Johns Hopkins University, USA Volkan Isler, University of Minnesota, USA # Knowledge Discovery from Sensor Network Data (KDSND), Chair: Alfredo Cuzzocrea, University of Calabria, Italy # International Workshop on Integration of the Real World and the Future Internet (RWI), Co-Chairs: Manfred Hauswirth, DERI Galway, Ireland Mirko Presser, University of Surrey, UK Srdjan Krco, Ericsson Ireland. The DCOSS '09 Workshops Proceedings Volume will include full text versions of accepted papers. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jan 21 20:43:57 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375043A68E3; Wed, 21 Jan 2009 20:43:57 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736983A68E3 for ; Wed, 21 Jan 2009 20:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 pqaaO10F-KNA for ; Wed, 21 Jan 2009 20:43:55 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3A1043A67AB for ; Wed, 21 Jan 2009 20:43:54 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0M4dhR24943; Thu, 22 Jan 2009 04:39:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 22:43:21 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Host Configuration Thread-Index: Acl7Lc3MAP4oVB1iR82bZZbJgjqV1gBGH9wg References: From: "Ahmad Muhanna" To: "McCann Peter-A001034" , Cc: Henrik Levkowetz Subject: Re: [Mip4] Host Configuration X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, Pete, I read both drafts and it seems to me that these two drafts are quite different. Let me explain. 1. draft, draft-ietf-mip4-gen-ext, as we know have a very specific proposal for a new extension which can be used during the MIP registration to allocate different host configuration parameters. Although in the past there was a long debate about the use of this extension which somewhat overlaps with DHCP protocol but I personally have no issue against this draft which addresses a very specific issue. 2. Concerning draft, draft-deng-mip4-host-configuration, and as we discussed during the last two IETF meetings, it does not introduce any new mechanism, however, it explains how RFC3344 and RFC3024 can be used to deliver DHCP packets to the DHCP server in the home network, in other words, it is an example on how RFC3344 and RFC3024 can be used to deliver DHCP packets to the home network and eventually deliver the DHCP response back to the mobile node. On the other hand, this draft build on the case that "encapsulating delivery style" is mandated in the FA CoA case and that is a problem. In other words, the draft does not address the serious disadvantages of the use of "encapsulating delivery style" which produces an big overhead on every unicast packet which is required to be delivered encapsulated to the FA. Finally, as we discussed in the last IETF meeting, draft-chakrabarti-mip4-mcbc addresses the handling and delivery of Multicast Broadcast packets to both the foreign and home network in a more fundamental way by enabling the negotiation of a new encapsulation mechanism. In brief it gives the MN the power to define which domain (foreign or home) is the target for the MCBC packet without the overhead as in "encapsulating delivery style". The authors of draft-chakrabarti-mip4-mcbc did not present the document in the context of host configuration but in a broader scope which fundamentally addresses all MCBC communication including DHCP. My 2 cents. Regards, Ahmad > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of McCann Peter-A001034 > Sent: Tuesday, January 20, 2009 7:35 PM > To: mip4@ietf.org > Cc: Henrik Levkowetz > Subject: [Mip4] Host Configuration > > Hi, all, > > We still have not come to a satisfactory conclusion on the > question of host configuration for MIP4 nodes. Recall that > we had a working group draft on this topic: > > http://tools.ietf.org/html/draft-ietf-mip4-gen-ext-04 > > But we got a comment during last call that we could > potentially solve this problem with DHCP. Hui was kind > enough to write a draft on this approach: > > http://tools.ietf.org/html/draft-deng-mip4-host-configuration-00.html > > Please reply to this note if you have a preference for one > draft over the other. We will most likely need to choose one > of these approaches rather than standardize both. > > Thanks, > > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jan 22 02:53:00 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D103A68C7; Thu, 22 Jan 2009 02:53:00 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0ED3A68C7 for ; Thu, 22 Jan 2009 02:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, 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 0mFqh2Wn5plx for ; Thu, 22 Jan 2009 02:52:58 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id AB3233A68BA for ; Thu, 22 Jan 2009 02:52:58 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so4200753rvf.49 for ; Thu, 22 Jan 2009 02:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=DKr1c9HdTd4/QWrT0+Y+oDNRCWtKg7lCN1E/robQE+U=; b=oFbpcI/qb8LaD56MSEX7MWHDt/tXmhZv3Gw5WhEaMtrI3mo5PXsU2XpU/0YsBfCpb9 hcJnuwPHxp0qQF51DwMkJj6pHRLSFdWHKTpswtCbDxLnLepN2zB4VPULMRWPEPuc3DrW eJRI6QTbb0cjaaNIYlXKXx5qz8R+6T4FjpStI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=DYxGGOaVipQN4tzvwl/KLNDehYent4msL3aLKjwAH+WqsFa9UsD/CYwC9SXtjQShKW UdMB++VEzgVrUgBmej6qCavonFYOcVXmTYo9RunrAYQ0tOhQj1fW1vZ6l0Qh8inseZ83 Fk72MKUYBFqHagcTlQUTP2cMM/gIST2ZyOioI= MIME-Version: 1.0 Received: by 10.114.24.1 with SMTP id 1mr6433878wax.179.1232621562092; Thu, 22 Jan 2009 02:52:42 -0800 (PST) Date: Thu, 22 Jan 2009 18:52:41 +0800 Message-ID: <1d38a3350901220252y17d6f14cs23b107afd22d6eb2@mail.gmail.com> From: Hui Deng To: Sri Gundavelli Cc: mip4@ietf.org Subject: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0646262710==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --===============0646262710== Content-Type: multipart/alternative; boundary=001485f3be6259dd1f0461101215 --001485f3be6259dd1f0461101215 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Sri, I have several questions regarding to your draft. 1) will you use the same AE between HA and MN on different interfaces? 2) how do you generate a label for each interface? 3) Where does the access Technology Type Registry is defined? 4) why don't allow mobile node use multiple interface when one of it stay at home? thanks -Hui 2009/1/20 Sri Gundavelli > Hi George, > > Sorry for the late reply. Please see inline. > > > On Wed, 14 Jan 2009, George Tsirtsis wrote: > > Hi Sri, >> >> I just had a look at the draft. >> Since I was not in the last IETF meeting could you summarize what the >> plan is with this draft? Is this something the WG considers taking up? >> >> > I hope so. That's the plan and there is interest. We need this for > our mobile router deployments. > > > If yes, I think it would be useful to spell out what the scope of this >> work is in comparison to the equivalent work in the MEXT (i.e., MCoA >> and Flow Movement). I did this early on for DSMIPv4 and it helped >> things significantly. >> >> > Ok. The problem statement between MCOA4 and MCOA6 is similar. The > ability for the mobile to setup multiple tunnels to the home agent > through different interfaces, is largely same. The presence of foreign > agent/types of registrations, NAT presence introduces some differences > and issues. > > > BTW, I am not sure I like the whole notion of 'Interface bandwidth". >> This is something notoriously difficult to set right and make sense >> of, especially on wireless links. Instead the rough link priority >> adopted in MIPv6-MCoA is easier to deal with and should satisfy your >> needs, without turning this into a QoS protocol...which would be a >> nightmare.. >> >> > > The draft is exposing the information about the interface through which > a mobile node is attached and marks the binding associated with this > attach. The interface type (WiMAX, WiFI, LTE ..etc) will definetly provide > a sufficient hint for the home agent. In some radio environments, if > the link bandwidth is predictable, it can certainly expose the same to > the home agent. I agree with you that its not always predictable, hence > it is optional, making it useful only when present. The exposed parameters > are sufficient for the tunnel peers to build efficient traffic policies > and leverage the links in a much more efficient manner. > > Sri > > > > > > > > Regards >> George >> >> On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli >> wrote: >> >>> >>> Please comment on this work item. We presented this >>> at Minneapolis. >>> >>> >>> Sri >>> >>> >>> ---------- Forwarded message ---------- >>> Date: Mon, 8 Dec 2008 00:51:42 -0800 (PST) >>> From: IETF I-D Submission Tool >>> To: sgundave@cisco.com >>> Cc: kleung@cisco.com >>> Subject: New Version Notification for >>> draft-gundavelli-mip4-multiple-tunnel-support-00 >>> >>> >>> A new version of I-D, >>> draft-gundavelli-mip4-multiple-tunnel-support-00.txt >>> has been successfuly submitted by Sri Gundavelli and posted to the IETF >>> repository. >>> >>> Filename: draft-gundavelli-mip4-multiple-tunnel-support >>> Revision: 00 >>> Title: Multiple Tunnel Support for Mobile IPv4 >>> Creation_date: 2008-12-08 >>> WG ID: Independent Submission >>> Number_of_pages: 17 >>> >>> Abstract: >>> This document defines extensions to Mobile IPv4 protocol for allowing >>> a mobile node or a mobile router with multiple interfaces to register >>> a care-of address for each of the available interfaces and to >>> simultaneously establish multiple Mobile IP tunnels to the home >>> agent, each through a different interface path. This capability is >>> required for enabling a mobile node to utilize all the available >>> wireless access links and build an higher aggregated data pipe to the >>> home agent by setting the home address reachability over all of those >>> tunnel paths. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> -- >>> Mip4 mailing list: Mip4@ietf.org >>> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>> Supplemental site: http://www.mip4.org/ >>> >>> >> -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > --001485f3be6259dd1f0461101215 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Sri,
 
I have several questions regarding to your draft.
 
1) will you use the same AE between HA and MN on different interfaces?=
2) how do you generate a label for each interface?
3) Where does the access Technology Type Registry is defined?
4) why don't allow mobile node use multiple interface when one of = it stay at home?
 
thanks
 
-Hui

2009/1/20 Sri Gundavelli <<= a href=3D"mailto:sgundave@cisco.com">sgundave@cisco.com>
Hi George,

Sorry for the = late reply. Please see inline.=20



On Wed, 14 Jan 2009, George Tsirtsis wrot= e:

Hi Sri,

I just had a look= at the draft.
Since I was not in the last IETF meeting could you summar= ize what the
plan is with this draft? Is this something the WG considers taking up?
<= br>

I hope so. That's the plan and there is inter= est. We need this for
our mobile router deployments.=20



If yes, I think it would be usef= ul to spell out what the scope of this
work is in comparison to the equi= valent work in the MEXT (i.e., MCoA
and Flow Movement). I did this early on for DSMIPv4 and it helped
things= significantly.


Ok. The problem statement bet= ween MCOA4 and MCOA6 is similar. The
ability for the mobile to setup mul= tiple tunnels to the home agent
through different interfaces, is largely same. The presence of foreign
a= gent/types of registrations, NAT presence introduces some differences
an= d issues.=20



BTW, I am not sure I like the wh= ole notion of 'Interface bandwidth".
This is something notoriou= sly difficult to set right and make sense
of, especially on wireless links. Instead the rough link priority
adopte= d in MIPv6-MCoA is easier to deal with and should satisfy your
needs, wi= thout turning this into a QoS protocol...which would be a
nightmare..


The draft is exposing the information about = the interface through which
a mobile node is attached and marks the bind= ing associated with this
attach. The interface type (WiMAX, WiFI, LTE ..= etc) will definetly provide
a sufficient hint for the home agent. In some radio environments, if
the= link bandwidth is predictable, it can certainly expose the same to
the = home agent. I agree with you that its not always predictable, hence
it is optional, making it useful only when present. The exposed parameters<= br>are sufficient for the tunnel peers to build efficient traffic policies<= br>and leverage the links in a much more efficient manner.

Sri=20







Regards
George

On Wed,= Dec 10, 2008 at 3:25 AM, Sri Gundavelli <sgundave@cisco.com> wrote:

Please comment on this work = item. We presented this
at Minneapolis.


Sri


------= ---- Forwarded message ----------
Date: Mon,  8 Dec 2008 00:51:42 -0800 (PST)
From: IETF I-D Submissi= on Tool <idsu= bmission@ietf.org>
To: sgundave@cisco.com
Cc: kleung@cisco.com<= /a>
Subject: New Version Notification for
  draft-gundavelli-mip= 4-multiple-tunnel-support-00


A new version of I-D, draft-gundave= lli-mip4-multiple-tunnel-support-00.txt
has been successfuly submitted by Sri Gundavelli and posted to the IETF
= repository.

Filename:        draft-gundavelli-mi= p4-multiple-tunnel-support
Revision:        00
Ti= tle:           Multiple Tunnel Support for Mobile = IPv4
Creation_date:   2008-12-08
WG ID:         &nbs= p; Independent Submission
Number_of_pages: 17

Abstract:
This d= ocument defines extensions to Mobile IPv4 protocol for allowing
a mobile= node or a mobile router with multiple interfaces to register
a care-of address for each of the available interfaces and to
simultaneo= usly establish multiple Mobile IP tunnels to the home
agent, each throug= h a different interface path.  This capability is
required for enab= ling a mobile node to utilize all the available
wireless access links and build an higher aggregated data pipe to the
ho= me agent by setting the home address reachability over all of those
tunn= el paths.



The IETF Secretariat.


--
Mip4 mailin= g list: Mip4@ietf.org
 Web interface: https://www.ietf.org/mailman/listinfo/mip4
 = Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http:= //www.mip4.org/


--
Mip4 mailing= list: Mip4@ietf.org=
  Web interface: https://www.ietf.org/mailman/listinfo/mip4
 = ;  Charter page: http://www.ietf.org/html.charters/mip4-charter= .html
Supplemental site: http:= //www.mip4.org/

--001485f3be6259dd1f0461101215-- --===============0646262710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0646262710==-- From mip4-bounces@ietf.org Fri Jan 23 08:49:46 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B513B3A6929; Fri, 23 Jan 2009 08:49:46 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACCE3A6880 for ; Fri, 23 Jan 2009 08:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Tdp+YDp-ExbU for ; Fri, 23 Jan 2009 08:49:34 -0800 (PST) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id 796113A6929 for ; Fri, 23 Jan 2009 08:49:34 -0800 (PST) Received: (qmail 88399 invoked by uid 60001); 23 Jan 2009 16:49:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=CIKpNFnzwpokbxp5pfDWoc2vzoREMoWy6zSvh1LyID0OzHbtAZJmclDfn0AkZWJc4e8DtoygZe98XAd60YlLYJ7UHmtq+TCWtU2OpVrQQc0OP41tsJHE1a21z/xpbouDT0NlANVFxuxBWrOOZVsMN4Zz6/hVM8xSTqzsGcq7kfg=; X-YMail-OSG: VxNZangVM1kkvi2e9LYIS5CznH0JW0IZ4JnxMLCM4EVhzI0pSLryg5FJkwNSCpyTJSSfk7_usF3390MR0Kuqqm6YC_EfElOkszPLdPq85z9747i4rInlZ9kn_F0qgGW4KISb_3Wjz9_J.HbO4ouRBiwiY.VymebInCBm7RaSY9YNteXlcgqe2iUPekgX8.lfI6Qv8Zkxt8NioP8- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Fri, 23 Jan 2009 08:49:17 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1d38a3350901220252y17d6f14cs23b107afd22d6eb2@mail.gmail.com> Date: Fri, 23 Jan 2009 08:49:17 -0800 (PST) From: Behcet Sarikaya To: Hui Deng , Sri Gundavelli MIME-Version: 1.0 Message-ID: <868721.88015.qm@web111408.mail.gq1.yahoo.com> Cc: mip4@ietf.org Subject: Re: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1233678238==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --===============1233678238== Content-Type: multipart/alternative; boundary="0-1446792345-1232729357=:88015" --0-1446792345-1232729357=:88015 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hui,=0A=A0 Access technology type values are registered at IANA website = at:=0Ahttp://www.iana.org/assignments/mobility-parameters=0ASri can answer = the other questions you have.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A_____= ___________________________=0AFrom: Hui Deng =0ATo: Sr= i Gundavelli =0ACc: mip4@ietf.org=0ASent: Thursday, Jan= uary 22, 2009 4:52:41 AM=0ASubject: [Mip4] Questions on draft-gundavelli-mi= p4-multiple-tunnel-support-00=0A=0A=0AHi, Sri,=0A=0AI have several question= s=A0regarding to your draft.=0A=0A1) will you use the same AE between HA an= d MN on different interfaces?=0A2) how do you generate a label for each int= erface?=0A3) Where does the access Technology Type Registry is defined?=0A4= ) why don't allow mobile node use multiple interface when one of it stay at= home?=0A=0Athanks=0A=0A-Hui=0A=0A=0A2009/1/20 Sri Gundavelli =0A=0AHi George,=0A=0ASorry for the late reply. Please see inline. = =0A=0A=0A=0AOn Wed, 14 Jan 2009, George Tsirtsis wrote:=0A=0A=0AHi Sri,=0A= =0AI just had a look at the draft.=0ASince I was not in the last IETF meeti= ng could you summarize what the=0Aplan is with this draft? Is this somethin= g the WG considers taking up?=0A=0A=0AI hope so. That's the plan and there = is interest. We need this for=0Aour mobile router deployments. =0A=0A=0A=0A= =0AIf yes, I think it would be useful to spell out what the scope of this= =0Awork is in comparison to the equivalent work in the MEXT (i.e., MCoA=0Aa= nd Flow Movement). I did this early on for DSMIPv4 and it helped=0Athings s= ignificantly.=0A=0A=0AOk. The problem statement between MCOA4 and MCOA6 is = similar. The=0Aability for the mobile to setup multiple tunnels to the home= agent=0Athrough different interfaces, is largely same. The presence of for= eign=0Aagent/types of registrations, NAT presence introduces some differenc= es=0Aand issues. =0A=0A=0A=0A=0ABTW, I am not sure I like the whole notion = of 'Interface bandwidth".=0AThis is something notoriously difficult to set = right and make sense=0Aof, especially on wireless links. Instead the rough = link priority=0Aadopted in MIPv6-MCoA is easier to deal with and should sat= isfy your=0Aneeds, without turning this into a QoS protocol...which would b= e a=0Anightmare..=0A=0A=0A=0AThe draft is exposing the information about th= e interface through which=0Aa mobile node is attached and marks the binding= associated with this=0Aattach. The interface type (WiMAX, WiFI, LTE ..etc)= will definetly provide=0Aa sufficient hint for the home agent. In some rad= io environments, if=0Athe link bandwidth is predictable, it can certainly e= xpose the same to=0Athe home agent. I agree with you that its not always pr= edictable, hence=0Ait is optional, making it useful only when present. The = exposed parameters=0Aare sufficient for the tunnel peers to build efficient= traffic policies=0Aand leverage the links in a much more efficient manner.= =0A=0ASri =0A=0A=0A=0A=0A=0A=0A=0A=0ARegards=0AGeorge=0A=0AOn Wed, Dec 10, = 2008 at 3:25 AM, Sri Gundavelli wrote:=0A=0A=0APlease = comment on this work item. We presented this=0Aat Minneapolis.=0A=0A=0ASri= =0A=0A=0A---------- Forwarded message ----------=0ADate: Mon, =A08 Dec 2008= 00:51:42 -0800 (PST)=0AFrom: IETF I-D Submission Tool =0ATo: sgundave@cisco.com=0ACc: kleung@cisco.com=0ASubject: New Version = Notification for=0A=A0 draft-gundavelli-mip4-multiple-tunnel-support-00=0A= =0A=0AA new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-0= 0.txt=0Ahas been successfuly submitted by Sri Gundavelli and posted to the = IETF=0Arepository.=0A=0AFilename: =A0 =A0 =A0 =A0draft-gundavelli-mip4-mult= iple-tunnel-support=0ARevision: =A0 =A0 =A0 =A000=0ATitle: =A0 =A0 =A0 =A0 = =A0 Multiple Tunnel Support for Mobile IPv4=0ACreation_date: =A0 2008-12-08= =0AWG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission=0ANumber_of_pages: 17= =0A=0AAbstract:=0AThis document defines extensions to Mobile IPv4 protocol = for allowing=0Aa mobile node or a mobile router with multiple interfaces to= register=0Aa care-of address for each of the available interfaces and to= =0Asimultaneously establish multiple Mobile IP tunnels to the home=0Aagent,= each through a different interface path. =A0This capability is=0Arequired = for enabling a mobile node to utilize all the available=0Awireless access l= inks and build an higher aggregated data pipe to the=0Ahome agent by settin= g the home address reachability over all of those=0Atunnel paths.=0A=0A=0A= =0AThe IETF Secretariat.=0A=0A=0A--=0AMip4 mailing list: Mip4@ietf.org=0A= =A0Web interface: https://www.ietf.org/mailman/listinfo/mip4=0A=A0 Charter = page: http://www.ietf.org/html.charters/mip4-charter.html=0ASupplemental si= te: http://www.mip4.org/=0A=0A=0A--=0AMip4 mailing list: Mip4@ietf.org=0A= =A0 Web interface: https://www.ietf.org/mailman/listinfo/mip4=0A=A0 =A0Char= ter page: http://www.ietf.org/html.charters/mip4-charter.html=0ASupplementa= l site: http://www.mip4.org/=0A=0A=0A --0-1446792345-1232729357=:88015 Content-Type: text/html; charset=us-ascii
Hi Hui,
  Access technology type values are registered at IANA website at:
Sri can answer the other questions you have.
 
Regards,
 
Behcet

From: Hui Deng <denghui02@gmail.com>
To: Sri Gundavelli <sgundave@cisco.com>
Cc: mip4@ietf.org
Sent: Thursday, January 22, 2009 4:52:41 AM
Subject: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00

Hi, Sri,
 
I have several questions regarding to your draft.
 
1) will you use the same AE between HA and MN on different interfaces?
2) how do you generate a label for each interface?
3) Where does the access Technology Type Registry is defined?
4) why don't allow mobile node use multiple interface when one of it stay at home?
 
thanks
 
-Hui

2009/1/20 Sri Gundavelli <sgundave@cisco.com>
Hi George,

Sorry for the late reply. Please see inline.



On Wed, 14 Jan 2009, George Tsirtsis wrote:

Hi Sri,

I just had a look at the draft.
Since I was not in the last IETF meeting could you summarize what the
plan is with this draft? Is this something the WG considers taking up?


I hope so. That's the plan and there is interest. We need this for
our mobile router deployments.



If yes, I think it would be useful to spell out what the scope of this
work is in comparison to the equivalent work in the MEXT (i.e., MCoA
and Flow Movement). I did this early on for DSMIPv4 and it helped
things significantly.


Ok. The problem statement between MCOA4 and MCOA6 is similar. The
ability for the mobile to setup multiple tunnels to the home agent
through different interfaces, is largely same. The presence of foreign
agent/types of registrations, NAT presence introduces some differences
and issues.



BTW, I am not sure I like the whole notion of 'Interface bandwidth".
This is something notoriously difficult to set right and make sense
of, especially on wireless links. Instead the rough link priority
adopted in MIPv6-MCoA is easier to deal with and should satisfy your
needs, without turning this into a QoS protocol...which would be a
nightmare..



The draft is exposing the information about the interface through which
a mobile node is attached and marks the binding associated with this
attach. The interface type (WiMAX, WiFI, LTE ..etc) will definetly provide
a sufficient hint for the home agent. In some radio environments, if
the link bandwidth is predictable, it can certainly expose the same to
the home agent. I agree with you that its not always predictable, hence
it is optional, making it useful only when present. The exposed parameters
are sufficient for the tunnel peers to build efficient traffic policies
and leverage the links in a much more efficient manner.

Sri







Regards
George

On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli <sgundave@cisco.com> wrote:

Please comment on this work item. We presented this
at Minneapolis.


Sri


---------- Forwarded message ----------
Date: Mon,  8 Dec 2008 00:51:42 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: sgundave@cisco.com
Cc: kleung@cisco.com
Subject: New Version Notification for
  draft-gundavelli-mip4-multiple-tunnel-support-00


A new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-00.txt
has been successfuly submitted by Sri Gundavelli and posted to the IETF
repository.

Filename:        draft-gundavelli-mip4-multiple-tunnel-support
Revision:        00
Title:           Multiple Tunnel Support for Mobile IPv4
Creation_date:   2008-12-08
WG ID:           Independent Submission
Number_of_pages: 17

Abstract:
This document defines extensions to Mobile IPv4 protocol for allowing
a mobile node or a mobile router with multiple interfaces to register
a care-of address for each of the available interfaces and to
simultaneously establish multiple Mobile IP tunnels to the home
agent, each through a different interface path.  This capability is
required for enabling a mobile node to utilize all the available
wireless access links and build an higher aggregated data pipe to the
home agent by setting the home address reachability over all of those
tunnel paths.



The IETF Secretariat.


--
Mip4 mailing list: Mip4@ietf.org
 Web interface: https://www.ietf.org/mailman/listinfo/mip4
  Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/


--
Mip4 mailing list: Mip4@ietf.org
  Web interface: https://www.ietf.org/mailman/listinfo/mip4
   Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/


--0-1446792345-1232729357=:88015-- --===============1233678238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1233678238==-- From mip4-bounces@ietf.org Fri Jan 23 13:16:23 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FCF3A693A; Fri, 23 Jan 2009 13:16:23 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727D63A6873 for ; Fri, 23 Jan 2009 13:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 28EstaZsOpnF for ; Fri, 23 Jan 2009 13:16:21 -0800 (PST) Received: from n56a.bullet.mail.sp1.yahoo.com (n56a.bullet.mail.sp1.yahoo.com [98.136.45.3]) by core3.amsl.com (Postfix) with SMTP id 9B0553A693A for ; Fri, 23 Jan 2009 13:16:21 -0800 (PST) Received: from [216.252.122.219] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 23 Jan 2009 21:16:05 -0000 Received: from [69.147.65.155] by t4.bullet.sp1.yahoo.com with NNFMP; 23 Jan 2009 21:16:05 -0000 Received: from [127.0.0.1] by omp403.mail.sp1.yahoo.com with NNFMP; 23 Jan 2009 21:16:05 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 207460.51111.bm@omp403.mail.sp1.yahoo.com Received: (qmail 19361 invoked by uid 60001); 23 Jan 2009 21:16:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=5cpHBSf44+A4fgPmtDoL/qxOQOxkSZru5OeX6sM1ry/QMr92jayi8Oi/aNfgwwxGjLSSg9gq9BSo9ka46kjDgQKx0Fh9AYhwZFb/Ka8XO85Ji8TrxwGp7coJiubbedjg3+5L5+fY5oDURmW4qF/IfTtgGaBdMWbBxY2PeCbRX2c=; X-YMail-OSG: yefzHAEVM1m.7enh5B7MJq2s0fXEjTZc_rRHlsWIT18Xv6HQoGpV6EJQ4v1n_FJ51QBJKlHDT5Xru4r7iYl_SrHGGNmKM.LL6Jh97YOmyO79tfjAbnZbgsz9F.P25iiGlH3Kcl2.Ry8jqWq_dFUG7B4Lp5UuGxukg.myuTQ3b0F4dyu7g3wMjWevmMI7ogozyQGJ9l91tw-- Received: from [67.233.188.239] by web45906.mail.sp1.yahoo.com via HTTP; Fri, 23 Jan 2009 13:16:04 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Fri, 23 Jan 2009 13:16:04 -0800 (PST) From: John Edward To: mip4@ietf.org MIME-Version: 1.0 Message-ID: <609257.18248.qm@web45906.mail.sp1.yahoo.com> Subject: [Mip4] Final call for papers: Special session on Mobile IP Protocols at HPCNCS-09 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0777983472==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --===============0777983472== Content-Type: multipart/alternative; boundary="0-808053076-1232745364=:18248" --0-808053076-1232745364=:18248 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There is a =A0Special session on=A0Mobile IP Protocols at the 2009 Internat= ional Conference on High Performance Computing, Networking and Communicatio= n Systems (HPCNCS-09) (website: http://www.PromoteResearch.org ) that will = be held during July 13-16 2009 in Orlando, FL, USA. We invite draft paper s= ubmissions. The conference will take place at the same time and venue where= several other international conferences are taking place. The other confer= ences include: =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Artificial Intellig= ence and Pattern Recognition (AIPR-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Automation, Robotic= s and Control Systems (ARCS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Bioinformatics, Com= putational Biology, Genomics and Chemoinformatics (BCBGC-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Enterprise Informat= ion Systems and Web Technologies (EISWT-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Information Securit= y and Privacy (ISP-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Recent Advances in = Information Technology and Applications (RAITA-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Software Engineerin= g Theory and Practice (SETP-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theory and Applicat= ions of Computational Science (TACS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theoretical and Mat= hematical Foundations of Computer Science (TMFCS-09) =A0 The website http://www.PromoteResearch.org contains more details. =A0 Sincerely John Edward Publicity committee =A0 =A0 =A0=0A=0A=0A --0-808053076-1232745364=:18248 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

There is a  S= pecial session on Mobil= e IP Protocols at the 2009 Internationa= l Conference on High Performance Computing, Networking and Communication Sy= stems (HPCNCS-09) (website: http://www.PromoteResearch.org ) that will be held during July= 13-16 2009 in Orlando, FL, USA. We invite draft paper submissions. The con= ference will take place at the same time and venue where several other inte= rnational conferences are taking place. The other conferences include:=

=B7         <= /FONT>

=B7         =B7         =B7         =B7         =B7         =B7         =B7         =B7          

The website h= ttp://www.PromoteResearch.org contains more details.

 

Sincerely

John Edward

Publicity committee

 

 

 


=0A=0A = --0-808053076-1232745364=:18248-- --===============0777983472== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0777983472==-- From mip4-bounces@ietf.org Sun Jan 25 10:36:21 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2930D3A68BF; Sun, 25 Jan 2009 10:36:21 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAE628C0E3 for ; Sun, 25 Jan 2009 10:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 4Emst2esHRlT for ; Sun, 25 Jan 2009 10:36:19 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0106D3A6805 for ; Sun, 25 Jan 2009 10:36:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,322,1231113600"; d="scan'208";a="130870837" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 25 Jan 2009 18:35:57 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0PIZvNB014742; Sun, 25 Jan 2009 10:35:57 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0PIZvFH022756; Sun, 25 Jan 2009 18:35:57 GMT Date: Sun, 25 Jan 2009 10:35:57 -0800 (PST) From: Sri Gundavelli To: Behcet Sarikaya In-Reply-To: <868721.88015.qm@web111408.mail.gq1.yahoo.com> Message-ID: References: <1d38a3350901220252y17d6f14cs23b107afd22d6eb2@mail.gmail.com> <868721.88015.qm@web111408.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1232908557=:17280" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5531; t=1232908557; x=1233772557; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[Mip4]=20Questions=20on=20draft-gundave lli-mip4-multiple-tunnel-support-00 |Sender:=20; bh=+O2PlFxdqxpxnd2iOGThGjqtWs0vVLbGM9RqRI+sFDA=; b=iVGIMgKVR6V1wux/cVKAdkQW4ItEAUyV041ZHUxy0k7aR7LQi6CPa+KYw6 H/MA+cFQ4Xpu/o5D2Zq5Cn4IAlHPNx2K/mSCZZwacWwHIwZxk3rxENzhjSiM Lnlku/TvTD; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Hui Deng , mip4@ietf.org Subject: Re: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-758783491-1232908557=:17280 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Behcet, Yes, that is the registry for ATT that should have been referenced. Sri On Fri, 23 Jan 2009, Behcet Sarikaya wrote: > Hi Hui, > =A0 Access technology type values are registered at IANA website at: > http://www.iana.org/assignments/mobility-parameters > Sri can answer the other questions you have. > > Regards, > > Behcet > > > > > ________________________________ > From: Hui Deng > To: Sri Gundavelli > Cc: mip4@ietf.org > Sent: Thursday, January 22, 2009 4:52:41 AM > Subject: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-suppor= t-00 > > > Hi, Sri, > > I have several questions=A0regarding to your draft. > > 1) will you use the same AE between HA and MN on different interfaces? > 2) how do you generate a label for each interface? > 3) Where does the access Technology Type Registry is defined? > 4) why don't allow mobile node use multiple interface when one of it stay= at home? > > thanks > > -Hui > > > 2009/1/20 Sri Gundavelli > > Hi George, > > Sorry for the late reply. Please see inline. > > > > On Wed, 14 Jan 2009, George Tsirtsis wrote: > > > Hi Sri, > > I just had a look at the draft. > Since I was not in the last IETF meeting could you summarize what the > plan is with this draft? Is this something the WG considers taking up? > > > I hope so. That's the plan and there is interest. We need this for > our mobile router deployments. > > > > > If yes, I think it would be useful to spell out what the scope of this > work is in comparison to the equivalent work in the MEXT (i.e., MCoA > and Flow Movement). I did this early on for DSMIPv4 and it helped > things significantly. > > > Ok. The problem statement between MCOA4 and MCOA6 is similar. The > ability for the mobile to setup multiple tunnels to the home agent > through different interfaces, is largely same. The presence of foreign > agent/types of registrations, NAT presence introduces some differences > and issues. > > > > > BTW, I am not sure I like the whole notion of 'Interface bandwidth". > This is something notoriously difficult to set right and make sense > of, especially on wireless links. Instead the rough link priority > adopted in MIPv6-MCoA is easier to deal with and should satisfy your > needs, without turning this into a QoS protocol...which would be a > nightmare.. > > > > The draft is exposing the information about the interface through which > a mobile node is attached and marks the binding associated with this > attach. The interface type (WiMAX, WiFI, LTE ..etc) will definetly provid= e > a sufficient hint for the home agent. In some radio environments, if > the link bandwidth is predictable, it can certainly expose the same to > the home agent. I agree with you that its not always predictable, hence > it is optional, making it useful only when present. The exposed parameter= s > are sufficient for the tunnel peers to build efficient traffic policies > and leverage the links in a much more efficient manner. > > Sri > > > > > > > > > Regards > George > > On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli wrot= e: > > > Please comment on this work item. We presented this > at Minneapolis. > > > Sri > > > ---------- Forwarded message ---------- > Date: Mon, =A08 Dec 2008 00:51:42 -0800 (PST) > From: IETF I-D Submission Tool > To: sgundave@cisco.com > Cc: kleung@cisco.com > Subject: New Version Notification for > =A0 draft-gundavelli-mip4-multiple-tunnel-support-00 > > > A new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-00.tx= t > has been successfuly submitted by Sri Gundavelli and posted to the IETF > repository. > > Filename: =A0 =A0 =A0 =A0draft-gundavelli-mip4-multiple-tunnel-support > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 Multiple Tunnel Support for Mobile IPv4 > Creation_date: =A0 2008-12-08 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 17 > > Abstract: > This document defines extensions to Mobile IPv4 protocol for allowing > a mobile node or a mobile router with multiple interfaces to register > a care-of address for each of the available interfaces and to > simultaneously establish multiple Mobile IP tunnels to the home > agent, each through a different interface path. =A0This capability is > required for enabling a mobile node to utilize all the available > wireless access links and build an higher aggregated data pipe to the > home agent by setting the home address reachability over all of those > tunnel paths. > > > > The IETF Secretariat. > > > -- > Mip4 mailing list: Mip4@ietf.org > =A0Web interface: https://www.ietf.org/mailman/listinfo/mip4 > =A0 Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > > -- > Mip4 mailing list: Mip4@ietf.org > =A0 Web interface: https://www.ietf.org/mailman/listinfo/mip4 > =A0 =A0Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > > ---559023410-758783491-1232908557=:17280 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ---559023410-758783491-1232908557=:17280-- From mip4-bounces@ietf.org Sun Jan 25 10:47:39 2009 Return-Path: X-Original-To: mip4-archive@optimus.ietf.org Delivered-To: ietfarch-mip4-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFEE3A682D; Sun, 25 Jan 2009 10:47:39 -0800 (PST) X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE763A6774 for ; Sun, 25 Jan 2009 10:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 uGWqaIN0EOr4 for ; Sun, 25 Jan 2009 10:47:38 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F294D3A682D for ; Sun, 25 Jan 2009 10:47:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,322,1231113600"; d="scan'208";a="60924042" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2009 18:47:20 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0PIlKm2008750; Sun, 25 Jan 2009 10:47:20 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0PIlKLE028996; Sun, 25 Jan 2009 18:47:20 GMT Date: Sun, 25 Jan 2009 10:47:20 -0800 (PST) From: Sri Gundavelli To: Behcet Sarikaya In-Reply-To: <868721.88015.qm@web111408.mail.gq1.yahoo.com> Message-ID: References: <1d38a3350901220252y17d6f14cs23b107afd22d6eb2@mail.gmail.com> <868721.88015.qm@web111408.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1903590565-1232909240=:17280" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5916; t=1232909240; x=1233773240; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[Mip4]=20Questions=20on=20draft-gundave lli-mip4-multiple-tunnel-support-00 |Sender:=20; bh=e84SYCxFDAjPJsulDmT/Q/BoRDJ2hnYsV4n5bmvLJAs=; b=piLr5XOFItTJqzHIuB7ecLZPTTIeX9+SFeZ/3iy0fvVoGEY++XHxqEcWju msbQerB7uHv+usYylqp0GkN6uWURmT44fAu8FmYV2sKjqLZAmuQsB5SYspoV HXtJf7Bvsr; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Hui Deng , mip4@ietf.org Subject: Re: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-support-00 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1903590565-1232909240=:17280 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Hui, Thanks for the review. Please see inline. > ________________________________ > From: Hui Deng > To: Sri Gundavelli > Cc: mip4@ietf.org > Sent: Thursday, January 22, 2009 4:52:41 AM > Subject: [Mip4] Questions on draft-gundavelli-mip4-multiple-tunnel-suppor= t-00 > > > Hi, Sri, > > I have several questions=A0regarding to your draft. > > 1) will you use the same AE between HA and MN on different interfaces? Auth extension ? Sure, the Security association however keyed using HoA or NAI, will remain the same. The AE will be generated for each of the RRQ sent. > 2) how do you generate a label for each interface? We currently allow the IfType and the Binding Id. We should probably allow the label to be specified as well, our implementation uses the explicit labels. Typically, the label is configured as part of configuring the roaming interface on the mobile router. Each of the selected roaming interfaces can be given a explicit label. > 3) Where does the access Technology Type Registry is defined? ATT registry > 4) why don't allow mobile node use multiple interface when one of it stay= at home? > This can be fixed. Initial thoughts were that this may not be so useful, but will fix it in the next rev, for simultaneous home and roam support. Regards Sri > thanks > > -Hui > > > 2009/1/20 Sri Gundavelli > > Hi George, > > Sorry for the late reply. Please see inline. > > > > On Wed, 14 Jan 2009, George Tsirtsis wrote: > > > Hi Sri, > > I just had a look at the draft. > Since I was not in the last IETF meeting could you summarize what the > plan is with this draft? Is this something the WG considers taking up? > > > I hope so. That's the plan and there is interest. We need this for > our mobile router deployments. > > > > > If yes, I think it would be useful to spell out what the scope of this > work is in comparison to the equivalent work in the MEXT (i.e., MCoA > and Flow Movement). I did this early on for DSMIPv4 and it helped > things significantly. > > > Ok. The problem statement between MCOA4 and MCOA6 is similar. The > ability for the mobile to setup multiple tunnels to the home agent > through different interfaces, is largely same. The presence of foreign > agent/types of registrations, NAT presence introduces some differences > and issues. > > > > > BTW, I am not sure I like the whole notion of 'Interface bandwidth". > This is something notoriously difficult to set right and make sense > of, especially on wireless links. Instead the rough link priority > adopted in MIPv6-MCoA is easier to deal with and should satisfy your > needs, without turning this into a QoS protocol...which would be a > nightmare.. > > > > The draft is exposing the information about the interface through which > a mobile node is attached and marks the binding associated with this > attach. The interface type (WiMAX, WiFI, LTE ..etc) will definetly provid= e > a sufficient hint for the home agent. In some radio environments, if > the link bandwidth is predictable, it can certainly expose the same to > the home agent. I agree with you that its not always predictable, hence > it is optional, making it useful only when present. The exposed parameter= s > are sufficient for the tunnel peers to build efficient traffic policies > and leverage the links in a much more efficient manner. > > Sri > > > > > > > > > Regards > George > > On Wed, Dec 10, 2008 at 3:25 AM, Sri Gundavelli wrot= e: > > > Please comment on this work item. We presented this > at Minneapolis. > > > Sri > > > ---------- Forwarded message ---------- > Date: Mon, =A08 Dec 2008 00:51:42 -0800 (PST) > From: IETF I-D Submission Tool > To: sgundave@cisco.com > Cc: kleung@cisco.com > Subject: New Version Notification for > =A0 draft-gundavelli-mip4-multiple-tunnel-support-00 > > > A new version of I-D, draft-gundavelli-mip4-multiple-tunnel-support-00.tx= t > has been successfuly submitted by Sri Gundavelli and posted to the IETF > repository. > > Filename: =A0 =A0 =A0 =A0draft-gundavelli-mip4-multiple-tunnel-support > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 Multiple Tunnel Support for Mobile IPv4 > Creation_date: =A0 2008-12-08 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 17 > > Abstract: > This document defines extensions to Mobile IPv4 protocol for allowing > a mobile node or a mobile router with multiple interfaces to register > a care-of address for each of the available interfaces and to > simultaneously establish multiple Mobile IP tunnels to the home > agent, each through a different interface path. =A0This capability is > required for enabling a mobile node to utilize all the available > wireless access links and build an higher aggregated data pipe to the > home agent by setting the home address reachability over all of those > tunnel paths. > > > > The IETF Secretariat. > > > -- > Mip4 mailing list: Mip4@ietf.org > =A0Web interface: https://www.ietf.org/mailman/listinfo/mip4 > =A0 Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > > -- > Mip4 mailing list: Mip4@ietf.org > =A0 Web interface: https://www.ietf.org/mailman/listinfo/mip4 > =A0 =A0Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > > > ---559023410-1903590565-1232909240=:17280 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ---559023410-1903590565-1232909240=:17280--