From mailman-owner@ietf.org Fri Mar 1 05:55:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07503 for ; Fri, 1 Mar 2002 05:55:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11816 for ; Fri, 1 Mar 2002 05:55:50 -0500 (EST) Date: Fri, 1 Mar 2002 05:55:50 -0500 (EST) Message-Id: <200203011055.FAA11816@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: seamoby-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, seamoby-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for seamoby-archive@lists.ietf.org: List Password // URL ---- -------- seamoby@ietf.org Zzch https://www1.ietf.org/mailman/options/seamoby/seamoby-archive@lists.ietf.org From mailman-owner@ietf.org Fri Mar 1 05:58:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07739 for ; Fri, 1 Mar 2002 05:58:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13090 for ; Fri, 1 Mar 2002 05:59:00 -0500 (EST) Date: Fri, 1 Mar 2002 05:59:00 -0500 (EST) Message-Id: <200203011059.FAA13090@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: seamoby-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, seamoby-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for seamoby-web-archive@ietf.org: List Password // URL ---- -------- seamoby@ietf.org zabP https://www1.ietf.org/mailman/options/seamoby/seamoby-web-archive@ietf.org From seamoby-admin@ietf.org Fri Mar 1 07:15:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16232 for ; Fri, 1 Mar 2002 07:15:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18318; Fri, 1 Mar 2002 07:04:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18292 for ; Fri, 1 Mar 2002 07:04:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13622; Fri, 1 Mar 2002 07:04:27 -0500 (EST) Message-Id: <200203011204.HAA13622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: seamoby@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:04:27 -0500 Subject: [Seamoby] I-D ACTION:draft-gopal-seamoby-ipsecctxt-issues-01.txt Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Issues in IPSec Context Transfer Author(s) : R. Gopal et al. Filename : draft-gopal-seamoby-ipsecctxt-issues-01.txt Pages : Date : 28-Feb-02 The reasons and the motivation for transferring context have been described in [1]. The requirements for a context transfer protocol can be found in [2]. In this document, we describe issues that need to be considered for transferring security (specifically IPsec) related context between access routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gopal-seamoby-ipsecctxt-issues-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gopal-seamoby-ipsecctxt-issues-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-gopal-seamoby-ipsecctxt-issues-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gopal-seamoby-ipsecctxt-issues-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-gopal-seamoby-ipsecctxt-issues-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134841.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 10:09:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29029 for ; Fri, 1 Mar 2002 10:09:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00437; Fri, 1 Mar 2002 09:56:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00406 for ; Fri, 1 Mar 2002 09:56:17 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28254 for ; Fri, 1 Mar 2002 09:56:15 -0500 (EST) From: rene.purnadi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21EuUG16327 for ; Fri, 1 Mar 2002 08:56:30 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 08:56:13 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 08:55:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 08:55:24 -0600 Message-ID: <748E8123D183394982E32A511DB3E73610B0F5@daebe005.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHAuGZ/7qO5K/ZLROWsf5DJyscyAwAdmv6w To: , Cc: , X-OriginalArrivalTime: 01 Mar 2002 14:55:25.0077 (UTC) FILETIME=[1E67EC50:01C1C131] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Yoshi, Please see my comment below. Thanks. Rene Purnadi Phone: +1 972.894.4897 Mobile: +1 972.342.3503 e-mail: rene.purnadi@nokia.com -----Original Message----- From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Thursday, February 28, 2002 6:30 PM To: Sreemanthula Srinivas (NRC/Dallas) Cc: yohba@tari.toshiba.com; Purnadi Rene (NRC/Dallas); behcet.sarikaya@alcatel.com; seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues On Thu, Feb 28, 2002 at 05:11:57PM -0600, Srinivas.Sreemanthula@nokia.com wrote: > >>Are there any particular reason for de-emphasizing the need of DMHA > for simple-ip? I think the reason for using the word "DMHA" instead > of "IP paging" is as a result of consideration of dormant simple-ip > hosts as well as dormant mobile hosts. We should also consider > simple-ip for the reason as I mentioned earlier. > > Yes. When we talk about about simple-ip, we mean static hosts that are plugged into the power source which don't have any mobility built in them. Therefore, they don't require any dormancy. Please remember the first requirement for DMHA is to save power for lean terminals running on limited power (mobile, ofcourse). Now, can you exactly tell why we need DMHA for simple-ip? Why do you exclude a simple-ip host that is not plugged into the power source? Moreover, why should we ignore power saving for plugged-in hosts? DMHA for simple-ip is required for stationary dormant hosts not to spend power (battery or plugged-in power) for processing unimportant packets (thus filtering trigger packets is necessary for DMHA). Paging does not come free. Some resources are used for paging. The justification of power saving (an other processing like you mentioned above) for plugged-in hosts must out weight the cost. > > >>I don't understand why we need another paging apllication layer protocol > if we put the paging protocol as an application layer protocol. > > If we leave the simple-ip out (as we should), it is only natural that paging protocol makes as an extension to the existing mobility protocol(s). As of now, the applications (or application servers) are not aware of the mobility of the hosts. For the same reason, paging protocol must be independent of the application layers above. Now one important requirement is going to be compromized, independence of any mobility management protocol. I disagree. We can create conceptual paging protocol that is independent of any mobility protocols, hence it fulfill 4.7. But, we also has to fulfill 4.8, therefore the working paging protocol should be an extension of the existing mobility protocol(s). Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 11:35:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04455 for ; Fri, 1 Mar 2002 11:35:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08614; Fri, 1 Mar 2002 11:24:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08576 for ; Fri, 1 Mar 2002 11:24:22 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03620 for ; Fri, 1 Mar 2002 11:24:19 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21GNGe06019; Fri, 1 Mar 2002 08:23:16 -0800 (PST) Message-ID: <002701c1c13d$2ac25830$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Yoshihiro Ohba" Cc: , , , References: <07EE0E021034014F99A57B032BC9C0E50FF676@daebe001.NOE.Nokia.com> <20020301003023.GA653@catfish> <3C7EE838.10806@alcatel.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 08:21:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Instead of the term Simple IP we could say: Hosts that do not use MIP, > they could be wireless or fixed. I do not think we should completely > ignore paging support for these hosts. > Having a design such that paging entities and their interactions are > within a local network (Foreign network takes care of paging when MN is > in a visited network and Home network takes care of paging when MN is at > home) could provide a solution for both MIP hosts and Simple IP hosts > (do not use MIP). > The MAIN difference (not the only difference) between Simple IP service > and MIP service is the involvement of Home Agent (Home network, AAAH > etc), so if we were to avoid anything to do with Home we could have a > BASE solution that supports both hosts. To me, that BASE solution should > be Home - Independent. > To have optimized solutions (whatever OPTIMIZED means), we would need to > use the base solution to come up with a solutions for Simple IP, MIPv4 > and MIPv6. > There is an assumption in the above that the mobility protocol is MIP. The IRTF is working on a micromobility routing protocol, and we would like the paging solution to work with that as well. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 11:54:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05697 for ; Fri, 1 Mar 2002 11:54:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10340; Fri, 1 Mar 2002 11:40:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10259 for ; Fri, 1 Mar 2002 11:40:16 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04809 for ; Fri, 1 Mar 2002 11:40:13 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21GgFx16420 for ; Fri, 1 Mar 2002 10:42:19 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 10:40:03 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 10:39:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 10:39:33 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF678@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHAuGZ/i28+VO+dSbujIck5MU3ldgAgw/Ow To: Cc: X-OriginalArrivalTime: 01 Mar 2002 16:39:33.0480 (UTC) FILETIME=[AABE8E80:01C1C13F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Yoshi, >Why do you exclude a simple-ip host that is not plugged into the power source? Moreover, why should we ignore power saving for plugged-in hosts? There is no incentive to try to save power for stationary or plugged-in hosts.There is no useful (business) case so far. >DMHA for simple-ip is required for stationary dormant hosts not to spend power (battery or plugged-in power) for processing unimportant packets (thus filtering trigger packets is necessary for DMHA). If I understand you correctly, you want to use DMHA as an "application layer" protocol for stationary (non mip) hosts for selective packet filtering. I completly agree with you on this packet filtering concept in home and small office environments when you use gateways or application servers. But this is handled elsewhere (IMPP) and their problem statement is even more general that they handle different modes for the hosts (including idle/dormant) and have defined application layer protocol/extensions for this. Trying to achieve the same in Seamoby WG would be a big waste. Moreover, packet filtering was never in the requirements!! So the emphasis is on power saving and for mobile hosts. >Now one important requirement is going to be compromized, independence of any mobility management protocol. I disagree. DMHA is not useful for non-mobile hosts, atleast not as much as it is required for the mobile hosts. So defining a protocol by just taking that requirement into account would violate req. 4.8 (support for existing MIP), anyways. Hence, we are trying to debate on the weight of this requirement. Regards, Srini _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 12:00:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06200 for ; Fri, 1 Mar 2002 12:00:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10802; Fri, 1 Mar 2002 11:45:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10773 for ; Fri, 1 Mar 2002 11:45:56 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05192 for ; Fri, 1 Mar 2002 11:45:53 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21Glvx16987 for ; Fri, 1 Mar 2002 10:47:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 10:45:46 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 10:44:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 10:44:58 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E574FF4A@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBPXtZS1yCltEjTQugs/R1UGvrowAAn9ug To: , , Cc: , , X-OriginalArrivalTime: 01 Mar 2002 16:44:58.0966 (UTC) FILETIME=[6CBFC760:01C1C140] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit >There is an assumption in the above that the mobility protocol is MIP. The IRTF is working on a micromobility routing protocol, and we would like the paging solution to work with that as well. James, as it is, we have problems with existing requirements. Now, you are bringing new requirements into the table. :) Please check the requirement 4.8. 4.8. Support for Existing Mobility Protocols The IP paging protocol MUST specify the binding to the existing IP mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3]. The IP paging protocol SHOULD make use of existing registration support. Regards, Srini _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 12:13:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07211 for ; Fri, 1 Mar 2002 12:13:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13211; Fri, 1 Mar 2002 12:02:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13162 for ; Fri, 1 Mar 2002 12:02:45 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06410 for ; Fri, 1 Mar 2002 12:02:33 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g21H24N13967; Fri, 1 Mar 2002 12:02:04 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g21H21V03022; Fri, 1 Mar 2002 12:02:01 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 12:02:02 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA48D4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Srinivas.Sreemanthula@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 12:02:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C142.CD843340" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C142.CD843340 Content-Type: text/plain; charset="iso-2022-jp" I know that the micromobility problem was sent to the IRTF for consideration, but I had not heard of any decision by the IRTF routing working group to pursue it. Have you heard of an official (or even unofficial) decision? Gary Kenward > -----Original Message----- > From: Srinivas.Sreemanthula@nokia.com > [mailto:Srinivas.Sreemanthula@nokia.com] > Sent: March 1, 2002 11:45 > To: kempf@docomolabs-usa.com; vinod.choyi@alcatel.com; > yohba@tari.toshiba.com > Cc: rene.purnadi@nokia.com; behcet.sarikaya@alcatel.com; > seamoby@ietf.org > Subject: RE: [Seamoby] Dormant Mode Location Tracking by > Mobility Protocol Issues > > > >There is an assumption in the above that the mobility > protocol is MIP. > The IRTF is working on a micromobility routing protocol, and > we would like the > paging solution to work with that as well. > > > James, as it is, we have problems with existing requirements. > Now, you are bringing new requirements into the table. :) > > Please check the requirement 4.8. > > 4.8. Support for Existing Mobility Protocols > > The IP paging protocol MUST specify the binding to the existing IP > mobility protocols, namely mobile IPv4 [2] and mobile IPv6 > [3]. The > IP paging protocol SHOULD make use of existing > registration support. > > Regards, > Srini > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1C142.CD843340 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Dormant Mode Location Tracking by Mobility = Protocol Issues

I know that the micromobility problem was sent to the = IRTF for consideration,
but I had not heard of any decision by the IRTF = routing working group to
pursue it.

Have you heard of an official (or even unofficial) = decision?

Gary Kenward

> -----Original Message-----
> From: Srinivas.Sreemanthula@nokia.com
> [mailto:Srinivas.Sreemant= hula@nokia.com]
> Sent: March 1, 2002 11:45
> To: kempf@docomolabs-usa.com; = vinod.choyi@alcatel.com;
> yohba@tari.toshiba.com
> Cc: rene.purnadi@nokia.com; = behcet.sarikaya@alcatel.com;
> seamoby@ietf.org
> Subject: RE: [Seamoby] Dormant Mode Location = Tracking by
> Mobility Protocol Issues
>
>
> >There is an assumption in the above that = the mobility
> protocol is MIP.
> The IRTF is working on a micromobility routing = protocol, and
> we would like the
> paging solution to work with that as = well.
>
>
> James, as it is, we have problems with existing = requirements.
> Now, you are bringing new requirements into the = table. :) 
>
> Please check the requirement 4.8.
>
> 4.8. Support for Existing Mobility = Protocols
>
>    The IP paging protocol MUST = specify the binding to the existing IP
>    mobility protocols, namely = mobile IPv4 [2] and mobile IPv6
> [3].  The
>    IP paging protocol SHOULD = make use of existing
> registration support.
>
> Regards,
> Srini
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1C142.CD843340-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 12:13:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07214 for ; Fri, 1 Mar 2002 12:13:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11626; Fri, 1 Mar 2002 11:59:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11595 for ; Fri, 1 Mar 2002 11:59:43 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06167 for ; Fri, 1 Mar 2002 11:59:39 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21GwZe06827; Fri, 1 Mar 2002 08:58:35 -0800 (PST) Message-ID: <00a201c1c142$19f25a00$7e6015ac@T23KEMPF> From: "James Kempf" To: , , Cc: , , References: <07EE0E021034014F99A57B032BC9C0E574FF4A@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 08:56:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > James, as it is, we have problems with existing requirements. Now, you are bringing new requirements into the table. :) > > Please check the requirement 4.8. > > 4.8. Support for Existing Mobility Protocols > > The IP paging protocol MUST specify the binding to the existing IP > mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3]. The > IP paging protocol SHOULD make use of existing registration support. > There is also requirement 4.7: 4.7. Independence of Mobility Protocol Recognizing that IETF may support multiple mobility protocols in the future and that paging may be of value to hosts that do not support a mobility protocol, the IP paging protocol MUST be designed so there is no dependence on the underlying mobility protocol or on any mobility protocol at all. The protocol SHOULD specify and provide support for a mobility protocol, if the Host supports one. This requirement was explicitly inserted to accommodate a micromobility protocol. Also, note that the requirement says "for hosts that do not support a mobility protocol." Basically, this discussion has been touching on the following architectural points I have been trying to make: 1) base paging protocol independent of mobility management that supports dormant mode alerting but no location tracking. 2) mobility management protocol additions and changes plus some hooks in the paging protocol that support location tracking via DMA and TA. For hosts that don't support a mobility management protocol, some kind of support for DMA and TA independent of mobility management. Point 1 satisfies most of requirement 4.7, point 2 satisfies requirement 4.8 and the part of 4.7 that says that hosts without access to a mobility protocol should be supported. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 12:20:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07736 for ; Fri, 1 Mar 2002 12:20:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13605; Fri, 1 Mar 2002 12:08:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13574 for ; Fri, 1 Mar 2002 12:08:12 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06809 for ; Fri, 1 Mar 2002 12:08:09 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g21H7eN14443; Fri, 1 Mar 2002 12:07:40 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g21H7cq13265; Fri, 1 Mar 2002 12:07:38 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 12:07:32 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA48D5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Srinivas.Sreemanthula@nokia.com'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 12:06:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C143.77DD5C90" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C143.77DD5C90 Content-Type: text/plain; charset="iso-2022-jp" Sorry, I just checked and noted that micromobility is listed under current actives. Gary Kenward ------------------- I know that the micromobility problem was sent to the IRTF for consideration, but I had not heard of any decision by the IRTF routing working group to pursue it. Have you heard of an official (or even unofficial) decision? Gary Kenward > -----Original Message----- > From: Srinivas.Sreemanthula@nokia.com > [mailto:Srinivas.Sreemanthula@nokia.com] > Sent: March 1, 2002 11:45 > To: kempf@docomolabs-usa.com; vinod.choyi@alcatel.com; > yohba@tari.toshiba.com > Cc: rene.purnadi@nokia.com; behcet.sarikaya@alcatel.com; > seamoby@ietf.org > Subject: RE: [Seamoby] Dormant Mode Location Tracking by > Mobility Protocol Issues > > > >There is an assumption in the above that the mobility > protocol is MIP. > The IRTF is working on a micromobility routing protocol, and > we would like the > paging solution to work with that as well. > > > James, as it is, we have problems with existing requirements. > Now, you are bringing new requirements into the table. :) > > Please check the requirement 4.8. > > 4.8. Support for Existing Mobility Protocols > > The IP paging protocol MUST specify the binding to the existing IP > mobility protocols, namely mobile IPv4 [2] and mobile IPv6 > [3]. The > IP paging protocol SHOULD make use of existing > registration support. > > Regards, > Srini > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1C143.77DD5C90 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Dormant Mode Location Tracking by Mobility = Protocol Issues

Sorry, I just checked and noted that micromobility is = listed under current actives.

Gary Kenward

-------------------

I know that the micromobility problem was sent to the = IRTF for consideration,
but I had not heard of any decision by the IRTF = routing working group to
pursue it.

Have you heard of an official (or even unofficial) = decision?

Gary Kenward

> -----Original Message-----
> From: Srinivas.Sreemanthula@nokia.com
> [mailto:Srinivas.Sreemant= hula@nokia.com]
> Sent: March 1, 2002 11:45
> To: kempf@docomolabs-usa.com; = vinod.choyi@alcatel.com;
> yohba@tari.toshiba.com
> Cc: rene.purnadi@nokia.com; = behcet.sarikaya@alcatel.com;
> seamoby@ietf.org
> Subject: RE: [Seamoby] Dormant Mode Location = Tracking by
> Mobility Protocol Issues
>
>
> >There is an assumption in the above that = the mobility
> protocol is MIP.
> The IRTF is working on a micromobility routing = protocol, and
> we would like the
> paging solution to work with that as = well.
>
>
> James, as it is, we have problems with existing = requirements.
> Now, you are bringing new requirements into the = table. :) 
>
> Please check the requirement 4.8.
>
> 4.8. Support for Existing Mobility = Protocols
>
>    The IP paging protocol MUST = specify the binding to the existing IP
>    mobility protocols, namely = mobile IPv4 [2] and mobile IPv6
> [3].  The
>    IP paging protocol SHOULD = make use of existing
> registration support.
>
> Regards,
> Srini
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1C143.77DD5C90-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 12:23:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08120 for ; Fri, 1 Mar 2002 12:23:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13551; Fri, 1 Mar 2002 12:07:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13520 for ; Fri, 1 Mar 2002 12:07:45 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06763 for ; Fri, 1 Mar 2002 12:07:42 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21H6fe07141; Fri, 1 Mar 2002 09:06:41 -0800 (PST) Message-ID: <00be01c1c143$3bc30250$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <07EE0E021034014F99A57B032BC9C0E50FF678@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 09:05:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Srini, > There is no incentive to try to save power for stationary or plugged-in hosts.There is no useful (business) case so far. > > Last spring during the height of California's power crisis, power use in the state dropped by 10% because people started buying compact fluorescent bulbs and took other power saving measures. The reason they did this is beause the cost of electricity went up by a factor of 10 over the previous year. My own electricity bill dropped by about 30 kWH a month for the same reason. If IP paging can help in reducing power costs, then I think there is a big business reason for having it, to say nothing of the CO2 and pollution saving. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 12:56:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10315 for ; Fri, 1 Mar 2002 12:56:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15549; Fri, 1 Mar 2002 12:42:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15519 for ; Fri, 1 Mar 2002 12:42:22 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09479 for ; Fri, 1 Mar 2002 12:42:17 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g21Hewd1027173; Fri, 1 Mar 2002 12:40:58 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA11277; Fri, 1 Mar 2002 12:40:52 -0500 (EST) Date: Fri, 1 Mar 2002 12:40:56 -0500 To: Srinivas.Sreemanthula@nokia.com Cc: yohba@tari.toshiba.com, seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020301174056.GB3884@catfish> Mail-Followup-To: Srinivas.Sreemanthula@nokia.com, yohba@tari.toshiba.com, seamoby@ietf.org References: <07EE0E021034014F99A57B032BC9C0E50FF678@daebe001.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF678@daebe001.NOE.Nokia.com> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 53 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Fri, Mar 01, 2002 at 10:39:33AM -0600, Srinivas.Sreemanthula@nokia.com wrote: > Yoshi, > > >Why do you exclude a simple-ip host that is not plugged into the power > source? Moreover, why should we ignore power saving for plugged-in hosts? > > There is no incentive to try to save power for stationary or plugged-in hosts.There is no useful (business) case so far. > This is wrong. There is a business so far for supporting a kind of DMHA for stationary hosts, MagicPacket, unfortunately it is not standardized one. Furthermore, I don't understand why a DMHA protocol design is affected by whether a host is plugged-in powered or battery powered. > > >DMHA for simple-ip is required for stationary dormant hosts not to > spend power (battery or plugged-in power) for processing unimportant > packets (thus filtering trigger packets is necessary for DMHA). > > If I understand you correctly, you want to use DMHA as an "application layer" protocol for stationary (non mip) hosts for selective packet filtering. I completly agree with you on this packet filtering concept in home and small office environments when you use gateways or application servers. But this is handled elsewhere (IMPP) and their problem statement is even more general that they handle different modes for the hosts (including idle/dormant) and have defined application layer protocol/extensions for this. Trying to achieve the same in Seamoby WG would be a big waste. Moreover, packet filtering was never in the requirements!! This is also wrong. There is a requirement for filtering in RFC3154: 4.3. Control of Broadcast/Multicast/Anycast The protocol SHOULD provide a filter mechanism to allow a Host prior to entering dormant mode to filter which broadcast/multicast/anycast packets active a page. This prevents the Host from awakening out of dormant mode for all broadcast/multicast/anycast traffic. In addition, IMPP is only for instant messaging, not for hosts that does not have instant messaging but requires DMHA. > > So the emphasis is on power saving and for mobile hosts. > > >Now one important requirement is going to be compromized, > independence of any mobility management protocol. I disagree. > > DMHA is not useful for non-mobile hosts, atleast not as much as it is required for the mobile hosts. So defining a protocol by just taking that requirement into account would violate req. 4.8 (support for existing MIP), anyways. Hence, we are trying to debate on the weight of this requirement. Then, could you explain how draft-ohba, for example, violates req. 4.8? > > > Regards, > Srini > Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 12:59:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10523 for ; Fri, 1 Mar 2002 12:59:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15693; Fri, 1 Mar 2002 12:45:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15666 for ; Fri, 1 Mar 2002 12:45:47 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09595 for ; Fri, 1 Mar 2002 12:45:40 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21HjxG25128 for ; Fri, 1 Mar 2002 11:45:59 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 11:45:42 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 11:45:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 11:45:33 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF679@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBQ3fc7BP5nf1pS/uE656BScckFgAApJiA To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 17:45:33.0989 (UTC) FILETIME=[E3644550:01C1C148] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, > Last spring during the height of California's power crisis, power use in the state dropped by 10% because people started buying compact fluorescent bulbs and took other power saving measures. The reason they did this is beause the cost of electricity went up by a factor of 10 over the previous year. My own electricity bill dropped by about 30 kWH a month for the same reason. If IP paging can help in reducing power costs, then I think there is a big business reason for having it, to say nothing of the CO2 and pollution saving. I would like to hear from somebody one scenario how IP paging for stationary hosts saves battery. What kind of current L2 (ethernet, WLAN) are we assuming here and what kind of dormancy and paging alert functions does it have? For stationary hosts, the power saving capabilities are NOT realised until the hosts perform paging registration and can (actually) go dormant at L2. This also requires that the L2 must support re-connect features when the paging request arrives. We can argue that there may be future L2 technologies that may support this. But, the focus right now is more on mobile hosts that use existing/near term L2 technologies that support the paging features and need power saving when idle. Hence the emphasis on the paging protocol solution for such mobile hosts. Regards. Srini _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 13:17:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11591 for ; Fri, 1 Mar 2002 13:17:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16809; Fri, 1 Mar 2002 13:03:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16782 for ; Fri, 1 Mar 2002 13:03:13 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10746 for ; Fri, 1 Mar 2002 13:03:09 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21I3MZ24846 for ; Fri, 1 Mar 2002 20:03:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 20:03:11 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 20:03:11 +0200 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 12:03:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 12:03:06 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF67A@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBSG6XCE+BYyuNSFGIFmuRXE1ORwAAJ9TQ To: Cc: X-OriginalArrivalTime: 01 Mar 2002 18:03:06.0621 (UTC) FILETIME=[56CF2AD0:01C1C14B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Furthermore, I don't understand why a DMHA protocol design is affected by whether a host is plugged-in powered or battery powered. Because, power saving was the most important requirement. > This is also wrong. There is a requirement for filtering in RFC3154: 4.3. Control of Broadcast/Multicast/Anycast The protocol SHOULD provide a filter mechanism to allow a Host prior to entering dormant mode to filter which broadcast/multicast/anycast packets active a page. This prevents the Host from awakening out of dormant mode for all broadcast/multicast/anycast traffic. Yoshi, filtering mechanism was to allow efficient DMHA functioning. But, DMHA is not for filtering function. > > So the emphasis is on power saving and for mobile hosts. > > >Now one important requirement is going to be compromized, > independence of any mobility management protocol. I disagree. > > DMHA is not useful for non-mobile hosts, atleast not as much as it is required for the mobile hosts. So defining a protocol by just taking that requirement into account would violate req. 4.8 (support for existing MIP), anyways. Hence, we are trying to debate on the weight of this requirement. Then, could you explain how draft-ohba, for example, violates req. 4.8? I didn't say that. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 13:19:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11723 for ; Fri, 1 Mar 2002 13:19:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17071; Fri, 1 Mar 2002 13:08:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17045 for ; Fri, 1 Mar 2002 13:08:29 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11048 for ; Fri, 1 Mar 2002 13:08:26 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21I8eG26375 for ; Fri, 1 Mar 2002 12:08:41 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 12:08:23 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 12:07:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 12:07:47 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E574FF4E@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBQlkf5ssMEpRqSkeEtlbA2k+UJwACRjXA To: , , Cc: , , X-OriginalArrivalTime: 01 Mar 2002 18:07:47.0772 (UTC) FILETIME=[FE6367C0:01C1C14B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James, >4.7. Independence of Mobility Protocol Recognizing that IETF may support multiple mobility protocols in the future and that paging may be of value to hosts that do not support a mobility protocol, the IP paging protocol MUST be designed so there is no dependence on the underlying mobility protocol or on any mobility protocol at all. The protocol SHOULD specify and provide support for a mobility protocol, if the Host supports one. >This requirement was explicitly inserted to accommodate a micromobility protocol. Also, note that the requirement says "for hosts that do not support a mobility protocol." Using the "Independence of mobility protocol" requirement to support "micromobility protocol" does not seem right. Regards, Srini _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 13:24:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12097 for ; Fri, 1 Mar 2002 13:24:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17233; Fri, 1 Mar 2002 13:13:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17204 for ; Fri, 1 Mar 2002 13:13:10 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11359 for ; Fri, 1 Mar 2002 13:13:07 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g21ICdl21729 for ; Fri, 1 Mar 2002 12:12:39 -0600 (CST) Message-ID: <3C7FC496.8020904@alcatel.com> Date: Fri, 01 Mar 2002 12:12:38 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <07EE0E021034014F99A57B032BC9C0E50FF679@daebe001.NOE.Nokia.com> Content-Type: multipart/alternative; boundary="------------080805000306020203010809" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------080805000306020203010809 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit I agree with Srini. What we should concentrate is the devices that move. For Simple IP, I have concerns. But if Yoshi says he can set up interoperability tests for devices that move but do not have MIP, why not? The simple policy of if you want it you get it can be applied. Regards, Srinivas.Sreemanthula@nokia.com wrote: >James, > >>Last spring during the height of California's power crisis, power use in >> >the state dropped by 10% because people started buying compact >fluorescent bulbs and took other power saving measures. The reason they >did this is beause the cost of electricity went up by a factor of 10 >over the previous year. My own electricity bill dropped by about 30 kWH >a month for the same reason. If IP paging can help in reducing power >costs, then I think there is a big business reason for having it, to say >nothing of the CO2 and pollution saving. > > >I would like to hear from somebody one scenario how IP paging for stationary hosts saves battery. What kind of current L2 (ethernet, WLAN) are we assuming here and what kind of dormancy and paging alert functions does it have? > >For stationary hosts, the power saving capabilities are NOT realised until the hosts perform paging registration and can (actually) go dormant at L2. This also requires that the L2 must support re-connect features when the paging request arrives. > >We can argue that there may be future L2 technologies that may support this. But, the focus right now is more on mobile hosts that use existing/near term L2 technologies that support the paging features and need power saving when idle. Hence the emphasis on the paging protocol solution for such mobile hosts. > >Regards. >Srini > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet --------------080805000306020203010809 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit I agree with Srini.
What we should concentrate is the devices that move. For Simple IP, I have concerns. But if Yoshi says he can set up interoperability tests for devices that move but do not have MIP, why not?
The simple policy of if you want it you get it can be applied.
Regards,

Srinivas.Sreemanthula@nokia.com wrote:
James,

Last spring during the height of California's power crisis, power use in
the state dropped by 10% because people started buying compact
fluorescent bulbs and took other power saving measures. The reason they
did this is beause the cost of electricity went up by a factor of 10
over the previous year. My own electricity bill dropped by about 30 kWH
a month for the same reason. If IP paging can help in reducing power
costs, then I think there is a big business reason for having it, to say
nothing of the CO2 and pollution saving.


I would like to hear from somebody one scenario how IP paging for stationary hosts saves battery. What kind of current L2 (ethernet, WLAN) are we assuming here and what kind of dormancy and paging alert functions does it have?  

For stationary hosts, the power saving capabilities are NOT realised until the hosts perform paging registration and can (actually) go dormant at L2. This also requires that the L2 must support re-connect features when the paging request arr
ives. 

We can argue that there may be future L2 technologies that may support this. But, the focus right now is more on mobile hosts that use existing/near term L2 technologies that support the paging features and need power saving when idle. Hence the emphasis on the paging protocol solution for such mobile hosts.

Regards.
Srini




_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby

-- 
Behcet

--------------080805000306020203010809-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 13:24:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12109 for ; Fri, 1 Mar 2002 13:24:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17304; Fri, 1 Mar 2002 13:14:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17276 for ; Fri, 1 Mar 2002 13:14:04 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11408 for ; Fri, 1 Mar 2002 13:14:00 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21IDQe09451; Fri, 1 Mar 2002 10:13:26 -0800 (PST) Message-ID: <00fa01c1c14c$8ec5af80$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA48D4@zcard031.ca.nortel.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 10:11:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit There is an IRTF Micromobility Task Force, John Loughny and Carl Williams are co-chairs. They held a meeting during last IETF. Currently, they are working on a taxonomy of micromobility protocols and examining the relation between micromobility and LMM/optimized handover protocols for Mobile IP. jak ----- Original Message ----- From: "Gary Kenward" To: Cc: Sent: Friday, March 01, 2002 9:02 AM Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues > I know that the micromobility problem was sent to the IRTF for > consideration, > but I had not heard of any decision by the IRTF routing working group to > pursue it. > > Have you heard of an official (or even unofficial) decision? > > Gary Kenward > > > -----Original Message----- > > From: Srinivas.Sreemanthula@nokia.com > > [mailto:Srinivas.Sreemanthula@nokia.com] > > Sent: March 1, 2002 11:45 > > To: kempf@docomolabs-usa.com; vinod.choyi@alcatel.com; > > yohba@tari.toshiba.com > > Cc: rene.purnadi@nokia.com; behcet.sarikaya@alcatel.com; > > seamoby@ietf.org > > Subject: RE: [Seamoby] Dormant Mode Location Tracking by > > Mobility Protocol Issues > > > > > > >There is an assumption in the above that the mobility > > protocol is MIP. > > The IRTF is working on a micromobility routing protocol, and > > we would like the > > paging solution to work with that as well. > > > > > > James, as it is, we have problems with existing requirements. > > Now, you are bringing new requirements into the table. :) > > > > Please check the requirement 4.8. > > > > 4.8. Support for Existing Mobility Protocols > > > > The IP paging protocol MUST specify the binding to the existing IP > > mobility protocols, namely mobile IPv4 [2] and mobile IPv6 > > [3]. The > > IP paging protocol SHOULD make use of existing > > registration support. > > > > Regards, > > Srini > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 13:29:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12506 for ; Fri, 1 Mar 2002 13:29:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17614; Fri, 1 Mar 2002 13:19:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17544 for ; Fri, 1 Mar 2002 13:19:00 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11705 for ; Fri, 1 Mar 2002 13:18:56 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21IHue09629; Fri, 1 Mar 2002 10:17:56 -0800 (PST) Message-ID: <010e01c1c14d$2fdd4f40$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <07EE0E021034014F99A57B032BC9C0E50FF679@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 10:16:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I would like to hear from somebody one scenario how IP paging for stationary hosts saves battery. What kind of current L2 (ethernet, WLAN) are we assuming here and what kind of dormancy and paging alert functions does it have? > > For stationary hosts, the power saving capabilities are NOT realised until the hosts perform paging registration and can (actually) go dormant at L2. This also requires that the L2 must support re-connect features when the paging request arrives. > > We can argue that there may be future L2 technologies that may support this. But, the focus right now is more on mobile hosts that use existing/near term L2 technologies that support the paging features and need power saving when idle. Hence the emphasis on the paging protocol solution for such mobile hosts. > There is a particular Ethernet frame type defined in Intel's Wired For Managment protocol that can be used to wake up a sleeping host. It was defined as part of the government's Energy Star initiative. I think it is now implemented by most NICs, including non-Intel ones. Most modern operating systems have power management capabilities that allow nonessential components, such as disk, screen, and even CPU, to be turned off if not in use. The NIC card would be the only component that is on. This frame would serve as the L2 support for DMHA. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 13:40:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13554 for ; Fri, 1 Mar 2002 13:40:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18386; Fri, 1 Mar 2002 13:29:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18357 for ; Fri, 1 Mar 2002 13:29:43 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12542 for ; Fri, 1 Mar 2002 13:29:38 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21ISae10002; Fri, 1 Mar 2002 10:28:36 -0800 (PST) Message-ID: <012c01c1c14e$ad2641e0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , Cc: , , References: <07EE0E021034014F99A57B032BC9C0E574FF4E@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 10:26:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >This requirement was explicitly inserted to accommodate a micromobility > protocol. Also, note that the requirement says "for hosts that do not support a mobility > protocol." > > Using the "Independence of mobility protocol" requirement to support "micromobility protocol" does not seem right. > I guess I don't understand this comment, can you explain? The history of Seamoby is that we have always tried to maintain independence of mobility protocol on all our charter items. One could equally well consider using IP paging to encompass GPRS, for example. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 14:10:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16269 for ; Fri, 1 Mar 2002 14:10:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20851; Fri, 1 Mar 2002 13:58:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20825 for ; Fri, 1 Mar 2002 13:58:14 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15135 for ; Fri, 1 Mar 2002 13:58:11 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g21Iv7d1005204; Fri, 1 Mar 2002 13:57:08 -0500 (EST) Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA11497; Fri, 1 Mar 2002 13:57:01 -0500 (EST) Date: Fri, 1 Mar 2002 13:57:05 -0500 To: Srinivas.Sreemanthula@nokia.com Cc: yohba@tari.toshiba.com, seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Message-ID: <20020301185705.GC3884@catfish> Mail-Followup-To: Srinivas.Sreemanthula@nokia.com, yohba@tari.toshiba.com, seamoby@ietf.org References: <07EE0E021034014F99A57B032BC9C0E50FF67A@daebe001.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <07EE0E021034014F99A57B032BC9C0E50FF67A@daebe001.NOE.Nokia.com> User-Agent: Mutt/1.3.27i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 26 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Fri, Mar 01, 2002 at 12:03:06PM -0600, Srinivas.Sreemanthula@nokia.com wrote: > > Furthermore, I don't understand why a DMHA protocol design is affected > by whether a host is plugged-in powered or battery powered. > > Because, power saving was the most important requirement. See Jim's email on California's power crisis. If power saving is the most important requirement, considering power saving for plugged-in power should also be important. > > > This is also wrong. There is a requirement for filtering in RFC3154: > 4.3. Control of Broadcast/Multicast/Anycast > > The protocol SHOULD provide a filter mechanism to allow a Host prior > to entering dormant mode to filter which broadcast/multicast/anycast > packets active a page. This prevents the Host from awakening out of > dormant mode for all broadcast/multicast/anycast traffic. > > Yoshi, filtering mechanism was to allow efficient DMHA functioning. But, DMHA is not for filtering function. Yes, filtering mechanism is to allow efficient DMHA functioning and it also efficiently works for stationary dormant hosts to save more power. Anyway, filtering is clearly a requirement. Yoshihiro Ohba _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 17:04:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02658 for ; Fri, 1 Mar 2002 17:04:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01717; Fri, 1 Mar 2002 16:52:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01686 for ; Fri, 1 Mar 2002 16:52:29 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01522 for ; Fri, 1 Mar 2002 16:52:26 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21LqjG07649 for ; Fri, 1 Mar 2002 15:52:45 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 15:52:28 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 15:51:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 15:51:07 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF67B@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBTXWc9CvcwA4YR7yVvTkdgpjUHQADSlSA To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 21:51:07.0630 (UTC) FILETIME=[315378E0:01C1C16B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit >There is a particular Ethernet frame type defined in Intel's Wired For Managment protocol that can be used to wake up a sleeping host. It was defined as part of the government's Energy Star initiative. I think it is now implemented by most NICs, including non-Intel ones. Most modern operating systems have power management capabilities that allow nonessential components, such as disk, screen, and even CPU, to be turned off if not in use. The NIC card would be the only component that is on. This frame would serve as the L2 support for DMHA. It is used for remote management of PCs for IT purposes. I cannot think of usage scenarios with DMHA. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Mar 1 17:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02667 for ; Fri, 1 Mar 2002 17:04:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03008 for seamoby-archive@odin.ietf.org; Fri, 1 Mar 2002 17:04:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01717; Fri, 1 Mar 2002 16:52:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01686 for ; Fri, 1 Mar 2002 16:52:29 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01522 for ; Fri, 1 Mar 2002 16:52:26 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21LqjG07649 for ; Fri, 1 Mar 2002 15:52:45 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 15:52:28 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 15:51:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 15:51:07 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF67B@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBTXWc9CvcwA4YR7yVvTkdgpjUHQADSlSA To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 21:51:07.0630 (UTC) FILETIME=[315378E0:01C1C16B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit >There is a particular Ethernet frame type defined in Intel's Wired For Managment protocol that can be used to wake up a sleeping host. It was defined as part of the government's Energy Star initiative. I think it is now implemented by most NICs, including non-Intel ones. Most modern operating systems have power management capabilities that allow nonessential components, such as disk, screen, and even CPU, to be turned off if not in use. The NIC card would be the only component that is on. This frame would serve as the L2 support for DMHA. It is used for remote management of PCs for IT purposes. I cannot think of usage scenarios with DMHA. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 18:11:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05336 for ; Fri, 1 Mar 2002 18:11:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05443; Fri, 1 Mar 2002 17:58:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05414 for ; Fri, 1 Mar 2002 17:58:53 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04978 for ; Fri, 1 Mar 2002 17:58:50 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21Mvme20848; Fri, 1 Mar 2002 14:57:48 -0800 (PST) Message-ID: <006b01c1c174$485e9610$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <07EE0E021034014F99A57B032BC9C0E50FF67B@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 14:56:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >There is a particular Ethernet frame type defined in Intel's Wired For > Managment protocol that can be used to wake up a sleeping host. It was > defined as part of the government's Energy Star initiative. I think it > is now implemented by most NICs, including non-Intel ones. Most modern > operating systems have power management capabilities that allow > nonessential components, such as disk, screen, and even CPU, to be > turned off if not in use. The NIC card would be the only component that > is on. > > This frame would serve as the L2 support for DMHA. > > > It is used for remote management of PCs for IT purposes. I cannot think of usage scenarios with DMHA. > Can you explain why? If the host is fixed, all that is required is some signal at L2 that causes the power management hardware to spin up the disk and turn on the CPU. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Mar 1 18:11:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05346 for ; Fri, 1 Mar 2002 18:11:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA06433 for seamoby-archive@odin.ietf.org; Fri, 1 Mar 2002 18:11:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05443; Fri, 1 Mar 2002 17:58:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05414 for ; Fri, 1 Mar 2002 17:58:53 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04978 for ; Fri, 1 Mar 2002 17:58:50 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g21Mvme20848; Fri, 1 Mar 2002 14:57:48 -0800 (PST) Message-ID: <006b01c1c174$485e9610$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <07EE0E021034014F99A57B032BC9C0E50FF67B@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 14:56:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >There is a particular Ethernet frame type defined in Intel's Wired For > Managment protocol that can be used to wake up a sleeping host. It was > defined as part of the government's Energy Star initiative. I think it > is now implemented by most NICs, including non-Intel ones. Most modern > operating systems have power management capabilities that allow > nonessential components, such as disk, screen, and even CPU, to be > turned off if not in use. The NIC card would be the only component that > is on. > > This frame would serve as the L2 support for DMHA. > > > It is used for remote management of PCs for IT purposes. I cannot think of usage scenarios with DMHA. > Can you explain why? If the host is fixed, all that is required is some signal at L2 that causes the power management hardware to spin up the disk and turn on the CPU. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 1 19:25:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07835 for ; Fri, 1 Mar 2002 19:25:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09875; Fri, 1 Mar 2002 19:12:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09848 for ; Fri, 1 Mar 2002 19:12:12 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07439 for ; Fri, 1 Mar 2002 19:12:09 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g220Cii21409 for ; Sat, 2 Mar 2002 02:12:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 2 Mar 2002 02:12:08 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 2 Mar 2002 02:12:08 +0200 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 18:12:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 18:12:06 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF680@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBdIauDUdrE2V/RtiWZVdQCg+WwAAAB2LA To: , Cc: X-OriginalArrivalTime: 02 Mar 2002 00:12:06.0419 (UTC) FILETIME=[E3283E30:01C1C17E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit >Can you explain why? If the host is fixed, all that is required is some signal at L2 that causes the power management hardware to spin up the disk and turn on the CPU. It will certainly work to wake up the host. Anyway, if you feel that such problems are within the Seamoby charter then it is fine. However, I woould like to bring the following charter item description for DMHA. Dormant Mode Host Alerting Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs. The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Mar 1 19:25:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07844 for ; Fri, 1 Mar 2002 19:25:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10594 for seamoby-archive@odin.ietf.org; Fri, 1 Mar 2002 19:25:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09875; Fri, 1 Mar 2002 19:12:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09848 for ; Fri, 1 Mar 2002 19:12:12 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07439 for ; Fri, 1 Mar 2002 19:12:09 -0500 (EST) From: Srinivas.Sreemanthula@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g220Cii21409 for ; Sat, 2 Mar 2002 02:12:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 2 Mar 2002 02:12:08 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 2 Mar 2002 02:12:08 +0200 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Mar 2002 18:12:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Fri, 1 Mar 2002 18:12:06 -0600 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF680@daebe001.NOE.Nokia.com> Thread-Topic: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Thread-Index: AcHBdIauDUdrE2V/RtiWZVdQCg+WwAAAB2LA To: , Cc: X-OriginalArrivalTime: 02 Mar 2002 00:12:06.0419 (UTC) FILETIME=[E3283E30:01C1C17E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit >Can you explain why? If the host is fixed, all that is required is some signal at L2 that causes the power management hardware to spin up the disk and turn on the CPU. It will certainly work to wake up the host. Anyway, if you feel that such problems are within the Seamoby charter then it is fine. However, I woould like to bring the following charter item description for DMHA. Dormant Mode Host Alerting Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs. The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 4 12:44:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05568 for ; Mon, 4 Mar 2002 12:44:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15800; Mon, 4 Mar 2002 12:27:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15774 for ; Mon, 4 Mar 2002 12:27:03 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04621 for ; Mon, 4 Mar 2002 12:26:57 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g24HPge05043; Mon, 4 Mar 2002 09:25:42 -0800 (PST) Message-ID: <004001c1c3a1$6c2ec540$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <07EE0E021034014F99A57B032BC9C0E50FF680@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Mon, 4 Mar 2002 09:24:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Srini, > Dormant Mode Host Alerting > > Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. > > All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs. > > The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. > > So I guess I don't see any conflict between this and accommodating fixed hosts. Is the concern that we may need to specify something at L2? If so, then be assured that we won't. There is a move afoot to start some work on defining abstract L2 triggers, but this will not involve explicit L2s and it will not be done in Seamoby. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Mar 4 12:44:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05582 for ; Mon, 4 Mar 2002 12:44:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17421 for seamoby-archive@odin.ietf.org; Mon, 4 Mar 2002 12:44:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15800; Mon, 4 Mar 2002 12:27:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15774 for ; Mon, 4 Mar 2002 12:27:03 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04621 for ; Mon, 4 Mar 2002 12:26:57 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g24HPge05043; Mon, 4 Mar 2002 09:25:42 -0800 (PST) Message-ID: <004001c1c3a1$6c2ec540$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <07EE0E021034014F99A57B032BC9C0E50FF680@daebe001.NOE.Nokia.com> Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues Date: Mon, 4 Mar 2002 09:24:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Srini, > Dormant Mode Host Alerting > > Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. > > All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs. > > The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. > > So I guess I don't see any conflict between this and accommodating fixed hosts. Is the concern that we may need to specify something at L2? If so, then be assured that we won't. There is a move afoot to start some work on defining abstract L2 triggers, but this will not involve explicit L2s and it will not be done in Seamoby. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 4 13:50:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10846 for ; Mon, 4 Mar 2002 13:50:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20941; Mon, 4 Mar 2002 13:34:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20893 for ; Mon, 4 Mar 2002 13:34:01 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08827 for ; Mon, 4 Mar 2002 13:33:56 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g24IXOQ07467 for ; Mon, 4 Mar 2002 19:33:24 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA08948 for ; Mon, 4 Mar 2002 19:33:23 +0100 Message-ID: <3C83BDF3.1F482137@ccrle.nec.de> Date: Mon, 04 Mar 2002 19:33:23 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <07EE0E021034014F99A57B032BC9C0E50FF680@daebe001.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi all, talking about reducing drainage of battery energy for mobile terminals or even saving power on a stationary host, I would like to refer to another aspect where 'idle mode support' and 'paging' brings in a benefit. Of course, saving energy on a terminal's side is an important issue, but from network design point of view, paging mechanisms, especially when deploying advanced paging strategies, can improve scalability in mobile networks. This is mainly for mobile terminals, of course, but this aspect should not be ignored. My understanding is that the Seamoby WG protocol on DMHA should 'allow' different access technologies (and their different lower layer power saving modes) to be deployed, but the group's 'focus' should be on the network side and the design of a flexible architecture as well as IP protocol specifics. So, we should have L2 specifics in mind, but should mainly take care of that the architecture and the protocol allows efficient deployment of IP paging and paging strategies for 'signaling cost' reasons. Marco Srinivas.Sreemanthula@nokia.com wrote: > >Can you explain why? If the host is fixed, all that is required is some > signal at L2 that causes the power management hardware to spin up the > disk and turn on the CPU. > > It will certainly work to wake up the host. Anyway, if you feel that such problems are within the Seamoby charter then it is fine. However, I woould like to bring the following charter item description for DMHA. > > Dormant Mode Host Alerting > > Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. > > All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs. > > The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Mar 4 14:39:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10854 for ; Mon, 4 Mar 2002 13:50:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22526 for seamoby-archive@odin.ietf.org; Mon, 4 Mar 2002 13:50:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20941; Mon, 4 Mar 2002 13:34:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20893 for ; Mon, 4 Mar 2002 13:34:01 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08827 for ; Mon, 4 Mar 2002 13:33:56 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g24IXOQ07467 for ; Mon, 4 Mar 2002 19:33:24 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA08948 for ; Mon, 4 Mar 2002 19:33:23 +0100 Message-ID: <3C83BDF3.1F482137@ccrle.nec.de> Date: Mon, 04 Mar 2002 19:33:23 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Dormant Mode Location Tracking by Mobility Protocol Issues References: <07EE0E021034014F99A57B032BC9C0E50FF680@daebe001.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi all, talking about reducing drainage of battery energy for mobile terminals or even saving power on a stationary host, I would like to refer to another aspect where 'idle mode support' and 'paging' brings in a benefit. Of course, saving energy on a terminal's side is an important issue, but from network design point of view, paging mechanisms, especially when deploying advanced paging strategies, can improve scalability in mobile networks. This is mainly for mobile terminals, of course, but this aspect should not be ignored. My understanding is that the Seamoby WG protocol on DMHA should 'allow' different access technologies (and their different lower layer power saving modes) to be deployed, but the group's 'focus' should be on the network side and the design of a flexible architecture as well as IP protocol specifics. So, we should have L2 specifics in mind, but should mainly take care of that the architecture and the protocol allows efficient deployment of IP paging and paging strategies for 'signaling cost' reasons. Marco Srinivas.Sreemanthula@nokia.com wrote: > >Can you explain why? If the host is fixed, all that is required is some > signal at L2 that causes the power management hardware to spin up the > disk and turn on the CPU. > > It will certainly work to wake up the host. Anyway, if you feel that such problems are within the Seamoby charter then it is fine. However, I woould like to bring the following charter item description for DMHA. > > Dormant Mode Host Alerting > > Third, the Working Group will define the requirements for Dormant Mode Host Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a protocol will be developed to tackle this problem. DMHA is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. DMHA enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. > > All work produced by the Working Group will support both IPv4 and IPv6, will follow the congestion control principles in RFC2914 (BCP41), and will undergo a security review prior to WG last call. Protocols developed will be accompanied by MIBs. > > The Working Group will coordinate closely with the aaa, mobileip, pilc, and rohc working groups. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 7 13:09:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11657 for ; Thu, 7 Mar 2002 13:09:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17272; Thu, 7 Mar 2002 12:55:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17162 for ; Thu, 7 Mar 2002 12:55:37 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10693 for ; Thu, 7 Mar 2002 12:54:10 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g27Hrge25978 for ; Thu, 7 Mar 2002 09:53:42 -0800 (PST) Message-ID: <00a601c1c600$cbb59820$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 7 Mar 2002 09:52:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] To Draft and WG Draft Editors Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit If you are working on a draft for Seamoby or are a WG Draft Editor, you need to read the following documents: http://www.rfc-editor.org/policy.html http://www.ietf.org/ID-nits.html Following these guidelines will assure that documents coming before the IESG are not bounced for editorial reasons. Thanx. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 7 13:09:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11671 for ; Thu, 7 Mar 2002 13:09:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18548 for seamoby-archive@odin.ietf.org; Thu, 7 Mar 2002 13:09:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17272; Thu, 7 Mar 2002 12:55:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17162 for ; Thu, 7 Mar 2002 12:55:37 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10693 for ; Thu, 7 Mar 2002 12:54:10 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g27Hrge25978 for ; Thu, 7 Mar 2002 09:53:42 -0800 (PST) Message-ID: <00a601c1c600$cbb59820$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Thu, 7 Mar 2002 09:52:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] To Draft and WG Draft Editors Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit If you are working on a draft for Seamoby or are a WG Draft Editor, you need to read the following documents: http://www.rfc-editor.org/policy.html http://www.ietf.org/ID-nits.html Following these guidelines will assure that documents coming before the IESG are not bounced for editorial reasons. Thanx. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 8 19:50:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13948 for ; Fri, 8 Mar 2002 19:50:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16862; Fri, 8 Mar 2002 19:39:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16829 for ; Fri, 8 Mar 2002 19:39:57 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13681 for ; Fri, 8 Mar 2002 19:39:55 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g290dQe00371 for ; Fri, 8 Mar 2002 16:39:26 -0800 (PST) Message-ID: <01f301c1c702$a3b0cea0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 8 Mar 2002 16:37:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CAR Discovery Requirements Discussion at IETF 53 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit If you would like to suggest a change in the requirements for CAR discovery (draft-krishnamurthi-car-discovery-requirements-01.txt), please do so on the list prior to the meeting. In order to make progress on the requirements, we want to restrict discussion to issues that have been explicitly raised on the list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 8 19:50:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13958 for ; Fri, 8 Mar 2002 19:50:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17647 for seamoby-archive@odin.ietf.org; Fri, 8 Mar 2002 19:50:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16862; Fri, 8 Mar 2002 19:39:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16829 for ; Fri, 8 Mar 2002 19:39:57 -0500 (EST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13681 for ; Fri, 8 Mar 2002 19:39:55 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g290dQe00371 for ; Fri, 8 Mar 2002 16:39:26 -0800 (PST) Message-ID: <01f301c1c702$a3b0cea0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Fri, 8 Mar 2002 16:37:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CAR Discovery Requirements Discussion at IETF 53 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit If you would like to suggest a change in the requirements for CAR discovery (draft-krishnamurthi-car-discovery-requirements-01.txt), please do so on the list prior to the meeting. In order to make progress on the requirements, we want to restrict discussion to issues that have been explicitly raised on the list. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 11 06:26:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04875 for ; Mon, 11 Mar 2002 06:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04931; Mon, 11 Mar 2002 06:03:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04900 for ; Mon, 11 Mar 2002 06:03:05 -0500 (EST) Received: from eugnpop1.eugn.uswest.net (eugnpop1.eugn.uswest.net [207.109.240.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04216 for ; Mon, 11 Mar 2002 06:03:00 -0500 (EST) Message-Id: <200203111103.GAA04216@ietf.org> Received: (qmail 26813 invoked by uid 0); 11 Mar 2002 11:03:02 -0000 Received: from unknown (HELO SOLTANI) (63.224.205.30) by eugnpop1.eugn.uswest.net with SMTP; 11 Mar 2002 11:03:02 -0000 Date: Mon, 11 Mar 2002 03:14:22 -0800 From: "Jamshid Pashutan" <> To: seamoby@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: SA-SMTPMail 1.0 (http://www.aspstudio.com) Reply-To: pashutan@qwest.net Content-Transfer-Encoding: 7bit Subject: [Seamoby] Urgent! Iran! Can you help? Please also forward. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The purpose of my letter is to introduce the Azadegan Foundation and to request your assistance. The Azadegan Foundation is a Not-for-Profit 501c3 organization dedicated to the promotion of democracy, human rights, and the establishment of a secular government in Iran. Our organization has a concrete, measurable strategy for facilitating change, and it is crucial for us at this juncture to secure your financial and moral support in order to accomplish our objectives. The clerical clique in Tehran views the world as a Mosque to be run by clerics who are inspired by the ecumenical revolutionary ideals of Ayatollah Khomeini. As each day passes, The Islamic regime of Tehran is ever increasing its covert political, financial, military and logistical support to a variety of terrorist groups. Citizens who have risen against the tyrannical rule of the clerics have been repressed brutally. Despite the danger they face, they are demanding that the regime put an end to its arbitrary rule, and to free political prisoners. Their struggle will continue and will intensify until the retreat of the ruling clerics to mosques, and the ultimate transfer of power to the people. Today, persecution of religious minorities continues, almost all pro-democracy newspapers have been shut down, and editors and writers have been imprisoned. Student leaders and all nationalist opposition leaders are being arrested and mercilessly tortured in prison, and women (even pregnant women) are stoned to death. Iran's population is now 70 million, with 45 million under 25 years of age. The economic situation and the over all standard of living is rapidly deteriorating. Discontent among the military, and even the Revolutionary Guard created by the regime, is ever increasing. Religious leaders and religious foundations totally control the economy. The Iranian people desire freedom, democracy, and the establishment of a secular Government. Please reply to this Email for more information about volunteering or supporting the Azadegan Foundation. Support the struggle of the Iranian people! Volunteers are always welcome. Contributions and Inquiries should be addressed to: Azadegan Foundation, PO Box 40152, Washington, DC 20016, USA Phone 541-606-3050 Fax 202-363-5985. Email: pashutan@qwest.net Thank you very much for your time and consideration in to this matter. I look forward to speaking with you further. Please forward this letter to your friends and associates. You can help make a difference! Sincerely Yours, Jamshid Pashutan Advocate for the People Please reply by Email, call us, fax, or snail mail us for more information and reference material. Email me at:: pashutan@qwest.net You received this Email because we aquire Email lists of individuals who may be interested in supporting the Iranian people and their struggle for freedom and democracy. If you have received this message in error, or if you do not wish any further communications from our office, Please respond with 'remove' in the subject line. To stop all Emails instantly, Email pashutan@qwest.net with subject of 'remove'. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 11 06:26:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04885 for ; Mon, 11 Mar 2002 06:26:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07717 for seamoby-archive@odin.ietf.org; Mon, 11 Mar 2002 06:26:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04931; Mon, 11 Mar 2002 06:03:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04900 for ; Mon, 11 Mar 2002 06:03:05 -0500 (EST) Received: from eugnpop1.eugn.uswest.net (eugnpop1.eugn.uswest.net [207.109.240.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04216 for ; Mon, 11 Mar 2002 06:03:00 -0500 (EST) Message-Id: <200203111103.GAA04216@ietf.org> Received: (qmail 26813 invoked by uid 0); 11 Mar 2002 11:03:02 -0000 Received: from unknown (HELO SOLTANI) (63.224.205.30) by eugnpop1.eugn.uswest.net with SMTP; 11 Mar 2002 11:03:02 -0000 Date: Mon, 11 Mar 2002 03:14:22 -0800 From: "Jamshid Pashutan" <> To: seamoby@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: SA-SMTPMail 1.0 (http://www.aspstudio.com) Reply-To: pashutan@qwest.net Content-Transfer-Encoding: 7bit Subject: [Seamoby] Urgent! Iran! Can you help? Please also forward. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The purpose of my letter is to introduce the Azadegan Foundation and to request your assistance. The Azadegan Foundation is a Not-for-Profit 501c3 organization dedicated to the promotion of democracy, human rights, and the establishment of a secular government in Iran. Our organization has a concrete, measurable strategy for facilitating change, and it is crucial for us at this juncture to secure your financial and moral support in order to accomplish our objectives. The clerical clique in Tehran views the world as a Mosque to be run by clerics who are inspired by the ecumenical revolutionary ideals of Ayatollah Khomeini. As each day passes, The Islamic regime of Tehran is ever increasing its covert political, financial, military and logistical support to a variety of terrorist groups. Citizens who have risen against the tyrannical rule of the clerics have been repressed brutally. Despite the danger they face, they are demanding that the regime put an end to its arbitrary rule, and to free political prisoners. Their struggle will continue and will intensify until the retreat of the ruling clerics to mosques, and the ultimate transfer of power to the people. Today, persecution of religious minorities continues, almost all pro-democracy newspapers have been shut down, and editors and writers have been imprisoned. Student leaders and all nationalist opposition leaders are being arrested and mercilessly tortured in prison, and women (even pregnant women) are stoned to death. Iran's population is now 70 million, with 45 million under 25 years of age. The economic situation and the over all standard of living is rapidly deteriorating. Discontent among the military, and even the Revolutionary Guard created by the regime, is ever increasing. Religious leaders and religious foundations totally control the economy. The Iranian people desire freedom, democracy, and the establishment of a secular Government. Please reply to this Email for more information about volunteering or supporting the Azadegan Foundation. Support the struggle of the Iranian people! Volunteers are always welcome. Contributions and Inquiries should be addressed to: Azadegan Foundation, PO Box 40152, Washington, DC 20016, USA Phone 541-606-3050 Fax 202-363-5985. Email: pashutan@qwest.net Thank you very much for your time and consideration in to this matter. I look forward to speaking with you further. Please forward this letter to your friends and associates. You can help make a difference! Sincerely Yours, Jamshid Pashutan Advocate for the People Please reply by Email, call us, fax, or snail mail us for more information and reference material. Email me at:: pashutan@qwest.net You received this Email because we aquire Email lists of individuals who may be interested in supporting the Iranian people and their struggle for freedom and democracy. If you have received this message in error, or if you do not wish any further communications from our office, Please respond with 'remove' in the subject line. To stop all Emails instantly, Email pashutan@qwest.net with subject of 'remove'. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 11 13:06:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17935 for ; Mon, 11 Mar 2002 13:06:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04218; Mon, 11 Mar 2002 12:50:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04193 for ; Mon, 11 Mar 2002 12:50:05 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17334 for ; Mon, 11 Mar 2002 12:50:02 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2BHnYI15314 for ; Mon, 11 Mar 2002 09:49:34 -0800 (PST) Message-ID: <012f01c1c924$e1915bd0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 11 Mar 2002 09:47:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Agenda for IETF 53 Meeting Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, Here is the agenda for the Seamboy meeting. We have two short talks scheduled by prominent Internet architects on technical topics, namely paging and the Internet architecture and CAR discovery and routing information distribution. As yet, we have not received definitive notice from the people who we have asked that they will attend. If they are unable to make it, we will extend the discussions to cover the time. Note also that in order to bring an issue up in the discussion period *it must first be discussed on the list*. New technical issues will be tabled for discussion on the list until after the meeting. There has been much discussion on paging, so we will likely have lots to talk about. On the other hand, there has been little or no discussion on CAR discovery requirements, so we may have nothing to talk about unless some issues are raised this week. The goal of the technical discussions is to air all the issues around a the technical topics, and hopefully come to concensus on the right solutions, taking into account engineering tradeoffs. jak ------------------------------------------------------------------------ ---------------------------------------- - - Agenda Bashing (co-chairs, 5 min.) - - Current draft status (co-chairs, 5 min.) - - Proposal for CT protocol selection process (co-chairs 10 minutes) - - Discussion of Paging and the Internet Architecture (Mystery Guest, 10 minutes) - - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) - - Discussion of CAR Discovery and Routing Information Distribution (Mystery Guest, 10 minutes) - - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 minutes) draft-krishnamurthi-car-requirements-00.txt _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 11 13:06:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17945 for ; Mon, 11 Mar 2002 13:06:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05512 for seamoby-archive@odin.ietf.org; Mon, 11 Mar 2002 13:06:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04218; Mon, 11 Mar 2002 12:50:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04193 for ; Mon, 11 Mar 2002 12:50:05 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17334 for ; Mon, 11 Mar 2002 12:50:02 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2BHnYI15314 for ; Mon, 11 Mar 2002 09:49:34 -0800 (PST) Message-ID: <012f01c1c924$e1915bd0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 11 Mar 2002 09:47:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Agenda for IETF 53 Meeting Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, Here is the agenda for the Seamboy meeting. We have two short talks scheduled by prominent Internet architects on technical topics, namely paging and the Internet architecture and CAR discovery and routing information distribution. As yet, we have not received definitive notice from the people who we have asked that they will attend. If they are unable to make it, we will extend the discussions to cover the time. Note also that in order to bring an issue up in the discussion period *it must first be discussed on the list*. New technical issues will be tabled for discussion on the list until after the meeting. There has been much discussion on paging, so we will likely have lots to talk about. On the other hand, there has been little or no discussion on CAR discovery requirements, so we may have nothing to talk about unless some issues are raised this week. The goal of the technical discussions is to air all the issues around a the technical topics, and hopefully come to concensus on the right solutions, taking into account engineering tradeoffs. jak ------------------------------------------------------------------------ ---------------------------------------- - - Agenda Bashing (co-chairs, 5 min.) - - Current draft status (co-chairs, 5 min.) - - Proposal for CT protocol selection process (co-chairs 10 minutes) - - Discussion of Paging and the Internet Architecture (Mystery Guest, 10 minutes) - - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) - - Discussion of CAR Discovery and Routing Information Distribution (Mystery Guest, 10 minutes) - - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 minutes) draft-krishnamurthi-car-requirements-00.txt _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 11 13:26:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18402 for ; Mon, 11 Mar 2002 13:26:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05789; Mon, 11 Mar 2002 13:11:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05759 for ; Mon, 11 Mar 2002 13:11:57 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18073 for ; Mon, 11 Mar 2002 13:11:53 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2BIBP428254 for ; Mon, 11 Mar 2002 12:11:25 -0600 (CST) Message-ID: <3C8CF34A.6050201@alcatel.com> Date: Mon, 11 Mar 2002 12:11:22 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting References: <012f01c1c924$e1915bd0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Are we going to have a Seamgirl meeting also? Just a joke! James Kempf wrote: >Folks, > >Here is the agenda for the Seamboy meeting. > -------------------------------------- -------------- > >We have two short talks scheduled by prominent Internet architects on >technical topics, namely paging and the Internet architecture and CAR >discovery and routing information distribution. As yet, we have not >received definitive notice from the people who we have asked that they >will attend. If they are unable to make it, we will extend the >discussions to cover the time. > >Note also that in order to bring an issue up in the discussion period >*it must first be discussed on the list*. New technical issues will be >tabled for discussion on the list until after the meeting. There has >been much discussion on paging, so we will likely have lots to talk >about. On the other hand, there has been little or no discussion on CAR >discovery requirements, so we may have nothing to talk about unless some >issues are raised this week. > >The goal of the technical discussions is to air all the issues around a >the technical topics, and hopefully come to concensus on the right >solutions, taking into account engineering tradeoffs. > > jak > >------------------------------------------------------------------------ >---------------------------------------- > >- - Agenda Bashing (co-chairs, 5 min.) > >- - Current draft status (co-chairs, 5 min.) > >- - Proposal for CT protocol selection process (co-chairs 10 minutes) > >- - Discussion of Paging and the Internet Architecture (Mystery Guest, >10 >minutes) > >- - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) > >- - Discussion of CAR Discovery and Routing Information Distribution >(Mystery Guest, 10 minutes) > >- - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 >minutes) > > draft-krishnamurthi-car-requirements-00.txt > > > > --behcet > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 11 13:26:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18412 for ; Mon, 11 Mar 2002 13:26:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06488 for seamoby-archive@odin.ietf.org; Mon, 11 Mar 2002 13:26:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05789; Mon, 11 Mar 2002 13:11:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05759 for ; Mon, 11 Mar 2002 13:11:57 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18073 for ; Mon, 11 Mar 2002 13:11:53 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2BIBP428254 for ; Mon, 11 Mar 2002 12:11:25 -0600 (CST) Message-ID: <3C8CF34A.6050201@alcatel.com> Date: Mon, 11 Mar 2002 12:11:22 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting References: <012f01c1c924$e1915bd0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Are we going to have a Seamgirl meeting also? Just a joke! James Kempf wrote: >Folks, > >Here is the agenda for the Seamboy meeting. > -------------------------------------- -------------- > >We have two short talks scheduled by prominent Internet architects on >technical topics, namely paging and the Internet architecture and CAR >discovery and routing information distribution. As yet, we have not >received definitive notice from the people who we have asked that they >will attend. If they are unable to make it, we will extend the >discussions to cover the time. > >Note also that in order to bring an issue up in the discussion period >*it must first be discussed on the list*. New technical issues will be >tabled for discussion on the list until after the meeting. There has >been much discussion on paging, so we will likely have lots to talk >about. On the other hand, there has been little or no discussion on CAR >discovery requirements, so we may have nothing to talk about unless some >issues are raised this week. > >The goal of the technical discussions is to air all the issues around a >the technical topics, and hopefully come to concensus on the right >solutions, taking into account engineering tradeoffs. > > jak > >------------------------------------------------------------------------ >---------------------------------------- > >- - Agenda Bashing (co-chairs, 5 min.) > >- - Current draft status (co-chairs, 5 min.) > >- - Proposal for CT protocol selection process (co-chairs 10 minutes) > >- - Discussion of Paging and the Internet Architecture (Mystery Guest, >10 >minutes) > >- - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) > >- - Discussion of CAR Discovery and Routing Information Distribution >(Mystery Guest, 10 minutes) > >- - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 >minutes) > > draft-krishnamurthi-car-requirements-00.txt > > > > --behcet > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 12 10:16:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24203 for ; Tue, 12 Mar 2002 10:16:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16601; Tue, 12 Mar 2002 09:59:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16568 for ; Tue, 12 Mar 2002 09:59:11 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23824 for ; Tue, 12 Mar 2002 09:59:08 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 09:57:41 -0500 Message-ID: From: "Shahrier, Sharif M." To: seamoby@ietf.org, "'mobile-ip@sunroof.eng.sun.com'" Cc: "Shahrier, Sharif M." Subject: [Seamoby] IEEE Std 802.11 Date: Tue, 12 Mar 2002 09:57:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello, I submitted this e-mail as a request to find out if anyone was working with IEEE Std 802.11 Wireless LAN. I am currently working on this, and at this time interested in the MAC-layer. Partcularly, the media access functions DCF and PCF, and enhancements thereof. Thus, I was wondering if anyone else was also working on this, perhaps implementation and modeling work, and simulation. Later, I also have plans to look at IP-layer enhancements such as transporting MAC frames from one ESS to another across multiple Aps. If anyone is involved in these topics, and would like some discussions, perhaps you can drop me an e-mail. Also, please let me know if you plan to be in Minneapolis, I am going to be there next week. Thank you very much. Sharif. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 12 10:16:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24212 for ; Tue, 12 Mar 2002 10:16:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17806 for seamoby-archive@odin.ietf.org; Tue, 12 Mar 2002 10:17:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16601; Tue, 12 Mar 2002 09:59:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16568 for ; Tue, 12 Mar 2002 09:59:11 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23824 for ; Tue, 12 Mar 2002 09:59:08 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 09:57:41 -0500 Message-ID: From: "Shahrier, Sharif M." To: seamoby@ietf.org, "'mobile-ip@sunroof.eng.sun.com'" Cc: "Shahrier, Sharif M." Subject: [Seamoby] IEEE Std 802.11 Date: Tue, 12 Mar 2002 09:57:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello, I submitted this e-mail as a request to find out if anyone was working with IEEE Std 802.11 Wireless LAN. I am currently working on this, and at this time interested in the MAC-layer. Partcularly, the media access functions DCF and PCF, and enhancements thereof. Thus, I was wondering if anyone else was also working on this, perhaps implementation and modeling work, and simulation. Later, I also have plans to look at IP-layer enhancements such as transporting MAC frames from one ESS to another across multiple Aps. If anyone is involved in these topics, and would like some discussions, perhaps you can drop me an e-mail. Also, please let me know if you plan to be in Minneapolis, I am going to be there next week. Thank you very much. Sharif. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 12 14:11:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01942 for ; Tue, 12 Mar 2002 14:11:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01430; Tue, 12 Mar 2002 13:49:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01394 for ; Tue, 12 Mar 2002 13:49:35 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01157 for ; Tue, 12 Mar 2002 13:49:32 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CIpkx01795 for ; Tue, 12 Mar 2002 12:51:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Mar 2002 12:49:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 12:48:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 12 Mar 2002 13:48:47 -0500 Message-ID: Thread-Topic: CAR Discovery Requirements Thread-Index: AcHJ9ouGDDqRdcHaQa605Q7EPbAbAw== To: X-OriginalArrivalTime: 12 Mar 2002 18:48:49.0108 (UTC) FILETIME=[8C00B940:01C1C9F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA01395 Subject: [Seamoby] CAR Discovery Requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi all, I'd like to propose the following requirement to be added to the CAR discovery requirements list: "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 12 15:11:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01951 for ; Tue, 12 Mar 2002 14:11:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02903 for seamoby-archive@odin.ietf.org; Tue, 12 Mar 2002 14:11:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01430; Tue, 12 Mar 2002 13:49:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01394 for ; Tue, 12 Mar 2002 13:49:35 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01157 for ; Tue, 12 Mar 2002 13:49:32 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CIpkx01795 for ; Tue, 12 Mar 2002 12:51:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Mar 2002 12:49:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 12:48:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 12 Mar 2002 13:48:47 -0500 Message-ID: Thread-Topic: CAR Discovery Requirements Thread-Index: AcHJ9ouGDDqRdcHaQa605Q7EPbAbAw== To: X-OriginalArrivalTime: 12 Mar 2002 18:48:49.0108 (UTC) FILETIME=[8C00B940:01C1C9F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA01395 Subject: [Seamoby] CAR Discovery Requirements Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi all, I'd like to propose the following requirement to be added to the CAR discovery requirements list: "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 12 15:42:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06263 for ; Tue, 12 Mar 2002 15:42:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09285; Tue, 12 Mar 2002 15:28:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09239 for ; Tue, 12 Mar 2002 15:28:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05694 for ; Tue, 12 Mar 2002 15:28:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CKSLI29270; Tue, 12 Mar 2002 12:28:21 -0800 (PST) Message-ID: <020b01c1ca04$39d70f80$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 12:26:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > "3.xx Providing MN's requirement for Determination of CARs > > The fundamental task of CAR discovery is to determine candidate > access routers (from the set of GAARs) that meet MN's requirements, > if known at the time of handoff. A CAR discovery protocol MUST > determine a set of CARs that meet MN's requirements. For this, > a CAR discovery protocol MUST provide means for the MN to express > these requirements." > I think this is confusing two issues: - Distribution of routing reachability and capability information. - Expression of MN requirements or rights. The second issue may require, for example, AAA, or it may be implemented using an AAA protocol. I think it would make more sense to keep these issues separate. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 12 15:42:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06279 for ; Tue, 12 Mar 2002 15:42:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10308 for seamoby-archive@odin.ietf.org; Tue, 12 Mar 2002 15:42:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09285; Tue, 12 Mar 2002 15:28:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09239 for ; Tue, 12 Mar 2002 15:28:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05694 for ; Tue, 12 Mar 2002 15:28:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CKSLI29270; Tue, 12 Mar 2002 12:28:21 -0800 (PST) Message-ID: <020b01c1ca04$39d70f80$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 12:26:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > "3.xx Providing MN's requirement for Determination of CARs > > The fundamental task of CAR discovery is to determine candidate > access routers (from the set of GAARs) that meet MN's requirements, > if known at the time of handoff. A CAR discovery protocol MUST > determine a set of CARs that meet MN's requirements. For this, > a CAR discovery protocol MUST provide means for the MN to express > these requirements." > I think this is confusing two issues: - Distribution of routing reachability and capability information. - Expression of MN requirements or rights. The second issue may require, for example, AAA, or it may be implemented using an AAA protocol. I think it would make more sense to keep these issues separate. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 12 16:18:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08014 for ; Tue, 12 Mar 2002 16:18:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12508; Tue, 12 Mar 2002 16:07:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12482 for ; Tue, 12 Mar 2002 16:07:20 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07410 for ; Tue, 12 Mar 2002 16:07:17 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CL9Vx15366 for ; Tue, 12 Mar 2002 15:09:31 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Mar 2002 15:07:17 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 15:06:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 16:06:36 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHKBHf30RB9XHZVTsS71r6eEXjNrQABI8lQ To: , X-OriginalArrivalTime: 12 Mar 2002 21:06:37.0458 (UTC) FILETIME=[CC52CF20:01C1CA09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA12484 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, I don't see that the requirement is addressing the distribution of the information. There is another requirement for this, namely 3.4. The present one is merely addressing that a solution has to match the set of GAAR+capabilities with MN's requirements to determine the set of CARs. This is essentially what CAR discovery is about, isn't it? Whether you use existing protocols for certain parts is not prohibited by the chosen wording. You might use AAA to express the requirements. Still, a CAR discovery protocol has to match these requirements onto the available GAAR+cap info. How this is done depends on the solution. Regards, Dirk -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, March 12, 2002 3:27 PM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CAR Discovery Requirements Dirk, > "3.xx Providing MN's requirement for Determination of CARs > > The fundamental task of CAR discovery is to determine candidate > access routers (from the set of GAARs) that meet MN's requirements, > if known at the time of handoff. A CAR discovery protocol MUST > determine a set of CARs that meet MN's requirements. For this, > a CAR discovery protocol MUST provide means for the MN to express > these requirements." > I think this is confusing two issues: - Distribution of routing reachability and capability information. - Expression of MN requirements or rights. The second issue may require, for example, AAA, or it may be implemented using an AAA protocol. I think it would make more sense to keep these issues separate. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 12 16:18:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08026 for ; Tue, 12 Mar 2002 16:18:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13135 for seamoby-archive@odin.ietf.org; Tue, 12 Mar 2002 16:18:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12508; Tue, 12 Mar 2002 16:07:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12482 for ; Tue, 12 Mar 2002 16:07:20 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07410 for ; Tue, 12 Mar 2002 16:07:17 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CL9Vx15366 for ; Tue, 12 Mar 2002 15:09:31 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Mar 2002 15:07:17 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 15:06:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 16:06:36 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHKBHf30RB9XHZVTsS71r6eEXjNrQABI8lQ To: , X-OriginalArrivalTime: 12 Mar 2002 21:06:37.0458 (UTC) FILETIME=[CC52CF20:01C1CA09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA12484 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, I don't see that the requirement is addressing the distribution of the information. There is another requirement for this, namely 3.4. The present one is merely addressing that a solution has to match the set of GAAR+capabilities with MN's requirements to determine the set of CARs. This is essentially what CAR discovery is about, isn't it? Whether you use existing protocols for certain parts is not prohibited by the chosen wording. You might use AAA to express the requirements. Still, a CAR discovery protocol has to match these requirements onto the available GAAR+cap info. How this is done depends on the solution. Regards, Dirk -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, March 12, 2002 3:27 PM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CAR Discovery Requirements Dirk, > "3.xx Providing MN's requirement for Determination of CARs > > The fundamental task of CAR discovery is to determine candidate > access routers (from the set of GAARs) that meet MN's requirements, > if known at the time of handoff. A CAR discovery protocol MUST > determine a set of CARs that meet MN's requirements. For this, > a CAR discovery protocol MUST provide means for the MN to express > these requirements." > I think this is confusing two issues: - Distribution of routing reachability and capability information. - Expression of MN requirements or rights. The second issue may require, for example, AAA, or it may be implemented using an AAA protocol. I think it would make more sense to keep these issues separate. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 12 16:40:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08865 for ; Tue, 12 Mar 2002 16:40:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13760; Tue, 12 Mar 2002 16:28:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13729 for ; Tue, 12 Mar 2002 16:28:52 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08481 for ; Tue, 12 Mar 2002 16:28:48 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CLSJI01860; Tue, 12 Mar 2002 13:28:19 -0800 (PST) Message-ID: <02cb01c1ca0c$9a6ae6c0$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 13:26:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I don't see that the requirement is addressing the distribution > of the information. There is another requirement for this, namely > 3.4. The present one is merely addressing that a solution has to > match the set of GAAR+capabilities with MN's requirements to determine > the set of CARs. This is essentially what CAR discovery is about, isn't > it? > What 3.4 states is: 3.4. CAPABILITY DISCOVERY The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. This says nothing about the MN's capability requirements. In fact, if you look at the last item in Section 3 of draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm, the selection of a target router, which would involve matching the MN's requests with the AR capabilities, is explicitly excluded from the problem statement. > Whether you use existing protocols for certain parts is not > prohibited by the chosen wording. You might use AAA to express > the requirements. Still, a CAR discovery protocol has to match > these requirements onto the available GAAR+cap info. How this > is done depends on the solution. > According to Section 3 of draft-ietf-seamoby-cardiscovery-issues-02.txt, this is out of scope of the problem. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 12 16:40:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08884 for ; Tue, 12 Mar 2002 16:40:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14852 for seamoby-archive@odin.ietf.org; Tue, 12 Mar 2002 16:40:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13760; Tue, 12 Mar 2002 16:28:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13729 for ; Tue, 12 Mar 2002 16:28:52 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08481 for ; Tue, 12 Mar 2002 16:28:48 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CLSJI01860; Tue, 12 Mar 2002 13:28:19 -0800 (PST) Message-ID: <02cb01c1ca0c$9a6ae6c0$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 13:26:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I don't see that the requirement is addressing the distribution > of the information. There is another requirement for this, namely > 3.4. The present one is merely addressing that a solution has to > match the set of GAAR+capabilities with MN's requirements to determine > the set of CARs. This is essentially what CAR discovery is about, isn't > it? > What 3.4 states is: 3.4. CAPABILITY DISCOVERY The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. This says nothing about the MN's capability requirements. In fact, if you look at the last item in Section 3 of draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm, the selection of a target router, which would involve matching the MN's requests with the AR capabilities, is explicitly excluded from the problem statement. > Whether you use existing protocols for certain parts is not > prohibited by the chosen wording. You might use AAA to express > the requirements. Still, a CAR discovery protocol has to match > these requirements onto the available GAAR+cap info. How this > is done depends on the solution. > According to Section 3 of draft-ietf-seamoby-cardiscovery-issues-02.txt, this is out of scope of the problem. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 12 17:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09744 for ; Tue, 12 Mar 2002 17:01:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15270; Tue, 12 Mar 2002 16:50:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15245 for ; Tue, 12 Mar 2002 16:50:02 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09330 for ; Tue, 12 Mar 2002 16:49:58 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CLoDZ26423 for ; Tue, 12 Mar 2002 23:50:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Mar 2002 23:50:01 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 23:50:01 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 15:49:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 16:49:58 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHKDNpukhCxQNWySDKfoUDD3djG2AAAW8+w To: , X-OriginalArrivalTime: 12 Mar 2002 21:49:59.0646 (UTC) FILETIME=[DB592FE0:01C1CA0F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA15246 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, some comments inline What 3.4 states is: 3.4. CAPABILITY DISCOVERY The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. This says nothing about the MN's capability requirements. [DOT] of course not since it aims at securely exchanging capability information. That's why I wanted to address MN's requirements in a separate protocol requirement. In fact, if you look at the last item in Section 3 of draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm, the selection of a target router, which would involve matching the MN's requests with the AR capabilities, is explicitly excluded from the problem statement. [DOT] The TAR Selection eventually picks one particular AR out of the set of CARs. This 'picking' is out of scope of the CAR discovery. If I look at the definition of CAR, namely "This is an AR that is a candidate for MN's handoff. CAR is necessarily a GAAR of the AR currently serving the MN, and also has the capability set required to serve the MN." and look at the fundamental task of CAR discovery, namely to determine a set of CARs, it means logically for me that I also require means to express these requirements and feed them into CAR discovery. This does not mean that I need a new protocol for expressing these requirements. If I look at CAR discovery as a black box, and I want to define the requirements of this black box, to fulfill the implicit fundamental task that we put in the issues draft, namely "What is required is a protocol that would allow an AR or an MN to discover the neighboring ARs whose capabilities meet the requirements of a MN, thus becoming potential target ARs for handoff." (copied from introduction of issues draft), I came up with this requirement. It merely says, that CAR discovery has to provide this set of CARs that would meet MN's requirement. For that, I need means to express MN's requirements. It does not imply that we have to invent the wheel again for this part, it merely has to be part of this black box to fulfill its task. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 12 17:01:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09760 for ; Tue, 12 Mar 2002 17:01:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16629 for seamoby-archive@odin.ietf.org; Tue, 12 Mar 2002 17:01:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15270; Tue, 12 Mar 2002 16:50:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15245 for ; Tue, 12 Mar 2002 16:50:02 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09330 for ; Tue, 12 Mar 2002 16:49:58 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CLoDZ26423 for ; Tue, 12 Mar 2002 23:50:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Mar 2002 23:50:01 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 23:50:01 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 15:49:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 16:49:58 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHKDNpukhCxQNWySDKfoUDD3djG2AAAW8+w To: , X-OriginalArrivalTime: 12 Mar 2002 21:49:59.0646 (UTC) FILETIME=[DB592FE0:01C1CA0F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA15246 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, some comments inline What 3.4 states is: 3.4. CAPABILITY DISCOVERY The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. This says nothing about the MN's capability requirements. [DOT] of course not since it aims at securely exchanging capability information. That's why I wanted to address MN's requirements in a separate protocol requirement. In fact, if you look at the last item in Section 3 of draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm, the selection of a target router, which would involve matching the MN's requests with the AR capabilities, is explicitly excluded from the problem statement. [DOT] The TAR Selection eventually picks one particular AR out of the set of CARs. This 'picking' is out of scope of the CAR discovery. If I look at the definition of CAR, namely "This is an AR that is a candidate for MN's handoff. CAR is necessarily a GAAR of the AR currently serving the MN, and also has the capability set required to serve the MN." and look at the fundamental task of CAR discovery, namely to determine a set of CARs, it means logically for me that I also require means to express these requirements and feed them into CAR discovery. This does not mean that I need a new protocol for expressing these requirements. If I look at CAR discovery as a black box, and I want to define the requirements of this black box, to fulfill the implicit fundamental task that we put in the issues draft, namely "What is required is a protocol that would allow an AR or an MN to discover the neighboring ARs whose capabilities meet the requirements of a MN, thus becoming potential target ARs for handoff." (copied from introduction of issues draft), I came up with this requirement. It merely says, that CAR discovery has to provide this set of CARs that would meet MN's requirement. For that, I need means to express MN's requirements. It does not imply that we have to invent the wheel again for this part, it merely has to be part of this black box to fulfill its task. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 12 17:56:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11110 for ; Tue, 12 Mar 2002 17:56:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20399; Tue, 12 Mar 2002 17:45:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20372 for ; Tue, 12 Mar 2002 17:45:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10860 for ; Tue, 12 Mar 2002 17:45:11 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CMigI04784; Tue, 12 Mar 2002 14:44:42 -0800 (PST) Message-ID: <032401c1ca17$45f2e790$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 14:43:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > In fact, if you look at the last item in Section 3 of > draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm, > the selection of a target router, which would involve matching the MN's > requests with the AR capabilities, is explicitly excluded from the > problem > statement. > > [DOT] The TAR Selection eventually picks one particular AR out of > the set of CARs. This 'picking' is out of scope of the CAR discovery. > If I look at the definition of CAR, namely > "This is an AR that is a candidate for MN's handoff. CAR is necessarily > a GAAR of the AR currently serving the MN, and also has the capability > set required to serve the MN." > Well, here we have a basic disagreement about what is involved in TAR selection. IMHO, TAR selection includes everything including communication of MN requirements. The reason I believe this is because communication of the requirements may require functions such as: - verifying that the MN is, in fact, authorized to get what it is asking. - arranging for accounting information so that the owner of the MN can be billed appropriately for what it is asking. - authenticating the exchange with the MN so that the AR (or whatever other network entity is involved in doing TAR selection) knows that they come from an authorized MN and not from a freeloader. - securing the exchange between the MN and the AR or other entity implementing the MN's selection. These functions are separate from communicating routing reachability and router capability information, even if the MN is involved in propagating the reachability and capability information (as, I believe, it may be in CAR discovery). The AAA functions are completely orthogonal, as are the security functions. > and look at the fundamental task of CAR discovery, namely to determine a set of > CARs, it means logically for me that I also require means to express > these requirements and feed them into CAR discovery. This does not > mean that I need a new protocol for expressing these requirements. > If I look at CAR discovery as a black box, and I want to define the > requirements of this black box, to fulfill the implicit fundamental > task that we put in the issues draft, namely > "What is required is a protocol that would allow an AR or an MN to discover > the neighboring ARs whose capabilities meet the requirements of > a MN, thus becoming potential target ARs for handoff." (copied from > introduction of issues draft), > I came up with this requirement. It merely says, that CAR discovery has > to provide this set of CARs that would meet MN's requirement. For that, > I need means to express MN's requirements. It does not imply that we > have to invent the wheel again for this part, it merely has to be part > of this black box to fulfill its task. > Perhaps what we need is "requirements for TAR selection." One requirement is that the MN communicate its requirements. There is no need to for the AR to know the MN's requirements just to select GAARs. I remember us very clearly discussing this when we were writing draft-ietf-seamoby-cardiscovery-issues-02.txt, but perhaps we took away two different interpretations of the discussion. Anybody else in the WG care to comment? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 12 17:56:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11130 for ; Tue, 12 Mar 2002 17:56:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20918 for seamoby-archive@odin.ietf.org; Tue, 12 Mar 2002 17:56:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20399; Tue, 12 Mar 2002 17:45:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20372 for ; Tue, 12 Mar 2002 17:45:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10860 for ; Tue, 12 Mar 2002 17:45:11 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CMigI04784; Tue, 12 Mar 2002 14:44:42 -0800 (PST) Message-ID: <032401c1ca17$45f2e790$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Tue, 12 Mar 2002 14:43:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > In fact, if you look at the last item in Section 3 of > draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm, > the selection of a target router, which would involve matching the MN's > requests with the AR capabilities, is explicitly excluded from the > problem > statement. > > [DOT] The TAR Selection eventually picks one particular AR out of > the set of CARs. This 'picking' is out of scope of the CAR discovery. > If I look at the definition of CAR, namely > "This is an AR that is a candidate for MN's handoff. CAR is necessarily > a GAAR of the AR currently serving the MN, and also has the capability > set required to serve the MN." > Well, here we have a basic disagreement about what is involved in TAR selection. IMHO, TAR selection includes everything including communication of MN requirements. The reason I believe this is because communication of the requirements may require functions such as: - verifying that the MN is, in fact, authorized to get what it is asking. - arranging for accounting information so that the owner of the MN can be billed appropriately for what it is asking. - authenticating the exchange with the MN so that the AR (or whatever other network entity is involved in doing TAR selection) knows that they come from an authorized MN and not from a freeloader. - securing the exchange between the MN and the AR or other entity implementing the MN's selection. These functions are separate from communicating routing reachability and router capability information, even if the MN is involved in propagating the reachability and capability information (as, I believe, it may be in CAR discovery). The AAA functions are completely orthogonal, as are the security functions. > and look at the fundamental task of CAR discovery, namely to determine a set of > CARs, it means logically for me that I also require means to express > these requirements and feed them into CAR discovery. This does not > mean that I need a new protocol for expressing these requirements. > If I look at CAR discovery as a black box, and I want to define the > requirements of this black box, to fulfill the implicit fundamental > task that we put in the issues draft, namely > "What is required is a protocol that would allow an AR or an MN to discover > the neighboring ARs whose capabilities meet the requirements of > a MN, thus becoming potential target ARs for handoff." (copied from > introduction of issues draft), > I came up with this requirement. It merely says, that CAR discovery has > to provide this set of CARs that would meet MN's requirement. For that, > I need means to express MN's requirements. It does not imply that we > have to invent the wheel again for this part, it merely has to be part > of this black box to fulfill its task. > Perhaps what we need is "requirements for TAR selection." One requirement is that the MN communicate its requirements. There is no need to for the AR to know the MN's requirements just to select GAARs. I remember us very clearly discussing this when we were writing draft-ietf-seamoby-cardiscovery-issues-02.txt, but perhaps we took away two different interpretations of the discussion. Anybody else in the WG care to comment? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 11:08:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09562 for ; Wed, 13 Mar 2002 11:08:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22768; Wed, 13 Mar 2002 10:55:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22745 for ; Wed, 13 Mar 2002 10:55:44 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08865 for ; Wed, 13 Mar 2002 10:55:35 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DFtjZ20245 for ; Wed, 13 Mar 2002 17:55:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 17:55:33 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 17:55:33 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 09:54:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Wed, 13 Mar 2002 10:54:03 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHKF4MSiaG8bRpbSYenJsysPAQFGAAjdyuA To: , X-OriginalArrivalTime: 13 Mar 2002 15:54:04.0782 (UTC) FILETIME=[4D4548E0:01C1CAA7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA22746 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, comments inline... -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, March 12, 2002 5:43 PM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CAR Discovery Requirements Dirk, Well, here we have a basic disagreement about what is involved in TAR selection. IMHO, TAR selection includes everything including communication of MN requirements. The reason I believe this is because communication of the requirements may require functions such as: - verifying that the MN is, in fact, authorized to get what it is asking. - arranging for accounting information so that the owner of the MN can be billed appropriately for what it is asking. - authenticating the exchange with the MN so that the AR (or whatever other network entity is involved in doing TAR selection) knows that they come from an authorized MN and not from a freeloader. - securing the exchange between the MN and the AR or other entity implementing the MN's selection. These functions are separate from communicating routing reachability and router capability information, even if the MN is involved in propagating the reachability and capability information (as, I believe, it may be in CAR discovery). The AAA functions are completely orthogonal, as are the security functions. [DOT] By all due respect, I'm kind of surprised to see these interpretations at this stage of discussion. What I quoted in my previous email is the definition of CARs and the fundamental sentence in the problem statement. In addition, here the definition of TAR selection: "TAR Selection Algorithm The algorithm that determines a unique TAR for MN's handoff from the set of CARs. The exact nature and definition of this algorithm is outside the scope of this document. " With all this information, available in the issues draft for quite a while, I draw the following line - discover GAARs and their capabilities - determine set of CARs (i.e., subset of GAARs that fulfil MN's requirements) - select a unique TAR from this set (i.e., TAR selection) I don't see that much room for interpretation of the terms, at least this interpretation should have been done at appropriate time of the discussion. [DOT] Further, the requirement to provide means to express MN's requirements to be used for the determination of the set of CARs (as I stated in my requirement) does not imply that we have to invent a new protocol for this part of CAR discovery. If I want to solve the CAR discovery problem (which according to the issues draft include the determination of CARs), I have to have means to express MN's requirements. These 'means' might certainly be existing protocols. [DOT] More philosophically, the requirements are meant to define a protocol that solves the CAR discovery problem. The design of such protocol should always be done under the constraint to re-use as much existing functionality as possible. However, the first and strongest requirement is to solve the problem. To do, I do think that this requirement is needed. > and look at the fundamental task of CAR discovery, namely to determine a set of > CARs, it means logically for me that I also require means to express > these requirements and feed them into CAR discovery. This does not > mean that I need a new protocol for expressing these requirements. > If I look at CAR discovery as a black box, and I want to define the > requirements of this black box, to fulfill the implicit fundamental > task that we put in the issues draft, namely > "What is required is a protocol that would allow an AR or an MN to discover > the neighboring ARs whose capabilities meet the requirements of > a MN, thus becoming potential target ARs for handoff." (copied from > introduction of issues draft), > I came up with this requirement. It merely says, that CAR discovery has > to provide this set of CARs that would meet MN's requirement. For that, > I need means to express MN's requirements. It does not imply that we > have to invent the wheel again for this part, it merely has to be part > of this black box to fulfill its task. > Perhaps what we need is "requirements for TAR selection." One requirement is that the MN communicate its requirements. [DOT] Since TAR selection is out of scope, I don't see the necessity and sense of such requirements. As I pointed out above, the need to communicate MN's requirements is already required for the CAR determination. There is no need to for the AR to know the MN's requirements just to select GAARs. [DOT] On what basis do you want to select GAARs? If you plainly determine a subset of GAARs that are reachable by the MN at time of handoff (is it that what you mean?), then you are not determining CARs according to the definition of CARs. You are plainly selecting reachable GAARs. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 13 11:08:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09573 for ; Wed, 13 Mar 2002 11:08:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23762 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 11:08:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22768; Wed, 13 Mar 2002 10:55:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22745 for ; Wed, 13 Mar 2002 10:55:44 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08865 for ; Wed, 13 Mar 2002 10:55:35 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DFtjZ20245 for ; Wed, 13 Mar 2002 17:55:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 17:55:33 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 17:55:33 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 09:54:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Wed, 13 Mar 2002 10:54:03 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHKF4MSiaG8bRpbSYenJsysPAQFGAAjdyuA To: , X-OriginalArrivalTime: 13 Mar 2002 15:54:04.0782 (UTC) FILETIME=[4D4548E0:01C1CAA7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA22746 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, comments inline... -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, March 12, 2002 5:43 PM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CAR Discovery Requirements Dirk, Well, here we have a basic disagreement about what is involved in TAR selection. IMHO, TAR selection includes everything including communication of MN requirements. The reason I believe this is because communication of the requirements may require functions such as: - verifying that the MN is, in fact, authorized to get what it is asking. - arranging for accounting information so that the owner of the MN can be billed appropriately for what it is asking. - authenticating the exchange with the MN so that the AR (or whatever other network entity is involved in doing TAR selection) knows that they come from an authorized MN and not from a freeloader. - securing the exchange between the MN and the AR or other entity implementing the MN's selection. These functions are separate from communicating routing reachability and router capability information, even if the MN is involved in propagating the reachability and capability information (as, I believe, it may be in CAR discovery). The AAA functions are completely orthogonal, as are the security functions. [DOT] By all due respect, I'm kind of surprised to see these interpretations at this stage of discussion. What I quoted in my previous email is the definition of CARs and the fundamental sentence in the problem statement. In addition, here the definition of TAR selection: "TAR Selection Algorithm The algorithm that determines a unique TAR for MN's handoff from the set of CARs. The exact nature and definition of this algorithm is outside the scope of this document. " With all this information, available in the issues draft for quite a while, I draw the following line - discover GAARs and their capabilities - determine set of CARs (i.e., subset of GAARs that fulfil MN's requirements) - select a unique TAR from this set (i.e., TAR selection) I don't see that much room for interpretation of the terms, at least this interpretation should have been done at appropriate time of the discussion. [DOT] Further, the requirement to provide means to express MN's requirements to be used for the determination of the set of CARs (as I stated in my requirement) does not imply that we have to invent a new protocol for this part of CAR discovery. If I want to solve the CAR discovery problem (which according to the issues draft include the determination of CARs), I have to have means to express MN's requirements. These 'means' might certainly be existing protocols. [DOT] More philosophically, the requirements are meant to define a protocol that solves the CAR discovery problem. The design of such protocol should always be done under the constraint to re-use as much existing functionality as possible. However, the first and strongest requirement is to solve the problem. To do, I do think that this requirement is needed. > and look at the fundamental task of CAR discovery, namely to determine a set of > CARs, it means logically for me that I also require means to express > these requirements and feed them into CAR discovery. This does not > mean that I need a new protocol for expressing these requirements. > If I look at CAR discovery as a black box, and I want to define the > requirements of this black box, to fulfill the implicit fundamental > task that we put in the issues draft, namely > "What is required is a protocol that would allow an AR or an MN to discover > the neighboring ARs whose capabilities meet the requirements of > a MN, thus becoming potential target ARs for handoff." (copied from > introduction of issues draft), > I came up with this requirement. It merely says, that CAR discovery has > to provide this set of CARs that would meet MN's requirement. For that, > I need means to express MN's requirements. It does not imply that we > have to invent the wheel again for this part, it merely has to be part > of this black box to fulfill its task. > Perhaps what we need is "requirements for TAR selection." One requirement is that the MN communicate its requirements. [DOT] Since TAR selection is out of scope, I don't see the necessity and sense of such requirements. As I pointed out above, the need to communicate MN's requirements is already required for the CAR determination. There is no need to for the AR to know the MN's requirements just to select GAARs. [DOT] On what basis do you want to select GAARs? If you plainly determine a subset of GAARs that are reachable by the MN at time of handoff (is it that what you mean?), then you are not determining CARs according to the definition of CARs. You are plainly selecting reachable GAARs. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 13:42:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14674 for ; Wed, 13 Mar 2002 13:42:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03049; Wed, 13 Mar 2002 13:23:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03018 for ; Wed, 13 Mar 2002 13:23:12 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14007 for ; Wed, 13 Mar 2002 13:23:09 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DIMcI00505; Wed, 13 Mar 2002 10:22:38 -0800 (PST) Message-ID: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Wed, 13 Mar 2002 10:21:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > IMHO, TAR selection includes everything including communication > of MN requirements. The reason I believe this is because communication > of the requirements may require functions such as: > > - verifying that the MN is, in fact, authorized to get what it is > asking. > > - arranging for accounting information so that the owner of the MN > can be billed appropriately for what it is asking. > > - authenticating the exchange with the MN so that the AR (or > whatever > other network entity is involved in doing TAR selection) knows that > they come from an authorized MN and not from a freeloader. > > - securing the exchange between the MN and the AR or other > entity implementing the MN's selection. > > These functions are separate from communicating routing reachability > and router capability information, even if the MN is involved in > propagating the reachability and capability information (as, I believe, > it may be in CAR discovery). The AAA functions are > completely orthogonal, as are the security functions. > > [DOT] By all due respect, I'm kind of surprised to see these interpretations > at this stage of discussion. What I quoted in my previous email is the > definition of CARs and the fundamental sentence in the problem statement. > In addition, here the definition of TAR selection: > "TAR Selection Algorithm > > The algorithm that determines a unique TAR for MN's handoff from > the set of CARs. The exact nature and definition of this algorithm > is outside the scope of this document. > " > With all this information, available in the issues draft for quite a while, > I draw the following line > - discover GAARs and their capabilities > - determine set of CARs (i.e., subset of GAARs that fulfil MN's requirements) > - select a unique TAR from this set (i.e., TAR selection) > I don't see that much room for interpretation of the terms, at least this > interpretation should have been done at appropriate time of the discussion. > Perhaps I did not state clearly enough what I was trying to say. The point that I was trying to make is similar to the one the Scott Bradner brought up at the last Seamoby meeting in SLC. The security/AAA requirements on a protocol for distributing routing reachability information are likely to be very different from those involving a MN expressing its preferences for capabilities. For example, I believe there is a separate IPsec policy for routing security as opposed to host security. If the CAR discovery information is coming from a host and the routing infrastructure is using this policy, then I would presume that the host must, in some way ensure that the security requirements of the routing infrastructure, and not for hosts, is followed. Similarly, for communicating MN capabilities preferences, a host security/AAA policy needs to be used and not a routing security policy. Conflating these two is likely to result in problems, IMHO. So I believe they should be kept separate. And, in fact, this brings up another issue. The current requirements are completely lacking *any* mention of security. But I will address that in another note so as not to confuse the threads. > [DOT] Further, the requirement to provide means to express MN's requirements > to be used for the determination of the set of CARs (as I stated in my requirement) > does not imply that we have to invent a new protocol for this part of CAR discovery. > If I want to solve the CAR discovery problem (which according to the issues draft > include the determination of CARs), I have to have means to express MN's > requirements. These 'means' might certainly be existing protocols. > Agreed. > [DOT] More philosophically, the requirements are meant to define a protocol > that solves the CAR discovery problem. The design of such protocol should always > be done under the constraint to re-use as much existing functionality as possible. > However, the first and strongest requirement is to solve the problem. To do, I do > think that this requirement is needed. > Agreed. > There is no need to for the AR to know the MN's requirements just to select GAARs. > > [DOT] On what basis do you want to select GAARs? If you plainly determine > a subset of GAARs that are reachable by the MN at time of handoff (is it > that what you mean?), then you are not determining CARs according to the > definition of CARs. You are plainly selecting reachable GAARs. > > I have no objection to including this requirement as long as: - The language makes clear that the requirement is not to force the same protocol to perform CAR discovery and to communicate MN preferences. - The distinction between routing security/AAA requirements for CAR discovery and MN security/AAA requirements for MN preferences is maintained. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 13:42:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14684 for ; Wed, 13 Mar 2002 13:42:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA04045 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 13:42:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03049; Wed, 13 Mar 2002 13:23:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03018 for ; Wed, 13 Mar 2002 13:23:12 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14007 for ; Wed, 13 Mar 2002 13:23:09 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DIMcI00505; Wed, 13 Mar 2002 10:22:38 -0800 (PST) Message-ID: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR Discovery Requirements Date: Wed, 13 Mar 2002 10:21:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > IMHO, TAR selection includes everything including communication > of MN requirements. The reason I believe this is because communication > of the requirements may require functions such as: > > - verifying that the MN is, in fact, authorized to get what it is > asking. > > - arranging for accounting information so that the owner of the MN > can be billed appropriately for what it is asking. > > - authenticating the exchange with the MN so that the AR (or > whatever > other network entity is involved in doing TAR selection) knows that > they come from an authorized MN and not from a freeloader. > > - securing the exchange between the MN and the AR or other > entity implementing the MN's selection. > > These functions are separate from communicating routing reachability > and router capability information, even if the MN is involved in > propagating the reachability and capability information (as, I believe, > it may be in CAR discovery). The AAA functions are > completely orthogonal, as are the security functions. > > [DOT] By all due respect, I'm kind of surprised to see these interpretations > at this stage of discussion. What I quoted in my previous email is the > definition of CARs and the fundamental sentence in the problem statement. > In addition, here the definition of TAR selection: > "TAR Selection Algorithm > > The algorithm that determines a unique TAR for MN's handoff from > the set of CARs. The exact nature and definition of this algorithm > is outside the scope of this document. > " > With all this information, available in the issues draft for quite a while, > I draw the following line > - discover GAARs and their capabilities > - determine set of CARs (i.e., subset of GAARs that fulfil MN's requirements) > - select a unique TAR from this set (i.e., TAR selection) > I don't see that much room for interpretation of the terms, at least this > interpretation should have been done at appropriate time of the discussion. > Perhaps I did not state clearly enough what I was trying to say. The point that I was trying to make is similar to the one the Scott Bradner brought up at the last Seamoby meeting in SLC. The security/AAA requirements on a protocol for distributing routing reachability information are likely to be very different from those involving a MN expressing its preferences for capabilities. For example, I believe there is a separate IPsec policy for routing security as opposed to host security. If the CAR discovery information is coming from a host and the routing infrastructure is using this policy, then I would presume that the host must, in some way ensure that the security requirements of the routing infrastructure, and not for hosts, is followed. Similarly, for communicating MN capabilities preferences, a host security/AAA policy needs to be used and not a routing security policy. Conflating these two is likely to result in problems, IMHO. So I believe they should be kept separate. And, in fact, this brings up another issue. The current requirements are completely lacking *any* mention of security. But I will address that in another note so as not to confuse the threads. > [DOT] Further, the requirement to provide means to express MN's requirements > to be used for the determination of the set of CARs (as I stated in my requirement) > does not imply that we have to invent a new protocol for this part of CAR discovery. > If I want to solve the CAR discovery problem (which according to the issues draft > include the determination of CARs), I have to have means to express MN's > requirements. These 'means' might certainly be existing protocols. > Agreed. > [DOT] More philosophically, the requirements are meant to define a protocol > that solves the CAR discovery problem. The design of such protocol should always > be done under the constraint to re-use as much existing functionality as possible. > However, the first and strongest requirement is to solve the problem. To do, I do > think that this requirement is needed. > Agreed. > There is no need to for the AR to know the MN's requirements just to select GAARs. > > [DOT] On what basis do you want to select GAARs? If you plainly determine > a subset of GAARs that are reachable by the MN at time of handoff (is it > that what you mean?), then you are not determining CARs according to the > definition of CARs. You are plainly selecting reachable GAARs. > > I have no objection to including this requirement as long as: - The language makes clear that the requirement is not to force the same protocol to perform CAR discovery and to communicate MN preferences. - The distinction between routing security/AAA requirements for CAR discovery and MN security/AAA requirements for MN preferences is maintained. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 14:32:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16188 for ; Wed, 13 Mar 2002 14:32:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06657; Wed, 13 Mar 2002 14:14:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06627 for ; Wed, 13 Mar 2002 14:14:14 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15531 for ; Wed, 13 Mar 2002 14:14:10 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DJDW309659 for ; Wed, 13 Mar 2002 21:13:32 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 21:14:11 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 21:14:10 +0200 Received: from Beethoven (nokdaa00583.americas.nokia.com [172.18.5.83]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA00622; Wed, 13 Mar 2002 14:10:29 -0500 (EST) Message-ID: <008701c1cac3$3c336840$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext James Kempf" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] CAR Discovery Requirements Date: Wed, 13 Mar 2002 14:13:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Mar 2002 19:14:10.0992 (UTC) FILETIME=[41878B00:01C1CAC3] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, > And, in fact, this brings up another issue. The current requirements are > completely lacking *any* mention of security. But I will address that in > another note so as not to confuse the threads. They at least mention the secure transfer of capability information. However, I'm looking forward to seeing requirements or additions to requirements, folding in security aspects. > I have no objection to including this requirement as long as: > > - The language makes clear that the requirement is not to force the > same protocol to perform CAR discovery and to communicate MN > preferences. Agree, sorry for any inappropriate wording that didn't make this clear enough. From my perpective, CAR discovery has been seen as a problem that needs certain aspects to be addressed. Expressing MN's requirements is one of them to determine the CARs. A solution for the CAR discovery problem is comprised of different parts that fulfil as a whole the requirements we're currently talking about. Parts of the solution could be defined as a new protocol, for other parts we could and should use existing infrastructure. This was implicitly in my mind for ALL requirements, e.g., for the transfer of capability information. That's why I didn't put it specifically in the one we're currently discussing. To expedite the process, what would an appropriate wording to make this clear? Or would it be more useful to have a general statement in the introduction of the requirements, that this is the case for ALL requirements, following the line of argumentation I tried to outline in the previous paragraph? > > - The distinction between routing security/AAA requirements for CAR > discovery and MN security/AAA requirements for MN preferences is > maintained. I see this more as security aspects in general. Could you provide requirement(s) for this aspect (actually your above sentence is pretty much one, isn't it)? Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 14:32:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16201 for ; Wed, 13 Mar 2002 14:32:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA07982 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 14:32:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06657; Wed, 13 Mar 2002 14:14:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06627 for ; Wed, 13 Mar 2002 14:14:14 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15531 for ; Wed, 13 Mar 2002 14:14:10 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DJDW309659 for ; Wed, 13 Mar 2002 21:13:32 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 21:14:11 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 21:14:10 +0200 Received: from Beethoven (nokdaa00583.americas.nokia.com [172.18.5.83]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA00622; Wed, 13 Mar 2002 14:10:29 -0500 (EST) Message-ID: <008701c1cac3$3c336840$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext James Kempf" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] CAR Discovery Requirements Date: Wed, 13 Mar 2002 14:13:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Mar 2002 19:14:10.0992 (UTC) FILETIME=[41878B00:01C1CAC3] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, > And, in fact, this brings up another issue. The current requirements are > completely lacking *any* mention of security. But I will address that in > another note so as not to confuse the threads. They at least mention the secure transfer of capability information. However, I'm looking forward to seeing requirements or additions to requirements, folding in security aspects. > I have no objection to including this requirement as long as: > > - The language makes clear that the requirement is not to force the > same protocol to perform CAR discovery and to communicate MN > preferences. Agree, sorry for any inappropriate wording that didn't make this clear enough. From my perpective, CAR discovery has been seen as a problem that needs certain aspects to be addressed. Expressing MN's requirements is one of them to determine the CARs. A solution for the CAR discovery problem is comprised of different parts that fulfil as a whole the requirements we're currently talking about. Parts of the solution could be defined as a new protocol, for other parts we could and should use existing infrastructure. This was implicitly in my mind for ALL requirements, e.g., for the transfer of capability information. That's why I didn't put it specifically in the one we're currently discussing. To expedite the process, what would an appropriate wording to make this clear? Or would it be more useful to have a general statement in the introduction of the requirements, that this is the case for ALL requirements, following the line of argumentation I tried to outline in the previous paragraph? > > - The distinction between routing security/AAA requirements for CAR > discovery and MN security/AAA requirements for MN preferences is > maintained. I see this more as security aspects in general. Could you provide requirement(s) for this aspect (actually your above sentence is pretty much one, isn't it)? Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 14:54:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16757 for ; Wed, 13 Mar 2002 14:54:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08230; Wed, 13 Mar 2002 14:35:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08201 for ; Wed, 13 Mar 2002 14:35:51 -0500 (EST) Received: from hotmail.com (f246.law9.hotmail.com [64.4.9.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16266 for ; Wed, 13 Mar 2002 14:35:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 11:35:19 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 19:35:18 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Date: Wed, 13 Mar 2002 14:35:18 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 19:35:19.0208 (UTC) FILETIME=[3571F280:01C1CAC6] Subject: [Seamoby] Security Requirements in CAR Discovery? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >And, in fact, this brings up another issue. The current requirements are >completely lacking *any* mention of security. But I will address that in >another note so as not to confuse the threads. ---> This is an important issue. So I started a new thread. This discussion did come up Madjid Nakhriji (from Motorola) about security during inter-domain CAR discovery. I did explain to him about what kind of security we had in mind when writing the current set of requirements. The current set of requirements goes to the extent of saying that the capabilities MUST be exchanged in a secure fashion. I agree that SAs MUST be established between entities involved in CAR discovery. Do you have any wording in mind? Do you feel CAR discovery imposes special security requirements other than the SAs described in the previous sentence. Ofcourse, particular solutions may require security handling, but do we address that in a requirements draft meant for the problem, rather than a particular solution? I would think that these particular solutions should make sure that they do not have security holes. Also, we don't know how these solutions which are all in the 00 version will evolve in the future. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 14:54:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16768 for ; Wed, 13 Mar 2002 14:54:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09660 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 14:54:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08230; Wed, 13 Mar 2002 14:35:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08201 for ; Wed, 13 Mar 2002 14:35:51 -0500 (EST) Received: from hotmail.com (f246.law9.hotmail.com [64.4.9.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16266 for ; Wed, 13 Mar 2002 14:35:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 11:35:19 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 19:35:18 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Date: Wed, 13 Mar 2002 14:35:18 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 19:35:19.0208 (UTC) FILETIME=[3571F280:01C1CAC6] Subject: [Seamoby] Security Requirements in CAR Discovery? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >And, in fact, this brings up another issue. The current requirements are >completely lacking *any* mention of security. But I will address that in >another note so as not to confuse the threads. ---> This is an important issue. So I started a new thread. This discussion did come up Madjid Nakhriji (from Motorola) about security during inter-domain CAR discovery. I did explain to him about what kind of security we had in mind when writing the current set of requirements. The current set of requirements goes to the extent of saying that the capabilities MUST be exchanged in a secure fashion. I agree that SAs MUST be established between entities involved in CAR discovery. Do you have any wording in mind? Do you feel CAR discovery imposes special security requirements other than the SAs described in the previous sentence. Ofcourse, particular solutions may require security handling, but do we address that in a requirements draft meant for the problem, rather than a particular solution? I would think that these particular solutions should make sure that they do not have security holes. Also, we don't know how these solutions which are all in the 00 version will evolve in the future. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 14:54:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16791 for ; Wed, 13 Mar 2002 14:54:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08695; Wed, 13 Mar 2002 14:44:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08666 for ; Wed, 13 Mar 2002 14:44:19 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16439 for ; Wed, 13 Mar 2002 14:44:15 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DJhlI03542 for ; Wed, 13 Mar 2002 11:43:47 -0800 (PST) Message-ID: <023d01c1cac7$2aaa21a0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 13 Mar 2002 11:42:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Requirement for Using Existing Protocols Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit This requirement is meant to encourage re-use of existing protocols wherever possible. The Seamoby CAR Discovery solution MUST re-use existing protocols wherever possible. As part of drafting the solution, existing protocol MUST be examined for their match with the requirements, and modifications SHOULD be proposed in preference to inventing new protocols. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 14:54:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16801 for ; Wed, 13 Mar 2002 14:54:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09738 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 14:54:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08695; Wed, 13 Mar 2002 14:44:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08666 for ; Wed, 13 Mar 2002 14:44:19 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16439 for ; Wed, 13 Mar 2002 14:44:15 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DJhlI03542 for ; Wed, 13 Mar 2002 11:43:47 -0800 (PST) Message-ID: <023d01c1cac7$2aaa21a0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 13 Mar 2002 11:42:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Requirement for Using Existing Protocols Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit This requirement is meant to encourage re-use of existing protocols wherever possible. The Seamoby CAR Discovery solution MUST re-use existing protocols wherever possible. As part of drafting the solution, existing protocol MUST be examined for their match with the requirements, and modifications SHOULD be proposed in preference to inventing new protocols. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 15:05:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17137 for ; Wed, 13 Mar 2002 15:05:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09488; Wed, 13 Mar 2002 14:51:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09454 for ; Wed, 13 Mar 2002 14:51:16 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16701 for ; Wed, 13 Mar 2002 14:51:12 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DJogI03762; Wed, 13 Mar 2002 11:50:42 -0800 (PST) Message-ID: <024d01c1cac8$226440b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Trossen Dirk \(NRC/Boston\)" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> <008701c1cac3$3c336840$6401a8c0@Beethoven> Subject: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) Date: Wed, 13 Mar 2002 11:49:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit This requirement is meant for a solution to expressing MN preferences without conflating that and routing and capability information distribution, requested by Dirk. The Seamoby CAR discovery solution MUST provide a means for the MN to transmit its preferences for CARs based on CAR capabilities to the AR. The MN preference solution SHOULD be logically separate from the CAR information distribution solution in order to maintain separation of security requirements, i.e. it need not be part of the same protocol as that involved in CAR information distribution. Existing protocols, such as AAA, MUST be examined as part the design process. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 15:05:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17147 for ; Wed, 13 Mar 2002 15:05:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10732 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 15:05:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09488; Wed, 13 Mar 2002 14:51:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09454 for ; Wed, 13 Mar 2002 14:51:16 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16701 for ; Wed, 13 Mar 2002 14:51:12 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DJogI03762; Wed, 13 Mar 2002 11:50:42 -0800 (PST) Message-ID: <024d01c1cac8$226440b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Trossen Dirk \(NRC/Boston\)" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> <008701c1cac3$3c336840$6401a8c0@Beethoven> Subject: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) Date: Wed, 13 Mar 2002 11:49:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit This requirement is meant for a solution to expressing MN preferences without conflating that and routing and capability information distribution, requested by Dirk. The Seamoby CAR discovery solution MUST provide a means for the MN to transmit its preferences for CARs based on CAR capabilities to the AR. The MN preference solution SHOULD be logically separate from the CAR information distribution solution in order to maintain separation of security requirements, i.e. it need not be part of the same protocol as that involved in CAR information distribution. Existing protocols, such as AAA, MUST be examined as part the design process. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 15:08:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17252 for ; Wed, 13 Mar 2002 15:08:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09706; Wed, 13 Mar 2002 14:54:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09673 for ; Wed, 13 Mar 2002 14:54:25 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16784 for ; Wed, 13 Mar 2002 14:54:24 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DJrtI03872 for ; Wed, 13 Mar 2002 11:53:55 -0800 (PST) Message-ID: <025501c1cac8$95738390$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 13 Mar 2002 11:52:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Security Requirments for CAR Discovery Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The current requirements draft is a little thin on security. Here's a proposal: The Seamoby CAR discovery solution MUST provide proper security. Security on CAR information and capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of routing information distribution. Security on communication of MN preferences to ARs MUST conform and interoperate with existing IETF security and AAA policies and protocols for host security, where applicable. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 15:08:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17262 for ; Wed, 13 Mar 2002 15:08:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10905 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 15:08:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09706; Wed, 13 Mar 2002 14:54:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09673 for ; Wed, 13 Mar 2002 14:54:25 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16784 for ; Wed, 13 Mar 2002 14:54:24 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DJrtI03872 for ; Wed, 13 Mar 2002 11:53:55 -0800 (PST) Message-ID: <025501c1cac8$95738390$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 13 Mar 2002 11:52:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Security Requirments for CAR Discovery Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit The current requirements draft is a little thin on security. Here's a proposal: The Seamoby CAR discovery solution MUST provide proper security. Security on CAR information and capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of routing information distribution. Security on communication of MN preferences to ARs MUST conform and interoperate with existing IETF security and AAA policies and protocols for host security, where applicable. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 15:10:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17326 for ; Wed, 13 Mar 2002 15:10:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09864; Wed, 13 Mar 2002 14:56:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09839 for ; Wed, 13 Mar 2002 14:56:46 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16874 for ; Wed, 13 Mar 2002 14:56:44 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DJuwZ17866 for ; Wed, 13 Mar 2002 21:56:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 21:56:45 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 21:56:45 +0200 Received: from Beethoven (nokdaa005114.americas.nokia.com [172.18.5.114]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA00663; Wed, 13 Mar 2002 14:53:05 -0500 (EST) Message-ID: <00bd01c1cac9$2f2c3c70$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext James Kempf" , References: <023d01c1cac7$2aaa21a0$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 14:56:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Mar 2002 19:56:45.0766 (UTC) FILETIME=[344B1E60:01C1CAC9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, One comment to this 'requirement': The first sentence can be seen as a protocol requirement. The second one though is not a solution requirement but a procedure mandate since it mandates a certain process for drafting the solution. Do you really think this should be part of solution requirements? Part of the solution selection would be the assessment of proposed solutions. Your second sentence gives one of the crucial criteria for this assessment. However, it does not constitute a solution requirement rather than a description of the assessment procedure. Maybe, we could put the second sentence as a statement/reminder in the introduction of the requirement to make this clear?! Regards, Dirk ----- Original Message ----- From: "ext James Kempf" To: Sent: Wednesday, March 13, 2002 2:42 PM Subject: [Seamoby] Requirement for Using Existing Protocols > This requirement is meant to encourage re-use of existing protocols > wherever possible. > > The Seamoby CAR Discovery solution MUST re-use existing protocols > wherever possible. As part of drafting the solution, existing > protocol > MUST be examined for their match with the requirements, and > modifications SHOULD be proposed in preference to inventing > new protocols. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 15:10:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17338 for ; Wed, 13 Mar 2002 15:10:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11042 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 15:10:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09864; Wed, 13 Mar 2002 14:56:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09839 for ; Wed, 13 Mar 2002 14:56:46 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16874 for ; Wed, 13 Mar 2002 14:56:44 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DJuwZ17866 for ; Wed, 13 Mar 2002 21:56:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 21:56:45 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 21:56:45 +0200 Received: from Beethoven (nokdaa005114.americas.nokia.com [172.18.5.114]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA00663; Wed, 13 Mar 2002 14:53:05 -0500 (EST) Message-ID: <00bd01c1cac9$2f2c3c70$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext James Kempf" , References: <023d01c1cac7$2aaa21a0$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 14:56:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Mar 2002 19:56:45.0766 (UTC) FILETIME=[344B1E60:01C1CAC9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, One comment to this 'requirement': The first sentence can be seen as a protocol requirement. The second one though is not a solution requirement but a procedure mandate since it mandates a certain process for drafting the solution. Do you really think this should be part of solution requirements? Part of the solution selection would be the assessment of proposed solutions. Your second sentence gives one of the crucial criteria for this assessment. However, it does not constitute a solution requirement rather than a description of the assessment procedure. Maybe, we could put the second sentence as a statement/reminder in the introduction of the requirement to make this clear?! Regards, Dirk ----- Original Message ----- From: "ext James Kempf" To: Sent: Wednesday, March 13, 2002 2:42 PM Subject: [Seamoby] Requirement for Using Existing Protocols > This requirement is meant to encourage re-use of existing protocols > wherever possible. > > The Seamoby CAR Discovery solution MUST re-use existing protocols > wherever possible. As part of drafting the solution, existing > protocol > MUST be examined for their match with the requirements, and > modifications SHOULD be proposed in preference to inventing > new protocols. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 15:21:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17745 for ; Wed, 13 Mar 2002 15:21:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10774; Wed, 13 Mar 2002 15:05:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10744 for ; Wed, 13 Mar 2002 15:05:13 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17164 for ; Wed, 13 Mar 2002 15:05:11 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DK4dI04305; Wed, 13 Mar 2002 12:04:39 -0800 (PST) Message-ID: <001901c1caca$14fc7b20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Security Requirements in CAR Discovery? Date: Wed, 13 Mar 2002 12:03:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, See the proposed requirement in a separate thread. The basic issue is that the security on routing reachability information, including capabilities, must match whatever security the routing fabric is currently using. Whether it is inter-domain or intra-domain is not important, except in so far as the security might be tigher for inter-domain. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 13, 2002 11:35 AM Subject: [Seamoby] Security Requirements in CAR Discovery? > James, > > > >And, in fact, this brings up another issue. The current requirements are > >completely lacking *any* mention of security. But I will address that in > >another note so as not to confuse the threads. > > > ---> This is an important issue. So I started a new thread. > This discussion did come up Madjid Nakhriji (from Motorola) > about security during inter-domain CAR discovery. I did explain to him about > what kind of security we had in mind when writing the current set of > requirements. The current set of requirements goes to the extent of saying > that the capabilities MUST be exchanged in a secure fashion. I agree that > SAs MUST be established between entities involved > in CAR discovery. Do you have any wording in mind? Do you feel CAR discovery > imposes special security requirements other than the SAs described in the > previous sentence. Ofcourse, particular solutions may > require security handling, but do we address that in a requirements draft > meant for the problem, rather than a particular solution? > I would think that these particular solutions should make sure that they do > not have security holes. Also, we don't know how these solutions which are > all in the 00 version will evolve in the future. > > > Regards, > Govind. > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 15:21:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17759 for ; Wed, 13 Mar 2002 15:21:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11570 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 15:21:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10774; Wed, 13 Mar 2002 15:05:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10744 for ; Wed, 13 Mar 2002 15:05:13 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17164 for ; Wed, 13 Mar 2002 15:05:11 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DK4dI04305; Wed, 13 Mar 2002 12:04:39 -0800 (PST) Message-ID: <001901c1caca$14fc7b20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Security Requirements in CAR Discovery? Date: Wed, 13 Mar 2002 12:03:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, See the proposed requirement in a separate thread. The basic issue is that the security on routing reachability information, including capabilities, must match whatever security the routing fabric is currently using. Whether it is inter-domain or intra-domain is not important, except in so far as the security might be tigher for inter-domain. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 13, 2002 11:35 AM Subject: [Seamoby] Security Requirements in CAR Discovery? > James, > > > >And, in fact, this brings up another issue. The current requirements are > >completely lacking *any* mention of security. But I will address that in > >another note so as not to confuse the threads. > > > ---> This is an important issue. So I started a new thread. > This discussion did come up Madjid Nakhriji (from Motorola) > about security during inter-domain CAR discovery. I did explain to him about > what kind of security we had in mind when writing the current set of > requirements. The current set of requirements goes to the extent of saying > that the capabilities MUST be exchanged in a secure fashion. I agree that > SAs MUST be established between entities involved > in CAR discovery. Do you have any wording in mind? Do you feel CAR discovery > imposes special security requirements other than the SAs described in the > previous sentence. Ofcourse, particular solutions may > require security handling, but do we address that in a requirements draft > meant for the problem, rather than a particular solution? > I would think that these particular solutions should make sure that they do > not have security holes. Also, we don't know how these solutions which are > all in the 00 version will evolve in the future. > > > Regards, > Govind. > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 15:28:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18171 for ; Wed, 13 Mar 2002 15:28:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11281; Wed, 13 Mar 2002 15:12:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11254 for ; Wed, 13 Mar 2002 15:12:43 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17457 for ; Wed, 13 Mar 2002 15:12:40 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DKCsZ24150 for ; Wed, 13 Mar 2002 22:12:54 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 22:12:42 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 22:12:41 +0200 Received: from Beethoven (nokdaa005114.americas.nokia.com [172.18.5.114]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id PAA00679; Wed, 13 Mar 2002 15:09:00 -0500 (EST) Message-ID: <00c501c1cacb$6886ef90$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext James Kempf" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> <008701c1cac3$3c336840$6401a8c0@Beethoven> <024d01c1cac8$226440b0$7e6015ac@T23KEMPF> Subject: Re: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) Date: Wed, 13 Mar 2002 15:12:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Mar 2002 20:12:41.0827 (UTC) FILETIME=[6E267330:01C1CACB] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, two comments: 1) I'd like to have the term CAR changed in GAAR or GAAR/CAR since a solution might exchange data of GAARs only while the CARs are determined locally without distributing any information. In general though, I appreciate to state the separation. 2) For the last sentence, the same comment is valid as for the re-use requirement earlier. What you state here is a procedure requirement rather than a solution requirement. We should keep process and solution requirements separate. Either we put ONE procedure requirement in the document, outlining exactly this implicit requirement explicitly, i.e., to re-use existing protocols wherever possible. That's what you proposed earlier (though removing the second sentence in this requirement). Or we put a description of the solution assessment procedure in the introduction as prosa text, stating that solutions will be assessed against the re-use of functionality and that the design process has to include an assessment/gap analysis of existing protocols. Personally, I'd prefer the second option. Regards, Dirk ----- Original Message ----- From: "ext James Kempf" To: "Trossen Dirk (NRC/Boston)" ; Sent: Wednesday, March 13, 2002 2:49 PM Subject: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) > This requirement is meant for a solution to expressing MN preferences > without conflating that and routing and capability information > distribution, requested by Dirk. > > The Seamoby CAR discovery solution MUST provide a means for > the MN to transmit its preferences for CARs based on CAR > capabilities to the AR. The MN preference solution SHOULD > be logically separate from the CAR information distribution > solution in order to maintain separation of security requirements, > i.e. it need not be part of the same protocol as that involved > in CAR information distribution. Existing protocols, such as AAA, > MUST be examined as part the design process. > > Comments? > > jak > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 15:28:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18181 for ; Wed, 13 Mar 2002 15:28:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11917 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 15:28:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11281; Wed, 13 Mar 2002 15:12:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11254 for ; Wed, 13 Mar 2002 15:12:43 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17457 for ; Wed, 13 Mar 2002 15:12:40 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DKCsZ24150 for ; Wed, 13 Mar 2002 22:12:54 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 22:12:42 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 22:12:41 +0200 Received: from Beethoven (nokdaa005114.americas.nokia.com [172.18.5.114]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id PAA00679; Wed, 13 Mar 2002 15:09:00 -0500 (EST) Message-ID: <00c501c1cacb$6886ef90$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext James Kempf" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> <008701c1cac3$3c336840$6401a8c0@Beethoven> <024d01c1cac8$226440b0$7e6015ac@T23KEMPF> Subject: Re: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) Date: Wed, 13 Mar 2002 15:12:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Mar 2002 20:12:41.0827 (UTC) FILETIME=[6E267330:01C1CACB] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, two comments: 1) I'd like to have the term CAR changed in GAAR or GAAR/CAR since a solution might exchange data of GAARs only while the CARs are determined locally without distributing any information. In general though, I appreciate to state the separation. 2) For the last sentence, the same comment is valid as for the re-use requirement earlier. What you state here is a procedure requirement rather than a solution requirement. We should keep process and solution requirements separate. Either we put ONE procedure requirement in the document, outlining exactly this implicit requirement explicitly, i.e., to re-use existing protocols wherever possible. That's what you proposed earlier (though removing the second sentence in this requirement). Or we put a description of the solution assessment procedure in the introduction as prosa text, stating that solutions will be assessed against the re-use of functionality and that the design process has to include an assessment/gap analysis of existing protocols. Personally, I'd prefer the second option. Regards, Dirk ----- Original Message ----- From: "ext James Kempf" To: "Trossen Dirk (NRC/Boston)" ; Sent: Wednesday, March 13, 2002 2:49 PM Subject: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) > This requirement is meant for a solution to expressing MN preferences > without conflating that and routing and capability information > distribution, requested by Dirk. > > The Seamoby CAR discovery solution MUST provide a means for > the MN to transmit its preferences for CARs based on CAR > capabilities to the AR. The MN preference solution SHOULD > be logically separate from the CAR information distribution > solution in order to maintain separation of security requirements, > i.e. it need not be part of the same protocol as that involved > in CAR information distribution. Existing protocols, such as AAA, > MUST be examined as part the design process. > > Comments? > > jak > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 15:45:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18819 for ; Wed, 13 Mar 2002 15:45:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12529; Wed, 13 Mar 2002 15:31:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12500 for ; Wed, 13 Mar 2002 15:31:43 -0500 (EST) Received: from hotmail.com (f65.law7.hotmail.com [216.33.237.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18349 for ; Wed, 13 Mar 2002 15:31:41 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 12:31:13 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 20:31:13 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 20:31:13 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 20:31:13.0350 (UTC) FILETIME=[04AB6660:01C1CACE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: In IETF, don't we always do the best of our effort to reuse existing protocols whenever applicable. I think this requirement (more precisely a practice) is true for ANY protocol that IETF works on. What is so special about this requirement in CAR discovery? Shouldn't we be quoting only those requirements that are specific to CAR discovery, usual practices being well understood. Also, what is exactly the meaning of inventing new protocol? How do you define a novelty of a protocol? I think as long as the protocol uses existing IP modules like say TCP, UDP, ICMP, DHCP, IPSec, Routing etc. it is not a new invention. How messages are sent using these tools, what information they carry and how they need to be processed solely depends upon the problem at hand. If this can be reused as well from other protocols that is even better. Hemant >From: "James Kempf" >To: >Subject: [Seamoby] Requirement for Using Existing Protocols >Date: Wed, 13 Mar 2002 11:42:10 -0800 > >This requirement is meant to encourage re-use of existing protocols >wherever possible. > > The Seamoby CAR Discovery solution MUST re-use existing protocols > wherever possible. As part of drafting the solution, existing >protocol > MUST be examined for their match with the requirements, and > modifications SHOULD be proposed in preference to inventing > new protocols. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 15:45:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18832 for ; Wed, 13 Mar 2002 15:45:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13115 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 15:45:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12529; Wed, 13 Mar 2002 15:31:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12500 for ; Wed, 13 Mar 2002 15:31:43 -0500 (EST) Received: from hotmail.com (f65.law7.hotmail.com [216.33.237.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18349 for ; Wed, 13 Mar 2002 15:31:41 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 12:31:13 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 20:31:13 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 20:31:13 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 20:31:13.0350 (UTC) FILETIME=[04AB6660:01C1CACE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: In IETF, don't we always do the best of our effort to reuse existing protocols whenever applicable. I think this requirement (more precisely a practice) is true for ANY protocol that IETF works on. What is so special about this requirement in CAR discovery? Shouldn't we be quoting only those requirements that are specific to CAR discovery, usual practices being well understood. Also, what is exactly the meaning of inventing new protocol? How do you define a novelty of a protocol? I think as long as the protocol uses existing IP modules like say TCP, UDP, ICMP, DHCP, IPSec, Routing etc. it is not a new invention. How messages are sent using these tools, what information they carry and how they need to be processed solely depends upon the problem at hand. If this can be reused as well from other protocols that is even better. Hemant >From: "James Kempf" >To: >Subject: [Seamoby] Requirement for Using Existing Protocols >Date: Wed, 13 Mar 2002 11:42:10 -0800 > >This requirement is meant to encourage re-use of existing protocols >wherever possible. > > The Seamoby CAR Discovery solution MUST re-use existing protocols > wherever possible. As part of drafting the solution, existing >protocol > MUST be examined for their match with the requirements, and > modifications SHOULD be proposed in preference to inventing > new protocols. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 15:55:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19080 for ; Wed, 13 Mar 2002 15:55:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12972; Wed, 13 Mar 2002 15:41:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12939 for ; Wed, 13 Mar 2002 15:41:35 -0500 (EST) Received: from hotmail.com (f243.law7.hotmail.com [216.33.237.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18737 for ; Wed, 13 Mar 2002 15:41:33 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 12:41:05 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 20:41:05 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 20:41:05 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 20:41:05.0374 (UTC) FILETIME=[658B17E0:01C1CACF] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some comments inline. >From: "James Kempf" >To: >Subject: [Seamoby] Security Requirments for CAR Discovery >Date: Wed, 13 Mar 2002 11:52:19 -0800 > >The current requirements draft is a little thin on security. Here's a >proposal: > > The Seamoby CAR discovery solution MUST provide proper security. > Security on CAR information and capabilities distribution MUST >conform > and interoperate with existing IETF security policies and protocols [HC] I agree with this part, though I think that the first sentence is superfluous. Also, do we have an official reference on such IETF security policies and protocols? If we do, we can quote it too. Furhter, will the currentness of that referece change over time? >on > the security of routing information distribution. I do not agree with this part. What is the relation between routing and CAR requirements? The first part of your requirement covers all the IETF security policies and protocols, and that should be enough in my opinion. Security on >communication > of MN preferences to ARs MUST conform and interoperate with existing > IETF security and AAA policies and protocols for host security, >where > applicable. I agree with this again. > >Comments? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 15:55:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19092 for ; Wed, 13 Mar 2002 15:55:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13458 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 15:55:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12972; Wed, 13 Mar 2002 15:41:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12939 for ; Wed, 13 Mar 2002 15:41:35 -0500 (EST) Received: from hotmail.com (f243.law7.hotmail.com [216.33.237.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18737 for ; Wed, 13 Mar 2002 15:41:33 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 12:41:05 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 20:41:05 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 20:41:05 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 20:41:05.0374 (UTC) FILETIME=[658B17E0:01C1CACF] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some comments inline. >From: "James Kempf" >To: >Subject: [Seamoby] Security Requirments for CAR Discovery >Date: Wed, 13 Mar 2002 11:52:19 -0800 > >The current requirements draft is a little thin on security. Here's a >proposal: > > The Seamoby CAR discovery solution MUST provide proper security. > Security on CAR information and capabilities distribution MUST >conform > and interoperate with existing IETF security policies and protocols [HC] I agree with this part, though I think that the first sentence is superfluous. Also, do we have an official reference on such IETF security policies and protocols? If we do, we can quote it too. Furhter, will the currentness of that referece change over time? >on > the security of routing information distribution. I do not agree with this part. What is the relation between routing and CAR requirements? The first part of your requirement covers all the IETF security policies and protocols, and that should be enough in my opinion. Security on >communication > of MN preferences to ARs MUST conform and interoperate with existing > IETF security and AAA policies and protocols for host security, >where > applicable. I agree with this again. > >Comments? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 16:18:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19686 for ; Wed, 13 Mar 2002 16:18:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14446; Wed, 13 Mar 2002 16:06:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14417 for ; Wed, 13 Mar 2002 16:06:29 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19408 for ; Wed, 13 Mar 2002 16:06:26 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DL5uI06058; Wed, 13 Mar 2002 13:05:56 -0800 (PST) Message-ID: <005701c1cad2$a4b51bc0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Trossen Dirk \(NRC/Boston\)" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> <008701c1cac3$3c336840$6401a8c0@Beethoven> <024d01c1cac8$226440b0$7e6015ac@T23KEMPF> <00c501c1cacb$6886ef90$6401a8c0@Beethoven> Subject: Re: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) Date: Wed, 13 Mar 2002 13:04:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > 1) I'd like to have the term CAR changed in GAAR or GAAR/CAR since > a solution might exchange data of GAARs only while the CARs are determined > locally without distributing any information. In general though, I > appreciate to state the > separation. > OK. > 2) For the last sentence, the same comment is valid as for the re-use > requirement earlier. > What you state here is a procedure requirement rather than a solution > requirement. > We should keep process and solution requirements separate. Either we put ONE > procedure requirement in the document, outlining exactly this implicit > requirement > explicitly, i.e., to re-use existing protocols wherever possible. That's > what you proposed > earlier (though removing the second sentence in this requirement). > Or we put a description of the solution assessment procedure in the > introduction > as prosa text, stating that solutions will be assessed against the re-use of > functionality and > that the design process has to include an assessment/gap analysis of > existing protocols. > Personally, I'd prefer the second option. > Let's put one procedure requirement in. Perhaps we can state this as a goal in the introductory section (but with MUST/SHOULD language) rather than as an explict requirement because, as you say, it does not constrain the solution but just the process. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 16:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19747 for ; Wed, 13 Mar 2002 16:19:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14002; Wed, 13 Mar 2002 16:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13957 for ; Wed, 13 Mar 2002 16:00:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19261 for ; Wed, 13 Mar 2002 16:00:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DL0NI05883; Wed, 13 Mar 2002 13:00:23 -0800 (PST) Message-ID: <004301c1cad1$dde9fec0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Trossen Dirk \(NRC/Boston\)" , References: <023d01c1cac7$2aaa21a0$7e6015ac@T23KEMPF> <00bd01c1cac9$2f2c3c70$6401a8c0@Beethoven> Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 12:57:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Maybe, we could put the second sentence as a statement/reminder in the > introduction of the requirement to make this clear?! > Sounds fine to me. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 16:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19758 for ; Wed, 13 Mar 2002 16:19:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14977 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 16:19:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14002; Wed, 13 Mar 2002 16:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13957 for ; Wed, 13 Mar 2002 16:00:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19261 for ; Wed, 13 Mar 2002 16:00:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DL0NI05883; Wed, 13 Mar 2002 13:00:23 -0800 (PST) Message-ID: <004301c1cad1$dde9fec0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Trossen Dirk \(NRC/Boston\)" , References: <023d01c1cac7$2aaa21a0$7e6015ac@T23KEMPF> <00bd01c1cac9$2f2c3c70$6401a8c0@Beethoven> Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 12:57:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Maybe, we could put the second sentence as a statement/reminder in the > introduction of the requirement to make this clear?! > Sounds fine to me. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 16:30:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20139 for ; Wed, 13 Mar 2002 16:30:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14824; Wed, 13 Mar 2002 16:16:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14793 for ; Wed, 13 Mar 2002 16:16:22 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19661 for ; Wed, 13 Mar 2002 16:16:20 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DLFpI06402; Wed, 13 Mar 2002 13:15:51 -0800 (PST) Message-ID: <006f01c1cad4$0730f110$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 13:14:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >The current requirements draft is a little thin on security. Here's a > >proposal: > > > > The Seamoby CAR discovery solution MUST provide proper security. > > Security on CAR information and capabilities distribution MUST > >conform > > and interoperate with existing IETF security policies and protocols > > [HC] I agree with this part, though I think that the first sentence is > superfluous. Also, do we have an official reference on such IETF security > policies and protocols? If we do, we can quote it too. Furhter, will the > currentness of that referece change over time? > We should have proper references, of course. And such references do change, we can only work with what we have right now. > >on > > the security of routing information distribution. > > I do not agree with this part. What is the relation between routing and CAR > requirements? The first part of your requirement covers all the IETF > security policies and protocols, and that should be enough in my opinion. > CAR discovery involves sending information about the reachability and capabilities of one router to another, possibly via a host. Routing information distribution involves sending information about the reachability and capabilities of one router to another, usually not via a host. The only thing the two don't have in common is that one could possibly use a host while the other doesn't. In either case, the routing fabric has to be able to trust the information it gets. Thus, the security on the information distribution needs to be the same. Note that this is *not* to say that, a priori, CAR discovery and routing information distribution should be solved by the same protocol, just that they involve the same kind of security problem. For an example of the problems it might cause if security on CAR discovery were any less than that on routing information distribution, consider security on MIP binding updates. The newly decided upon protocol, return routability, depends critically upon the security of the routing fabric. If the security on CAR discovery causes the security of the routing fabric to be compromised, then MIP RR security on BU updates is compromised. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 16:30:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20149 for ; Wed, 13 Mar 2002 16:30:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15971 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 16:30:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14824; Wed, 13 Mar 2002 16:16:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14793 for ; Wed, 13 Mar 2002 16:16:22 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19661 for ; Wed, 13 Mar 2002 16:16:20 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DLFpI06402; Wed, 13 Mar 2002 13:15:51 -0800 (PST) Message-ID: <006f01c1cad4$0730f110$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 13:14:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >The current requirements draft is a little thin on security. Here's a > >proposal: > > > > The Seamoby CAR discovery solution MUST provide proper security. > > Security on CAR information and capabilities distribution MUST > >conform > > and interoperate with existing IETF security policies and protocols > > [HC] I agree with this part, though I think that the first sentence is > superfluous. Also, do we have an official reference on such IETF security > policies and protocols? If we do, we can quote it too. Furhter, will the > currentness of that referece change over time? > We should have proper references, of course. And such references do change, we can only work with what we have right now. > >on > > the security of routing information distribution. > > I do not agree with this part. What is the relation between routing and CAR > requirements? The first part of your requirement covers all the IETF > security policies and protocols, and that should be enough in my opinion. > CAR discovery involves sending information about the reachability and capabilities of one router to another, possibly via a host. Routing information distribution involves sending information about the reachability and capabilities of one router to another, usually not via a host. The only thing the two don't have in common is that one could possibly use a host while the other doesn't. In either case, the routing fabric has to be able to trust the information it gets. Thus, the security on the information distribution needs to be the same. Note that this is *not* to say that, a priori, CAR discovery and routing information distribution should be solved by the same protocol, just that they involve the same kind of security problem. For an example of the problems it might cause if security on CAR discovery were any less than that on routing information distribution, consider security on MIP binding updates. The newly decided upon protocol, return routability, depends critically upon the security of the routing fabric. If the security on CAR discovery causes the security of the routing fabric to be compromised, then MIP RR security on BU updates is compromised. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 16:36:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20391 for ; Wed, 13 Mar 2002 16:36:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15320; Wed, 13 Mar 2002 16:22:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15237 for ; Wed, 13 Mar 2002 16:22:29 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19902 for ; Wed, 13 Mar 2002 16:22:27 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DLLwI06591; Wed, 13 Mar 2002 13:21:58 -0800 (PST) Message-ID: <007501c1cad4$e2369530$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 13:20:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > In IETF, don't we always do the best of our effort to reuse existing > protocols whenever applicable. I think this requirement (more precisely a > practice) is true for ANY protocol that IETF works on. What is so special > about this requirement in CAR discovery? Shouldn't we be quoting only those > requirements that are specific to CAR discovery, usual practices being well > understood. > I have seen other requirements statements in which this was included. As I indicated in my message to Dirk, I think we could move this to the introduction section as a process goal, rather than as a specific requirement on the solution. > Also, what is exactly the meaning of inventing new protocol? How do you > define a novelty of a protocol? I think as long as the protocol uses > existing IP modules like say TCP, UDP, ICMP, DHCP, IPSec, Routing etc. it is > not a new invention. How messages are sent using these tools, what > information they carry and how they need to be processed solely depends upon > the problem at hand. If this can be reused as well from other protocols that > is even better. > There is a difference between using a protocol and modifying a protocol so that it will support a particular set of requirements. What I'm suggesting is that part of the process should be examining where existing protocols might be modified, with the goal of being conservative and not introducing more complexity than necessary. Of course, even if a new protocol is required, we can and will use other protocols, such as TCP. That's not the issue. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 16:36:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20409 for ; Wed, 13 Mar 2002 16:36:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16706 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 16:36:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15320; Wed, 13 Mar 2002 16:22:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15237 for ; Wed, 13 Mar 2002 16:22:29 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19902 for ; Wed, 13 Mar 2002 16:22:27 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DLLwI06591; Wed, 13 Mar 2002 13:21:58 -0800 (PST) Message-ID: <007501c1cad4$e2369530$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Requirement for Using Existing Protocols Date: Wed, 13 Mar 2002 13:20:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > In IETF, don't we always do the best of our effort to reuse existing > protocols whenever applicable. I think this requirement (more precisely a > practice) is true for ANY protocol that IETF works on. What is so special > about this requirement in CAR discovery? Shouldn't we be quoting only those > requirements that are specific to CAR discovery, usual practices being well > understood. > I have seen other requirements statements in which this was included. As I indicated in my message to Dirk, I think we could move this to the introduction section as a process goal, rather than as a specific requirement on the solution. > Also, what is exactly the meaning of inventing new protocol? How do you > define a novelty of a protocol? I think as long as the protocol uses > existing IP modules like say TCP, UDP, ICMP, DHCP, IPSec, Routing etc. it is > not a new invention. How messages are sent using these tools, what > information they carry and how they need to be processed solely depends upon > the problem at hand. If this can be reused as well from other protocols that > is even better. > There is a difference between using a protocol and modifying a protocol so that it will support a particular set of requirements. What I'm suggesting is that part of the process should be examining where existing protocols might be modified, with the goal of being conservative and not introducing more complexity than necessary. Of course, even if a new protocol is required, we can and will use other protocols, such as TCP. That's not the issue. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 17:11:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19693 for ; Wed, 13 Mar 2002 16:18:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14880 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 16:18:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14446; Wed, 13 Mar 2002 16:06:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14417 for ; Wed, 13 Mar 2002 16:06:29 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19408 for ; Wed, 13 Mar 2002 16:06:26 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DL5uI06058; Wed, 13 Mar 2002 13:05:56 -0800 (PST) Message-ID: <005701c1cad2$a4b51bc0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Trossen Dirk \(NRC/Boston\)" , References: <017201c1cabb$d48fbf10$7e6015ac@T23KEMPF> <008701c1cac3$3c336840$6401a8c0@Beethoven> <024d01c1cac8$226440b0$7e6015ac@T23KEMPF> <00c501c1cacb$6886ef90$6401a8c0@Beethoven> Subject: Re: Requirement for MN Preference (was: Re: [Seamoby] CAR Discovery Requirements) Date: Wed, 13 Mar 2002 13:04:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > 1) I'd like to have the term CAR changed in GAAR or GAAR/CAR since > a solution might exchange data of GAARs only while the CARs are determined > locally without distributing any information. In general though, I > appreciate to state the > separation. > OK. > 2) For the last sentence, the same comment is valid as for the re-use > requirement earlier. > What you state here is a procedure requirement rather than a solution > requirement. > We should keep process and solution requirements separate. Either we put ONE > procedure requirement in the document, outlining exactly this implicit > requirement > explicitly, i.e., to re-use existing protocols wherever possible. That's > what you proposed > earlier (though removing the second sentence in this requirement). > Or we put a description of the solution assessment procedure in the > introduction > as prosa text, stating that solutions will be assessed against the re-use of > functionality and > that the design process has to include an assessment/gap analysis of > existing protocols. > Personally, I'd prefer the second option. > Let's put one procedure requirement in. Perhaps we can state this as a goal in the introductory section (but with MUST/SHOULD language) rather than as an explict requirement because, as you say, it does not constrain the solution but just the process. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 17:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21846 for ; Wed, 13 Mar 2002 17:16:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19868; Wed, 13 Mar 2002 17:10:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19843 for ; Wed, 13 Mar 2002 17:10:07 -0500 (EST) Received: from hotmail.com (f223.law7.hotmail.com [216.33.237.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21509 for ; Wed, 13 Mar 2002 17:10:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 14:09:36 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 22:09:36 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 22:09:36 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 22:09:36.0492 (UTC) FILETIME=[C33762C0:01C1CADB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Please see coments below marked as [HC] --------------------------snip--------------------------------------- > > >on > > > the security of routing information distribution. > > > > I do not agree with this part. What is the relation between routing >and CAR > > requirements? The first part of your requirement covers all the IETF > > security policies and protocols, and that should be enough in my >opinion. > > > >CAR discovery involves sending information about the reachability and >capabilities of one router to another, possibly via a host. [HC] CAR discovery is not about spreading reachability information of one router to another. That is the job of routing protocols. It is about capability exchange between GAARs. Routing >information distribution involves sending information about the >reachability and capabilities of one router to another, usually not via >a host. The only thing the two don't have in common is that one could >possibly use a host while the other doesn't. [HC] I think there is little commanality between routing protocols and CAR discovery. Let me explain. There are two main parts of CAR discovery: GAAR discovery and capability exchange. I will come to GAAR discovery later. As far as the capability exchange between the GAARs is considered, once the two GAARs have decided to exchange capabilities they can do so by opening simply a peer-to-peer connection such as TCP between them or use open loop messaging like UDP and ICMP. I see no involvment of routing protocols here (beyond the point that they will help route the packets containing these messages). To give an analogy, if two routers need to do FTP between them they simply do it using TCP. FTP is however not deemed to be related to routing. If capabilities are exchanged via MN instead, the same logic still applies. Only, there is extra node between them. Now coming to GAAR discovery part, I struggle to see how a routing protocol are related to GAAR discovery. The problem statement clearly points hout how GAAR discovery (Geospace) is different from logical neighborhood discovery (Cyberspace) on which routing protocols are built. In either case, the routing >fabric has to be able to trust the information it gets. [HC] Why CAR discovery needs to inject any information in routing fabric? As I have explained above, it is about peer to peer information exchange between GAARs. Thus, the >security on the information distribution needs to be the same. Note that >this is *not* to say that, a priori, CAR discovery and routing >information distribution should be solved by the same protocol, just >that they involve the same kind of security problem. > >For an example of the problems it might cause if security on CAR >discovery were any less than that on routing information distribution, >consider security on MIP binding updates. The newly decided upon >protocol, return routability, depends critically upon the security of >the routing fabric. If the security on CAR discovery causes the security >of the routing fabric to be compromised, then MIP RR security on BU >updates is compromised. > > jak > [HC] I am not denying that the security problem may exist. But then, we need to point it out more directly and precisely rather than saying that the security problem is something like the one involved in routing. I think the problem is that "why will the two GAARs involve in capability exchange in the first place, unless they are assured about the validity of each other". Now we do have to come up with a solution to that. But, it is difficult to see how this problem alone can draw relation between CAR discovery and routing protocols. Regards, Hemant _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 17:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21857 for ; Wed, 13 Mar 2002 17:16:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20272 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 17:16:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19868; Wed, 13 Mar 2002 17:10:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19843 for ; Wed, 13 Mar 2002 17:10:07 -0500 (EST) Received: from hotmail.com (f223.law7.hotmail.com [216.33.237.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21509 for ; Wed, 13 Mar 2002 17:10:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 14:09:36 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 22:09:36 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 22:09:36 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 22:09:36.0492 (UTC) FILETIME=[C33762C0:01C1CADB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Please see coments below marked as [HC] --------------------------snip--------------------------------------- > > >on > > > the security of routing information distribution. > > > > I do not agree with this part. What is the relation between routing >and CAR > > requirements? The first part of your requirement covers all the IETF > > security policies and protocols, and that should be enough in my >opinion. > > > >CAR discovery involves sending information about the reachability and >capabilities of one router to another, possibly via a host. [HC] CAR discovery is not about spreading reachability information of one router to another. That is the job of routing protocols. It is about capability exchange between GAARs. Routing >information distribution involves sending information about the >reachability and capabilities of one router to another, usually not via >a host. The only thing the two don't have in common is that one could >possibly use a host while the other doesn't. [HC] I think there is little commanality between routing protocols and CAR discovery. Let me explain. There are two main parts of CAR discovery: GAAR discovery and capability exchange. I will come to GAAR discovery later. As far as the capability exchange between the GAARs is considered, once the two GAARs have decided to exchange capabilities they can do so by opening simply a peer-to-peer connection such as TCP between them or use open loop messaging like UDP and ICMP. I see no involvment of routing protocols here (beyond the point that they will help route the packets containing these messages). To give an analogy, if two routers need to do FTP between them they simply do it using TCP. FTP is however not deemed to be related to routing. If capabilities are exchanged via MN instead, the same logic still applies. Only, there is extra node between them. Now coming to GAAR discovery part, I struggle to see how a routing protocol are related to GAAR discovery. The problem statement clearly points hout how GAAR discovery (Geospace) is different from logical neighborhood discovery (Cyberspace) on which routing protocols are built. In either case, the routing >fabric has to be able to trust the information it gets. [HC] Why CAR discovery needs to inject any information in routing fabric? As I have explained above, it is about peer to peer information exchange between GAARs. Thus, the >security on the information distribution needs to be the same. Note that >this is *not* to say that, a priori, CAR discovery and routing >information distribution should be solved by the same protocol, just >that they involve the same kind of security problem. > >For an example of the problems it might cause if security on CAR >discovery were any less than that on routing information distribution, >consider security on MIP binding updates. The newly decided upon >protocol, return routability, depends critically upon the security of >the routing fabric. If the security on CAR discovery causes the security >of the routing fabric to be compromised, then MIP RR security on BU >updates is compromised. > > jak > [HC] I am not denying that the security problem may exist. But then, we need to point it out more directly and precisely rather than saying that the security problem is something like the one involved in routing. I think the problem is that "why will the two GAARs involve in capability exchange in the first place, unless they are assured about the validity of each other". Now we do have to come up with a solution to that. But, it is difficult to see how this problem alone can draw relation between CAR discovery and routing protocols. Regards, Hemant _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 17:54:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23246 for ; Wed, 13 Mar 2002 17:54:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23809; Wed, 13 Mar 2002 17:50:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23783 for ; Wed, 13 Mar 2002 17:50:13 -0500 (EST) Received: from hotmail.com (f205.law9.hotmail.com [64.4.9.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23070 for ; Wed, 13 Mar 2002 17:50:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 14:49:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 22:49:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 17:49:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 22:49:42.0944 (UTC) FILETIME=[5D92D200:01C1CAE1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James, Just to add to Hemant's comments, reachability of GAARs according to CAR discovery is in the view of the current MN in question. Two GAARs may be reachable for an MN but not for a different MN. In the IP sense, two GAARs are always reachable somehow through the Internet (of course I am not considering private addresses here. But even in that case it may be reachable indirectly through a border router). In summary, I share Hemant's concern about why you are going linking routing and CAR discovery. I don't know whether I am missing something. Regards, Govind. > >Hi James: > >Please see coments below marked as [HC] > >--------------------------snip--------------------------------------- >> > >on >> > > the security of routing information distribution. >> > >> > I do not agree with this part. What is the relation between routing >>and CAR >> > requirements? The first part of your requirement covers all the IETF >> > security policies and protocols, and that should be enough in my >>opinion. >> > >> >>CAR discovery involves sending information about the reachability and >>capabilities of one router to another, possibly via a host. > >[HC] CAR discovery is not about spreading reachability information of one >router to another. That is the job of routing protocols. It is about >capability exchange between GAARs. > >Routing >>information distribution involves sending information about the >>reachability and capabilities of one router to another, usually not via >>a host. The only thing the two don't have in common is that one could >>possibly use a host while the other doesn't. > >[HC] I think there is little commanality between routing protocols and CAR >discovery. Let me explain. There are two main parts of CAR discovery: GAAR >discovery and capability exchange. I will come to GAAR discovery later. As >far as the capability exchange between the GAARs is considered, once the >two >GAARs have decided to exchange capabilities they can do so by opening >simply >a peer-to-peer connection such as TCP between them or use open loop >messaging like UDP and ICMP. I see no involvment of routing protocols here >(beyond the point that they will help route the packets containing these >messages). To give an analogy, if two routers need to do FTP between them >they simply do it using TCP. FTP is however not deemed to be related to >routing. If capabilities are exchanged via MN instead, the same logic still >applies. Only, there is extra node between them. > >Now coming to GAAR discovery part, I struggle to see how a routing protocol >are related to GAAR discovery. The problem statement clearly points hout >how >GAAR discovery (Geospace) is different from logical neighborhood discovery >(Cyberspace) on which routing protocols are built. > >In either case, the routing >>fabric has to be able to trust the information it gets. > >[HC] Why CAR discovery needs to inject any information in routing fabric? >As >I have explained above, it is about peer to peer information exchange >between GAARs. > >Thus, the >>security on the information distribution needs to be the same. Note that >>this is *not* to say that, a priori, CAR discovery and routing >>information distribution should be solved by the same protocol, just >>that they involve the same kind of security problem. >> >>For an example of the problems it might cause if security on CAR >>discovery were any less than that on routing information distribution, >>consider security on MIP binding updates. The newly decided upon >>protocol, return routability, depends critically upon the security of >>the routing fabric. If the security on CAR discovery causes the security >>of the routing fabric to be compromised, then MIP RR security on BU >>updates is compromised. >> >> jak >> > >[HC] I am not denying that the security problem may exist. But then, we >need >to point it out more directly and precisely rather than saying that the >security problem is something like the one involved in routing. I think the >problem is that "why will the two GAARs involve in capability exchange in >the first place, unless they are assured about the validity of each other". >Now we do have to come up with a solution to that. But, it is difficult to >see how this problem alone can draw relation between CAR discovery and >routing protocols. > >Regards, >Hemant > > > > >_________________________________________________________________ >Join the world?s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 17:54:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23257 for ; Wed, 13 Mar 2002 17:54:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24175 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 17:54:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23809; Wed, 13 Mar 2002 17:50:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23783 for ; Wed, 13 Mar 2002 17:50:13 -0500 (EST) Received: from hotmail.com (f205.law9.hotmail.com [64.4.9.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23070 for ; Wed, 13 Mar 2002 17:50:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 14:49:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 22:49:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 17:49:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 22:49:42.0944 (UTC) FILETIME=[5D92D200:01C1CAE1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James, Just to add to Hemant's comments, reachability of GAARs according to CAR discovery is in the view of the current MN in question. Two GAARs may be reachable for an MN but not for a different MN. In the IP sense, two GAARs are always reachable somehow through the Internet (of course I am not considering private addresses here. But even in that case it may be reachable indirectly through a border router). In summary, I share Hemant's concern about why you are going linking routing and CAR discovery. I don't know whether I am missing something. Regards, Govind. > >Hi James: > >Please see coments below marked as [HC] > >--------------------------snip--------------------------------------- >> > >on >> > > the security of routing information distribution. >> > >> > I do not agree with this part. What is the relation between routing >>and CAR >> > requirements? The first part of your requirement covers all the IETF >> > security policies and protocols, and that should be enough in my >>opinion. >> > >> >>CAR discovery involves sending information about the reachability and >>capabilities of one router to another, possibly via a host. > >[HC] CAR discovery is not about spreading reachability information of one >router to another. That is the job of routing protocols. It is about >capability exchange between GAARs. > >Routing >>information distribution involves sending information about the >>reachability and capabilities of one router to another, usually not via >>a host. The only thing the two don't have in common is that one could >>possibly use a host while the other doesn't. > >[HC] I think there is little commanality between routing protocols and CAR >discovery. Let me explain. There are two main parts of CAR discovery: GAAR >discovery and capability exchange. I will come to GAAR discovery later. As >far as the capability exchange between the GAARs is considered, once the >two >GAARs have decided to exchange capabilities they can do so by opening >simply >a peer-to-peer connection such as TCP between them or use open loop >messaging like UDP and ICMP. I see no involvment of routing protocols here >(beyond the point that they will help route the packets containing these >messages). To give an analogy, if two routers need to do FTP between them >they simply do it using TCP. FTP is however not deemed to be related to >routing. If capabilities are exchanged via MN instead, the same logic still >applies. Only, there is extra node between them. > >Now coming to GAAR discovery part, I struggle to see how a routing protocol >are related to GAAR discovery. The problem statement clearly points hout >how >GAAR discovery (Geospace) is different from logical neighborhood discovery >(Cyberspace) on which routing protocols are built. > >In either case, the routing >>fabric has to be able to trust the information it gets. > >[HC] Why CAR discovery needs to inject any information in routing fabric? >As >I have explained above, it is about peer to peer information exchange >between GAARs. > >Thus, the >>security on the information distribution needs to be the same. Note that >>this is *not* to say that, a priori, CAR discovery and routing >>information distribution should be solved by the same protocol, just >>that they involve the same kind of security problem. >> >>For an example of the problems it might cause if security on CAR >>discovery were any less than that on routing information distribution, >>consider security on MIP binding updates. The newly decided upon >>protocol, return routability, depends critically upon the security of >>the routing fabric. If the security on CAR discovery causes the security >>of the routing fabric to be compromised, then MIP RR security on BU >>updates is compromised. >> >> jak >> > >[HC] I am not denying that the security problem may exist. But then, we >need >to point it out more directly and precisely rather than saying that the >security problem is something like the one involved in routing. I think the >problem is that "why will the two GAARs involve in capability exchange in >the first place, unless they are assured about the validity of each other". >Now we do have to come up with a solution to that. But, it is difficult to >see how this problem alone can draw relation between CAR discovery and >routing protocols. > >Regards, >Hemant > > > > >_________________________________________________________________ >Join the world?s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 19:08:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25402 for ; Wed, 13 Mar 2002 19:08:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29528; Wed, 13 Mar 2002 19:02:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29496 for ; Wed, 13 Mar 2002 19:02:05 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25224 for ; Wed, 13 Mar 2002 19:02:02 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2E023B26642 for ; Thu, 14 Mar 2002 01:02:03 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 14 01:02:02 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 01:02:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB00@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 01:02:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi, I have some brief general comments on the draft and some minor specific ones. I'm afraid my old comment still applies. See below: General comments: 1. I think (somewhere in the intro or a dedicated section) that there should be some description of the entities participating in the CAR discovery, without getting into a solution. I still think the requirements are vague because they don't explain which entities are affected by these requirements. They are on such a high level, that they could apply to anything. 2. The security requirements are noon-existent as James said, and I don't think one requirement is enough, several issues need to be addressed: - Authorisation - DoS attacks - Replay protection ....etc There needs to be a separate security section. And again, detailing these requirements will show who/which part of the protocol is affected by it. Requirement 3.3 seems to mix site-local/private addresses with IPv4/IPv6 and is a bit vague. This area is quite large and some proposals are already on the table in ngtrans. Can you be a bit specific with what is actually required? Sorry (in advance) if I don't reply quickly. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 19:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25416 for ; Wed, 13 Mar 2002 19:08:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29842 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 19:08:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29528; Wed, 13 Mar 2002 19:02:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29496 for ; Wed, 13 Mar 2002 19:02:05 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25224 for ; Wed, 13 Mar 2002 19:02:02 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2E023B26642 for ; Thu, 14 Mar 2002 01:02:03 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 14 01:02:02 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 01:02:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB00@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 01:02:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi, I have some brief general comments on the draft and some minor specific ones. I'm afraid my old comment still applies. See below: General comments: 1. I think (somewhere in the intro or a dedicated section) that there should be some description of the entities participating in the CAR discovery, without getting into a solution. I still think the requirements are vague because they don't explain which entities are affected by these requirements. They are on such a high level, that they could apply to anything. 2. The security requirements are noon-existent as James said, and I don't think one requirement is enough, several issues need to be addressed: - Authorisation - DoS attacks - Replay protection ....etc There needs to be a separate security section. And again, detailing these requirements will show who/which part of the protocol is affected by it. Requirement 3.3 seems to mix site-local/private addresses with IPv4/IPv6 and is a bit vague. This area is quite large and some proposals are already on the table in ngtrans. Can you be a bit specific with what is actually required? Sorry (in advance) if I don't reply quickly. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 19:51:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26104 for ; Wed, 13 Mar 2002 19:51:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01611; Wed, 13 Mar 2002 19:45:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01580 for ; Wed, 13 Mar 2002 19:45:17 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26047 for ; Wed, 13 Mar 2002 19:45:14 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E0ijI12318; Wed, 13 Mar 2002 16:44:45 -0800 (PST) Message-ID: <00db01c1caf1$35a09510$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 16:43:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, > [HC] CAR discovery is not about spreading reachability information of one > router to another. That is the job of routing protocols. It is about > capability exchange between GAARs. > I think we have a fundamental disconnect here. Please go back and review draft-ietf-seamoby-cardiscovery-issues-02.txt. One of the primary drivers behind the CAR discovery work is spreading reachabilty information for fast handover purposes. The access routers need to know what other routers a mobile node can get to in order to be able to perform fast handover. This is, fundamentally, spreading routing reachability information. BTW, I am not aruging this from a purely theoretical perspective. We are in the process of implementing fast handover, and we have implemented one of the CAR discovery algorithms for exactly this purpose. > [HC] I think there is little commanality between routing protocols and CAR > discovery. Let me explain. There are two main parts of CAR discovery: GAAR > discovery and capability exchange. I will come to GAAR discovery later. As > far as the capability exchange between the GAARs is considered, once the two > GAARs have decided to exchange capabilities they can do so by opening simply > a peer-to-peer connection such as TCP between them or use open loop > messaging like UDP and ICMP. I see no involvment of routing protocols here > (beyond the point that they will help route the packets containing these > messages). To give an analogy, if two routers need to do FTP between them > they simply do it using TCP. FTP is however not deemed to be related to > routing. If capabilities are exchanged via MN instead, the same logic still > applies. Only, there is extra node between them. > > Now coming to GAAR discovery part, I struggle to see how a routing protocol > are related to GAAR discovery. The problem statement clearly points hout how > GAAR discovery (Geospace) is different from logical neighborhood discovery > (Cyberspace) on which routing protocols are built. > Both OSPF and BGP have the ability to send capability information, in the form of attributes. While I am not advocating that CAR discovery use OSPF or BGP, I am trying to point out that the problem is not all that different. > In either case, the routing > >fabric has to be able to trust the information it gets. > > [HC] Why CAR discovery needs to inject any information in routing fabric? As > I have explained above, it is about peer to peer information exchange > between GAARs. > Because the routing fabric is going to use information about reachable GAARs in order to make decisions about what GAARs to offer the MN. The GAARs are part of the routing fabric. > > [HC] I am not denying that the security problem may exist. But then, we need > to point it out more directly and precisely rather than saying that the > security problem is something like the one involved in routing. I think the > problem is that "why will the two GAARs involve in capability exchange in > the first place, unless they are assured about the validity of each other". > Now we do have to come up with a solution to that. But, it is difficult to > see how this problem alone can draw relation between CAR discovery and > routing protocols. > What I have tried to say (perhaps unsuccessfully) is that a GAAR that receives CAR information has to have the same level of trust in that information as it has in path information received via OSPF. Whether or not the same protocol is used is solution space, and therefore not part of the current discussion. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 19:51:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26116 for ; Wed, 13 Mar 2002 19:51:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01766 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 19:51:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01611; Wed, 13 Mar 2002 19:45:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01580 for ; Wed, 13 Mar 2002 19:45:17 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26047 for ; Wed, 13 Mar 2002 19:45:14 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E0ijI12318; Wed, 13 Mar 2002 16:44:45 -0800 (PST) Message-ID: <00db01c1caf1$35a09510$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 16:43:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, > [HC] CAR discovery is not about spreading reachability information of one > router to another. That is the job of routing protocols. It is about > capability exchange between GAARs. > I think we have a fundamental disconnect here. Please go back and review draft-ietf-seamoby-cardiscovery-issues-02.txt. One of the primary drivers behind the CAR discovery work is spreading reachabilty information for fast handover purposes. The access routers need to know what other routers a mobile node can get to in order to be able to perform fast handover. This is, fundamentally, spreading routing reachability information. BTW, I am not aruging this from a purely theoretical perspective. We are in the process of implementing fast handover, and we have implemented one of the CAR discovery algorithms for exactly this purpose. > [HC] I think there is little commanality between routing protocols and CAR > discovery. Let me explain. There are two main parts of CAR discovery: GAAR > discovery and capability exchange. I will come to GAAR discovery later. As > far as the capability exchange between the GAARs is considered, once the two > GAARs have decided to exchange capabilities they can do so by opening simply > a peer-to-peer connection such as TCP between them or use open loop > messaging like UDP and ICMP. I see no involvment of routing protocols here > (beyond the point that they will help route the packets containing these > messages). To give an analogy, if two routers need to do FTP between them > they simply do it using TCP. FTP is however not deemed to be related to > routing. If capabilities are exchanged via MN instead, the same logic still > applies. Only, there is extra node between them. > > Now coming to GAAR discovery part, I struggle to see how a routing protocol > are related to GAAR discovery. The problem statement clearly points hout how > GAAR discovery (Geospace) is different from logical neighborhood discovery > (Cyberspace) on which routing protocols are built. > Both OSPF and BGP have the ability to send capability information, in the form of attributes. While I am not advocating that CAR discovery use OSPF or BGP, I am trying to point out that the problem is not all that different. > In either case, the routing > >fabric has to be able to trust the information it gets. > > [HC] Why CAR discovery needs to inject any information in routing fabric? As > I have explained above, it is about peer to peer information exchange > between GAARs. > Because the routing fabric is going to use information about reachable GAARs in order to make decisions about what GAARs to offer the MN. The GAARs are part of the routing fabric. > > [HC] I am not denying that the security problem may exist. But then, we need > to point it out more directly and precisely rather than saying that the > security problem is something like the one involved in routing. I think the > problem is that "why will the two GAARs involve in capability exchange in > the first place, unless they are assured about the validity of each other". > Now we do have to come up with a solution to that. But, it is difficult to > see how this problem alone can draw relation between CAR discovery and > routing protocols. > What I have tried to say (perhaps unsuccessfully) is that a GAAR that receives CAR information has to have the same level of trust in that information as it has in path information received via OSPF. Whether or not the same protocol is used is solution space, and therefore not part of the current discussion. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 20:01:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26254 for ; Wed, 13 Mar 2002 20:01:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01996; Wed, 13 Mar 2002 19:59:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01967 for ; Wed, 13 Mar 2002 19:59:17 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26211 for ; Wed, 13 Mar 2002 19:59:14 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E0wiI12720; Wed, 13 Mar 2002 16:58:45 -0800 (PST) Message-ID: <00fc01c1caf3$2a44f330$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 16:57:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Just to add to Hemant's comments, reachability of GAARs according to CAR > discovery is in the view of the current MN in question. Two GAARs may be > reachable for an MN but not for a different MN. In the IP sense, two GAARs > are always reachable somehow through the Internet (of course I am not > considering private addresses here. But even in that case it may be > reachable indirectly through a border router). In summary, > I share Hemant's concern about why you are going linking routing and CAR > discovery. I don't know whether I am missing something. > I don't think there's any contradiction. Routing means getting packets to hosts. Whether they go one way for one host and another for another doesn't not make it routing. BTW, I'm wondering if you and Hemant aren't confusing "routing" *the problem* with "routing" *the protocols*? I never meant to imply that CAR discovery protocols and routing information distribution protocols are the same. We are still talking requirements, that would be solution space. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 20:01:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26265 for ; Wed, 13 Mar 2002 20:01:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA02497 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 20:01:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01996; Wed, 13 Mar 2002 19:59:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01967 for ; Wed, 13 Mar 2002 19:59:17 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26211 for ; Wed, 13 Mar 2002 19:59:14 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E0wiI12720; Wed, 13 Mar 2002 16:58:45 -0800 (PST) Message-ID: <00fc01c1caf3$2a44f330$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Wed, 13 Mar 2002 16:57:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Just to add to Hemant's comments, reachability of GAARs according to CAR > discovery is in the view of the current MN in question. Two GAARs may be > reachable for an MN but not for a different MN. In the IP sense, two GAARs > are always reachable somehow through the Internet (of course I am not > considering private addresses here. But even in that case it may be > reachable indirectly through a border router). In summary, > I share Hemant's concern about why you are going linking routing and CAR > discovery. I don't know whether I am missing something. > I don't think there's any contradiction. Routing means getting packets to hosts. Whether they go one way for one host and another for another doesn't not make it routing. BTW, I'm wondering if you and Hemant aren't confusing "routing" *the problem* with "routing" *the protocols*? I never meant to imply that CAR discovery protocols and routing information distribution protocols are the same. We are still talking requirements, that would be solution space. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 20:46:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26931 for ; Wed, 13 Mar 2002 20:46:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04191; Wed, 13 Mar 2002 20:41:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04159 for ; Wed, 13 Mar 2002 20:41:11 -0500 (EST) Received: from hotmail.com (f143.law9.hotmail.com [64.4.9.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26868 for ; Wed, 13 Mar 2002 20:41:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 17:40:39 -0800 Received: from 63.214.76.107 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 01:40:39 GMT X-Originating-IP: [63.214.76.107] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Wed, 13 Mar 2002 20:40:39 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 01:40:39.0829 (UTC) FILETIME=[3F274450:01C1CAF9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Thanks for your comments. My responses are inline. Regards, Govind. > >Hi, > >I have some brief general comments on the >draft and some minor specific ones. I'm afraid >my old comment still applies. See below: > >General comments: > >1. I think (somewhere in the intro or a dedicated >section) that there should be some description >of the entities participating in the CAR >discovery, without getting into a solution. >I still think the requirements are vague because >they don't explain which entities are affected >by these requirements. They are on such a high level, >that they could apply to anything. [Govind] ASAIK, the requirements were designed for ANY protocol involved in CAR discovery irrespective what entities may actually be part of in a solution. It might be difficult to anticipate every solution and prepare requirements for different entities probably in the solution. However, could you provide a paragraph to the WG so that we can then understand your concern more clearly. I remember you saying that you will be sending in some text but we never got it. > >2. The security requirements are noon-existent >as James said, and I don't think one requirement >is enough, several issues need to be addressed: >- Authorisation >- DoS attacks >- Replay protection >....etc >There needs to be a separate security section. >And again, detailing these requirements will show >who/which part of the protocol is affected by it. [Govind] I guess James has proposed a requirement and we are discussing this in a separate thread. May be you can post your requirement there along with the justification text there so that we don't have to deal with two threads dealing with this topic. > >Requirement 3.3 seems to mix site-local/private >addresses with IPv4/IPv6 and is a bit vague. >This area is quite large and some proposals are >already on the table in ngtrans. Can you be a bit >specific with what is actually required? [Govind] The requirement is very simple. It is attempting to look into a situation wherein APs adjacent to each other may be connected to ARs not directly reachable from each other. Again if this is not clear, could you send in text which more appropriately describes what you have in mind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 20:46:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26945 for ; Wed, 13 Mar 2002 20:46:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04480 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 20:46:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04191; Wed, 13 Mar 2002 20:41:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04159 for ; Wed, 13 Mar 2002 20:41:11 -0500 (EST) Received: from hotmail.com (f143.law9.hotmail.com [64.4.9.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26868 for ; Wed, 13 Mar 2002 20:41:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 17:40:39 -0800 Received: from 63.214.76.107 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 01:40:39 GMT X-Originating-IP: [63.214.76.107] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Wed, 13 Mar 2002 20:40:39 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 01:40:39.0829 (UTC) FILETIME=[3F274450:01C1CAF9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Thanks for your comments. My responses are inline. Regards, Govind. > >Hi, > >I have some brief general comments on the >draft and some minor specific ones. I'm afraid >my old comment still applies. See below: > >General comments: > >1. I think (somewhere in the intro or a dedicated >section) that there should be some description >of the entities participating in the CAR >discovery, without getting into a solution. >I still think the requirements are vague because >they don't explain which entities are affected >by these requirements. They are on such a high level, >that they could apply to anything. [Govind] ASAIK, the requirements were designed for ANY protocol involved in CAR discovery irrespective what entities may actually be part of in a solution. It might be difficult to anticipate every solution and prepare requirements for different entities probably in the solution. However, could you provide a paragraph to the WG so that we can then understand your concern more clearly. I remember you saying that you will be sending in some text but we never got it. > >2. The security requirements are noon-existent >as James said, and I don't think one requirement >is enough, several issues need to be addressed: >- Authorisation >- DoS attacks >- Replay protection >....etc >There needs to be a separate security section. >And again, detailing these requirements will show >who/which part of the protocol is affected by it. [Govind] I guess James has proposed a requirement and we are discussing this in a separate thread. May be you can post your requirement there along with the justification text there so that we don't have to deal with two threads dealing with this topic. > >Requirement 3.3 seems to mix site-local/private >addresses with IPv4/IPv6 and is a bit vague. >This area is quite large and some proposals are >already on the table in ngtrans. Can you be a bit >specific with what is actually required? [Govind] The requirement is very simple. It is attempting to look into a situation wherein APs adjacent to each other may be connected to ARs not directly reachable from each other. Again if this is not clear, could you send in text which more appropriately describes what you have in mind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 13 21:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27154 for ; Wed, 13 Mar 2002 21:01:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04838; Wed, 13 Mar 2002 20:55:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04805 for ; Wed, 13 Mar 2002 20:55:29 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27032 for ; Wed, 13 Mar 2002 20:55:26 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2E1tOB09405 for ; Thu, 14 Mar 2002 02:55:24 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 14 02:55:23 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 02:55:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB09@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 02:55:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >I have some brief general comments on the > >draft and some minor specific ones. I'm afraid > >my old comment still applies. See below: > > > >General comments: > > > >1. I think (somewhere in the intro or a dedicated > >section) that there should be some description > >of the entities participating in the CAR > >discovery, without getting into a solution. > >I still think the requirements are vague because > >they don't explain which entities are affected > >by these requirements. They are on such a high level, > >that they could apply to anything. > > [Govind] ASAIK, the requirements were designed for ANY protocol > involved in CAR discovery => This is the problem. The requirements are on such high level, that makes it hard to address any issues in detail. irrespective what entities may actually > be part of in a solution. It might be difficult to anticipate > every solution and prepare requirements for different entities > probably in the solution. => We know the entities already don't we? The MN, The AR and one or more GAARs. There is nothing more is there ? > However, could you provide a paragraph to the WG so > that we can then understand your concern more clearly. I remember > you saying that you will be sending in some text but we > never got it. => OK > >2. The security requirements are noon-existent > >as James said, and I don't think one requirement > >is enough, several issues need to be addressed: > >- Authorisation > >- DoS attacks > >- Replay protection > >....etc > >There needs to be a separate security section. > >And again, detailing these requirements will show > >who/which part of the protocol is affected by it. > > [Govind] I guess James has proposed a requirement and > we are discussing this in a separate thread. May be > you can post your requirement there along with the justification > text there so that we don't have to deal with > two threads dealing with this topic. => OK, but this is not about a single requirement, you need to have a few of them. > > > >Requirement 3.3 seems to mix site-local/private > >addresses with IPv4/IPv6 and is a bit vague. > >This area is quite large and some proposals are > >already on the table in ngtrans. Can you be a bit > >specific with what is actually required? > > [Govind] The requirement is very simple. It is > attempting to look into a situation wherein APs > adjacent to each other may be > connected to ARs not directly reachable from each other. => The entire CAR discovery problem looks at this scenario, but how does IPv4/v6, Site-local issues come into this? > Again if this is not clear, could you send in text which > more appropriately describes what you have in mind. > => I'll try, but I can't guarantee it. It doesn't make the comments less valid though. Hesham > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Mar 13 21:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27167 for ; Wed, 13 Mar 2002 21:01:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05548 for seamoby-archive@odin.ietf.org; Wed, 13 Mar 2002 21:01:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04838; Wed, 13 Mar 2002 20:55:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04805 for ; Wed, 13 Mar 2002 20:55:29 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27032 for ; Wed, 13 Mar 2002 20:55:26 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2E1tOB09405 for ; Thu, 14 Mar 2002 02:55:24 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 14 02:55:23 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 02:55:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB09@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 02:55:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >I have some brief general comments on the > >draft and some minor specific ones. I'm afraid > >my old comment still applies. See below: > > > >General comments: > > > >1. I think (somewhere in the intro or a dedicated > >section) that there should be some description > >of the entities participating in the CAR > >discovery, without getting into a solution. > >I still think the requirements are vague because > >they don't explain which entities are affected > >by these requirements. They are on such a high level, > >that they could apply to anything. > > [Govind] ASAIK, the requirements were designed for ANY protocol > involved in CAR discovery => This is the problem. The requirements are on such high level, that makes it hard to address any issues in detail. irrespective what entities may actually > be part of in a solution. It might be difficult to anticipate > every solution and prepare requirements for different entities > probably in the solution. => We know the entities already don't we? The MN, The AR and one or more GAARs. There is nothing more is there ? > However, could you provide a paragraph to the WG so > that we can then understand your concern more clearly. I remember > you saying that you will be sending in some text but we > never got it. => OK > >2. The security requirements are noon-existent > >as James said, and I don't think one requirement > >is enough, several issues need to be addressed: > >- Authorisation > >- DoS attacks > >- Replay protection > >....etc > >There needs to be a separate security section. > >And again, detailing these requirements will show > >who/which part of the protocol is affected by it. > > [Govind] I guess James has proposed a requirement and > we are discussing this in a separate thread. May be > you can post your requirement there along with the justification > text there so that we don't have to deal with > two threads dealing with this topic. => OK, but this is not about a single requirement, you need to have a few of them. > > > >Requirement 3.3 seems to mix site-local/private > >addresses with IPv4/IPv6 and is a bit vague. > >This area is quite large and some proposals are > >already on the table in ngtrans. Can you be a bit > >specific with what is actually required? > > [Govind] The requirement is very simple. It is > attempting to look into a situation wherein APs > adjacent to each other may be > connected to ARs not directly reachable from each other. => The entire CAR discovery problem looks at this scenario, but how does IPv4/v6, Site-local issues come into this? > Again if this is not clear, could you send in text which > more appropriately describes what you have in mind. > => I'll try, but I can't guarantee it. It doesn't make the comments less valid though. Hesham > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 10:48:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20145 for ; Thu, 14 Mar 2002 10:48:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05937; Thu, 14 Mar 2002 10:36:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05908 for ; Thu, 14 Mar 2002 10:36:55 -0500 (EST) Received: from hotmail.com (f83.law9.hotmail.com [64.4.9.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19644 for ; Thu, 14 Mar 2002 10:36:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 07:36:21 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 15:36:21 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 10:36:21 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 15:36:21.0739 (UTC) FILETIME=[FE0F8BB0:01C1CB6D] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Comments inline, Regards, Govind. > >=> This is the problem. The requirements are on such >high level, that makes it hard to address any >issues in detail [Govind] OK. please feel free to add some statements to the requirements and send it over to the mailing list. >=> We know the entities already don't we? >The MN, The AR and one or more GAARs. There is >nothing more is there ? [Govind] "Nothing more" is a very blanket statement which may not be true. I think it is solution dependent. I am not saying that the entities you mention will not be involved. > > > However, could you provide a paragraph to the WG so > > that we can then understand your concern more clearly. I remember > > you saying that you will be sending in some text but we > > never got it. > >=> OK [Govind] Thanks. > > > >2. The security requirements are noon-existent > > >as James said, and I don't think one requirement > > >is enough, several issues need to be addressed: > > >- Authorisation > > >- DoS attacks > > >- Replay protection > > >....etc > > >There needs to be a separate security section. > > >And again, detailing these requirements will show > > >who/which part of the protocol is affected by it. > > > > [Govind] I guess James has proposed a requirement and > > we are discussing this in a separate thread. May be > > you can post your requirement there along with the justification > > text there so that we don't have to deal with > > two threads dealing with this topic. > >=> OK, but this is not about a single requirement, >you need to have a few of them. [Govind] Feel free to add as many relevant requirements as you want. > > > > > > >Requirement 3.3 seems to mix site-local/private > > >addresses with IPv4/IPv6 and is a bit vague. > > >This area is quite large and some proposals are > > >already on the table in ngtrans. Can you be a bit > > >specific with what is actually required? > > > > [Govind] The requirement is very simple. It is > > attempting to look into a situation wherein APs > > adjacent to each other may be > > connected to ARs not directly reachable from each other. > >=> The entire CAR discovery problem looks at >this scenario, but how does IPv4/v6, Site-local >issues come into this? [Govind] I don't understand your question. As I explained before, the point is just to introduce the "practical scenario" of having ARs belonging to private domains ending up as GAARs. > > > Again if this is not clear, could you send in text which > > more appropriately describes what you have in mind. > > > >=> I'll try, but I can't guarantee it. It doesn't >make the comments less valid though. [Govind] Ofcourse, but unless you post your ideas one cant make any progress. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 10:48:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20155 for ; Thu, 14 Mar 2002 10:48:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06817 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 10:48:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05937; Thu, 14 Mar 2002 10:36:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05908 for ; Thu, 14 Mar 2002 10:36:55 -0500 (EST) Received: from hotmail.com (f83.law9.hotmail.com [64.4.9.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19644 for ; Thu, 14 Mar 2002 10:36:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 07:36:21 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 15:36:21 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 10:36:21 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 15:36:21.0739 (UTC) FILETIME=[FE0F8BB0:01C1CB6D] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Comments inline, Regards, Govind. > >=> This is the problem. The requirements are on such >high level, that makes it hard to address any >issues in detail [Govind] OK. please feel free to add some statements to the requirements and send it over to the mailing list. >=> We know the entities already don't we? >The MN, The AR and one or more GAARs. There is >nothing more is there ? [Govind] "Nothing more" is a very blanket statement which may not be true. I think it is solution dependent. I am not saying that the entities you mention will not be involved. > > > However, could you provide a paragraph to the WG so > > that we can then understand your concern more clearly. I remember > > you saying that you will be sending in some text but we > > never got it. > >=> OK [Govind] Thanks. > > > >2. The security requirements are noon-existent > > >as James said, and I don't think one requirement > > >is enough, several issues need to be addressed: > > >- Authorisation > > >- DoS attacks > > >- Replay protection > > >....etc > > >There needs to be a separate security section. > > >And again, detailing these requirements will show > > >who/which part of the protocol is affected by it. > > > > [Govind] I guess James has proposed a requirement and > > we are discussing this in a separate thread. May be > > you can post your requirement there along with the justification > > text there so that we don't have to deal with > > two threads dealing with this topic. > >=> OK, but this is not about a single requirement, >you need to have a few of them. [Govind] Feel free to add as many relevant requirements as you want. > > > > > > >Requirement 3.3 seems to mix site-local/private > > >addresses with IPv4/IPv6 and is a bit vague. > > >This area is quite large and some proposals are > > >already on the table in ngtrans. Can you be a bit > > >specific with what is actually required? > > > > [Govind] The requirement is very simple. It is > > attempting to look into a situation wherein APs > > adjacent to each other may be > > connected to ARs not directly reachable from each other. > >=> The entire CAR discovery problem looks at >this scenario, but how does IPv4/v6, Site-local >issues come into this? [Govind] I don't understand your question. As I explained before, the point is just to introduce the "practical scenario" of having ARs belonging to private domains ending up as GAARs. > > > Again if this is not clear, could you send in text which > > more appropriately describes what you have in mind. > > > >=> I'll try, but I can't guarantee it. It doesn't >make the comments less valid though. [Govind] Ofcourse, but unless you post your ideas one cant make any progress. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 10:48:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20190 for ; Thu, 14 Mar 2002 10:48:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06112; Thu, 14 Mar 2002 10:38:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06079 for ; Thu, 14 Mar 2002 10:38:05 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19677 for ; Thu, 14 Mar 2002 10:38:02 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA04689 for ; Thu, 14 Mar 2002 08:38:04 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA22029 for ; Thu, 14 Mar 2002 08:38:03 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 14 Mar 2002 09:38:03 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF8E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments Date: Thu, 14 Mar 2002 09:38:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, Sorry for the delay, I just came back from vacation :) See my comments below, >Madjid>OK. However, remember that the original attraction of >CAR as a protocol will be greatly diminished (IMHO) if it can't >handle inter-domain. > ----> Thats why we have to decide whether it is a SHOULD or a MUST. Madjid>> Well, to make it brief, I would say, if you want me as a costumer for your "CAR", make interdomain a MUST, otherwise, I will buy domestic and not from Seamoby:) [snip] > >Madjid>> Well, not quite, there are two issues, first >The AR-AR SA is a big IF, in case of inter-domain (I am guessing >you are dealing with more than just one new AR, right). Now, since >inter-domain is a should, I give up on this, lets move to the second >issue, you seem to be assuming that from oldAR-MN and oldAR-NewAR >SA you can deduce newAR-MN SA? How, you said that CAR comes before >Context transfer. ------> Agreed that old AR - new AR SA maybe a toughie, maybe SIKED can help us with this :) But once that is established we can have two tunnels is it not? One tunnel to the old AR from the MN and then another tunnel to the new AR. Ofcourse, this is a trivial solution and may not be the optimal way to go, but wont this work? Madjid>> Intra domain this works (I assume, by "tunnel", you are talking about a secure tunnel, otherwise I fail to see the need for a tunnel. Regards, Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 11:00:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20581 for ; Thu, 14 Mar 2002 11:00:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07008; Thu, 14 Mar 2002 10:50:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06940 for ; Thu, 14 Mar 2002 10:50:44 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20302 for ; Thu, 14 Mar 2002 10:50:41 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA15217 for ; Thu, 14 Mar 2002 08:39:38 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA04704 for ; Thu, 14 Mar 2002 08:50:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 14 Mar 2002 09:50:43 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF8F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Dirk.Trossen@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments Date: Thu, 14 Mar 2002 09:50:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Dirk, sorry for the delay, See comments below, > Madjid>> I responded to Govind on this issue. However, to respond > to the above, my issue is, say the MN needs some information before > the handover, that the AR thinks it is too sensitive to be > shared, then > the whole thing would fall apart in an inter-domain scenario?? In an MN-based decision approach, the selection of a TAR is still possible in general since it is always under the constraint of the revealed information. It is certainly true that this constraint is more stringent in the N case. But that's a drawback which lies in the fact to put the decision in the MN. You could do this also in the AR. Madjid>> Are you envisioning different selection algorithms depending on whether it is done at AR or MN? I am hearing that you are willing to sacrifice the quality of TAR selection for the sake of not having good security, in case the selection is done by MN (which also means a less elaborate selection algorithm). In either case, if sensitive information regarding the network is shared with MN, it needs to be in a secure fashion and after making sure that the MN is a trusted recipient for this information. I don't want to go too much into using context transfer for AR capability transfer since it is certainly not the scope of CT to do this. Madjid>> I have been involved in CT development in seamoby from very begining and I don't recall making capability transfer out of scope. You could argue that CAR comes before CT (like Govind did) and that is acceptable, but CT does not segregate on the type of data it transfers. Right now, the requirements cover the capability exchange which is meant to happen between ARs. As for a capability transfer from the AR to an MN for performing a TAR selection in the MN, we could incorporate this by extending requirement 3.4 in the way that each transfer of capability information within CAR has to happen in a secure manner. We should probably then also rename the heading of 3.4 in 'capability transfer'. You should also keep in mind that that the MN gets the information from the old AR, so it is enough to an SA between MN and old AR. The old AR (hopefully) has information regarding the potential new ARs (AKA CARs) which are then transferred to the MN. I have to admit that I didn't get your comment in a mail to Govind that you need an MN-newAR SA? For what is this in the context of CAR. CAR discovery is meant to determine the new AR, so why should I have an SA to this entity in the process of CAR?? Madjid>> I don't see why the capability info HAS to go to MN through oldAR (especially, if old AR originally does not have this info) , other than security reasons. If the TAR selection algorithm does not need sensitive info, or MN is trusted by the new network, it would make perfect sense to send the data directly to the MN (in case MN is making the selection). Regarding the inter-domain SHOULD issue, I agree that CAR without inter-domain reduces the relevance of CAR a lot. That's why I think that MUST is better. Madjid>> I have yet to see where intra-domain CAR is needed, so I am for MUST. Regards, Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 11:00:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20590 for ; Thu, 14 Mar 2002 11:00:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07908 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 11:00:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07008; Thu, 14 Mar 2002 10:50:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06940 for ; Thu, 14 Mar 2002 10:50:44 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20302 for ; Thu, 14 Mar 2002 10:50:41 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA15217 for ; Thu, 14 Mar 2002 08:39:38 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA04704 for ; Thu, 14 Mar 2002 08:50:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 14 Mar 2002 09:50:43 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF8F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Dirk.Trossen@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments Date: Thu, 14 Mar 2002 09:50:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Dirk, sorry for the delay, See comments below, > Madjid>> I responded to Govind on this issue. However, to respond > to the above, my issue is, say the MN needs some information before > the handover, that the AR thinks it is too sensitive to be > shared, then > the whole thing would fall apart in an inter-domain scenario?? In an MN-based decision approach, the selection of a TAR is still possible in general since it is always under the constraint of the revealed information. It is certainly true that this constraint is more stringent in the N case. But that's a drawback which lies in the fact to put the decision in the MN. You could do this also in the AR. Madjid>> Are you envisioning different selection algorithms depending on whether it is done at AR or MN? I am hearing that you are willing to sacrifice the quality of TAR selection for the sake of not having good security, in case the selection is done by MN (which also means a less elaborate selection algorithm). In either case, if sensitive information regarding the network is shared with MN, it needs to be in a secure fashion and after making sure that the MN is a trusted recipient for this information. I don't want to go too much into using context transfer for AR capability transfer since it is certainly not the scope of CT to do this. Madjid>> I have been involved in CT development in seamoby from very begining and I don't recall making capability transfer out of scope. You could argue that CAR comes before CT (like Govind did) and that is acceptable, but CT does not segregate on the type of data it transfers. Right now, the requirements cover the capability exchange which is meant to happen between ARs. As for a capability transfer from the AR to an MN for performing a TAR selection in the MN, we could incorporate this by extending requirement 3.4 in the way that each transfer of capability information within CAR has to happen in a secure manner. We should probably then also rename the heading of 3.4 in 'capability transfer'. You should also keep in mind that that the MN gets the information from the old AR, so it is enough to an SA between MN and old AR. The old AR (hopefully) has information regarding the potential new ARs (AKA CARs) which are then transferred to the MN. I have to admit that I didn't get your comment in a mail to Govind that you need an MN-newAR SA? For what is this in the context of CAR. CAR discovery is meant to determine the new AR, so why should I have an SA to this entity in the process of CAR?? Madjid>> I don't see why the capability info HAS to go to MN through oldAR (especially, if old AR originally does not have this info) , other than security reasons. If the TAR selection algorithm does not need sensitive info, or MN is trusted by the new network, it would make perfect sense to send the data directly to the MN (in case MN is making the selection). Regarding the inter-domain SHOULD issue, I agree that CAR without inter-domain reduces the relevance of CAR a lot. That's why I think that MUST is better. Madjid>> I have yet to see where intra-domain CAR is needed, so I am for MUST. Regards, Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 11:12:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20875 for ; Thu, 14 Mar 2002 11:12:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07962; Thu, 14 Mar 2002 11:00:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07896 for ; Thu, 14 Mar 2002 11:00:38 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20578 for ; Thu, 14 Mar 2002 11:00:35 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA08862 for ; Thu, 14 Mar 2002 09:00:30 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA24661 for ; Thu, 14 Mar 2002 09:00:28 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 14 Mar 2002 09:58:56 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF90@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Dirk.Trossen@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Date: Thu, 14 Mar 2002 09:58:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry for the late response, isn't MN's requirement spelled out in MN's user profile or SLA or something else recorded in the policy server of the MN's network? why does the MN has to express them again. if the new network needs it (I don't know why it would in a CAR selection), then it can get it from old network, if the old network needs, it gets it from policy server. I think what this should concentrate on is: CAR discovery protocol MUST provide means for signaling parameters needed for a TAR selection mechanims (regardless of whether it is done at MN or at AR). I know that the selection process is out of scope, but providing input for it should be in scope. signaling MN's requirements for service is a different issue. Regards, Madjid "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 11:12:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20888 for ; Thu, 14 Mar 2002 11:12:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09118 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 11:12:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07962; Thu, 14 Mar 2002 11:00:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07896 for ; Thu, 14 Mar 2002 11:00:38 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20578 for ; Thu, 14 Mar 2002 11:00:35 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA08862 for ; Thu, 14 Mar 2002 09:00:30 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA24661 for ; Thu, 14 Mar 2002 09:00:28 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 14 Mar 2002 09:58:56 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF90@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Dirk.Trossen@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Date: Thu, 14 Mar 2002 09:58:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry for the late response, isn't MN's requirement spelled out in MN's user profile or SLA or something else recorded in the policy server of the MN's network? why does the MN has to express them again. if the new network needs it (I don't know why it would in a CAR selection), then it can get it from old network, if the old network needs, it gets it from policy server. I think what this should concentrate on is: CAR discovery protocol MUST provide means for signaling parameters needed for a TAR selection mechanims (regardless of whether it is done at MN or at AR). I know that the selection process is out of scope, but providing input for it should be in scope. signaling MN's requirements for service is a different issue. Regards, Madjid "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 11:25:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21470 for ; Thu, 14 Mar 2002 11:25:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08783; Thu, 14 Mar 2002 11:08:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08758 for ; Thu, 14 Mar 2002 11:08:51 -0500 (EST) Received: from hotmail.com (f8.law7.hotmail.com [216.33.237.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20738 for ; Thu, 14 Mar 2002 11:08:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 08:08:20 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 16:08:19 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 16:08:19 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 16:08:20.0320 (UTC) FILETIME=[759FC600:01C1CB72] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I think that the genesis of this discussion thread is your concern that the current document does not bring out security aspects in detail. Sharing that, I would like this concern being addressed in a direct and precise manner. From that perspective, may I propose the following text for the security requirements part: "A CAR discovery protocol MUST address the security concerns involved in the various aspects of protocol operation, namely GAAR discovery, capability exchange and CAR selection. In particular, a) A CAR Discovery protocol MUST provide means for an AR to to verify that another AR claiming to be its GAAR is genuine. In other words, the other AR is indeed a GAAR and it is an authentic router. The authenticity of a router MAY mean that it is authorized to act as an access router by the jurisdiction of the environment (operator network, organizatoinal LAN, home network etc.) that the router resides in. b)A CAR discovery protocol MUST provide means for secure capability exchange between an AR and its GAAR. c)A CAR discovery protocol MUST provide secure means for the expression of MN requirements to CAR discovery protocol." If you like these, you need not read the rest of the comments below included as for friendly understanding purposes. >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Security Requirments for CAR Discovery >Date: Wed, 13 Mar 2002 16:43:07 -0800 > >Hemant, > > > [HC] CAR discovery is not about spreading reachability information of >one > > router to another. That is the job of routing protocols. It is about > > capability exchange between GAARs. > > > >I think we have a fundamental disconnect here. Please go back >and review draft-ietf-seamoby-cardiscovery-issues-02.txt. > >One of the primary drivers behind the CAR discovery work is spreading >reachabilty information for fast handover purposes. The access routers >need to know what other routers a mobile node can get to in order >to be able to perform fast handover. This is, fundamentally, spreading >routing >reachability information. I do not have any disconnet here. I exactly know what CAR discovery is about and agree with your detailed description above. However, I do not call it routing reachability which has completely different connotations in IP community. > >BTW, I am not aruging this from a purely theoretical perspective. >We are in the process of implementing fast handover, and >we have implemented one of the CAR discovery algorithms >for exactly this purpose. Same here. We are using CAR discovery for fast and seamless handovers and some other interesting applications too. > > > [HC] I think there is little commanality between routing protocols and >CAR > > discovery. Let me explain. There are two main parts of CAR discovery: >GAAR > > discovery and capability exchange. I will come to GAAR discovery >later. As > > far as the capability exchange between the GAARs is considered, once >the two > > GAARs have decided to exchange capabilities they can do so by opening >simply > > a peer-to-peer connection such as TCP between them or use open loop > > messaging like UDP and ICMP. I see no involvment of routing protocols >here > > (beyond the point that they will help route the packets containing >these > > messages). To give an analogy, if two routers need to do FTP between >them > > they simply do it using TCP. FTP is however not deemed to be related >to > > routing. If capabilities are exchanged via MN instead, the same logic >still > > applies. Only, there is extra node between them. > > > > Now coming to GAAR discovery part, I struggle to see how a routing >protocol > > are related to GAAR discovery. The problem statement clearly points >hout how > > GAAR discovery (Geospace) is different from logical neighborhood >discovery > > (Cyberspace) on which routing protocols are built. > > > >Both OSPF and BGP have the ability to send capability information, in >the form >of attributes. While I am not advocating that CAR discovery use OSPF or >BGP, I am trying to point out that the problem is not all that >different. I think that there are some fundamental differences between capability attributes of OSPF, BGP and what is required for CAR. Some of them that come to mind are as follows: - Subjects of OSPF and BGP are all routers in a domain and all ASs in the Internet, respectively. While, CAR discovery affects only a small percentage of routers, namely the access routers. - Routing protocols employ generous aggregation techniques at the inerdomain boundaries. This is not in the interest of CAR, as every router in a given domain may actually have different capabilities (best examples are load and lower layer IDs). - Attributes exchanged by inter-domain routing protocls are typically relevant for domains as a whole (e.g. AS policy in BGP). It does not seem that these will suffice for CAR as here we have to exchange very fine grained and possibly fast changing attributes of different ARs. - Either the AR or GAAR may actually not be a part of routing information exchange. For example, a router in my home can be statically configured to forward IP packets to some router in the Internet. However, I still may want it to exchange capabilities with another AR. Regards, Hemant _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 11:25:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21480 for ; Thu, 14 Mar 2002 11:25:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11242 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 11:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08783; Thu, 14 Mar 2002 11:08:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08758 for ; Thu, 14 Mar 2002 11:08:51 -0500 (EST) Received: from hotmail.com (f8.law7.hotmail.com [216.33.237.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20738 for ; Thu, 14 Mar 2002 11:08:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 08:08:20 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 16:08:19 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 16:08:19 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 16:08:20.0320 (UTC) FILETIME=[759FC600:01C1CB72] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I think that the genesis of this discussion thread is your concern that the current document does not bring out security aspects in detail. Sharing that, I would like this concern being addressed in a direct and precise manner. From that perspective, may I propose the following text for the security requirements part: "A CAR discovery protocol MUST address the security concerns involved in the various aspects of protocol operation, namely GAAR discovery, capability exchange and CAR selection. In particular, a) A CAR Discovery protocol MUST provide means for an AR to to verify that another AR claiming to be its GAAR is genuine. In other words, the other AR is indeed a GAAR and it is an authentic router. The authenticity of a router MAY mean that it is authorized to act as an access router by the jurisdiction of the environment (operator network, organizatoinal LAN, home network etc.) that the router resides in. b)A CAR discovery protocol MUST provide means for secure capability exchange between an AR and its GAAR. c)A CAR discovery protocol MUST provide secure means for the expression of MN requirements to CAR discovery protocol." If you like these, you need not read the rest of the comments below included as for friendly understanding purposes. >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Security Requirments for CAR Discovery >Date: Wed, 13 Mar 2002 16:43:07 -0800 > >Hemant, > > > [HC] CAR discovery is not about spreading reachability information of >one > > router to another. That is the job of routing protocols. It is about > > capability exchange between GAARs. > > > >I think we have a fundamental disconnect here. Please go back >and review draft-ietf-seamoby-cardiscovery-issues-02.txt. > >One of the primary drivers behind the CAR discovery work is spreading >reachabilty information for fast handover purposes. The access routers >need to know what other routers a mobile node can get to in order >to be able to perform fast handover. This is, fundamentally, spreading >routing >reachability information. I do not have any disconnet here. I exactly know what CAR discovery is about and agree with your detailed description above. However, I do not call it routing reachability which has completely different connotations in IP community. > >BTW, I am not aruging this from a purely theoretical perspective. >We are in the process of implementing fast handover, and >we have implemented one of the CAR discovery algorithms >for exactly this purpose. Same here. We are using CAR discovery for fast and seamless handovers and some other interesting applications too. > > > [HC] I think there is little commanality between routing protocols and >CAR > > discovery. Let me explain. There are two main parts of CAR discovery: >GAAR > > discovery and capability exchange. I will come to GAAR discovery >later. As > > far as the capability exchange between the GAARs is considered, once >the two > > GAARs have decided to exchange capabilities they can do so by opening >simply > > a peer-to-peer connection such as TCP between them or use open loop > > messaging like UDP and ICMP. I see no involvment of routing protocols >here > > (beyond the point that they will help route the packets containing >these > > messages). To give an analogy, if two routers need to do FTP between >them > > they simply do it using TCP. FTP is however not deemed to be related >to > > routing. If capabilities are exchanged via MN instead, the same logic >still > > applies. Only, there is extra node between them. > > > > Now coming to GAAR discovery part, I struggle to see how a routing >protocol > > are related to GAAR discovery. The problem statement clearly points >hout how > > GAAR discovery (Geospace) is different from logical neighborhood >discovery > > (Cyberspace) on which routing protocols are built. > > > >Both OSPF and BGP have the ability to send capability information, in >the form >of attributes. While I am not advocating that CAR discovery use OSPF or >BGP, I am trying to point out that the problem is not all that >different. I think that there are some fundamental differences between capability attributes of OSPF, BGP and what is required for CAR. Some of them that come to mind are as follows: - Subjects of OSPF and BGP are all routers in a domain and all ASs in the Internet, respectively. While, CAR discovery affects only a small percentage of routers, namely the access routers. - Routing protocols employ generous aggregation techniques at the inerdomain boundaries. This is not in the interest of CAR, as every router in a given domain may actually have different capabilities (best examples are load and lower layer IDs). - Attributes exchanged by inter-domain routing protocls are typically relevant for domains as a whole (e.g. AS policy in BGP). It does not seem that these will suffice for CAR as here we have to exchange very fine grained and possibly fast changing attributes of different ARs. - Either the AR or GAAR may actually not be a part of routing information exchange. For example, a router in my home can be statically configured to forward IP packets to some router in the Internet. However, I still may want it to exchange capabilities with another AR. Regards, Hemant _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 11:26:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21501 for ; Thu, 14 Mar 2002 11:26:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09712; Thu, 14 Mar 2002 11:16:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09687 for ; Thu, 14 Mar 2002 11:16:51 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21034 for ; Thu, 14 Mar 2002 11:16:42 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA11527 for ; Thu, 14 Mar 2002 09:16:24 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA04903 for ; Thu, 14 Mar 2002 09:04:29 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <1LKF3MH7>; Thu, 14 Mar 2002 10:16:22 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF91@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 10:16:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I think your second sentence is putting most of its emphasis on protecting routing information. I don't know what parameters the CAR discovery mechanism needs, and what type of capabilities are communicated, but whatever parameters those are, if they are sensitive, they must be protected. So a stronger alternative would be: The Seamoby CAR discovery solution MUST provide proper security and protection for network's sensitive information. Furthermore, security on CAR information and capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of network information distribution. Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 13, 2002 1:52 PM To: seamoby@ietf.org Subject: [Seamoby] Security Requirments for CAR Discovery The current requirements draft is a little thin on security. Here's a proposal: The Seamoby CAR discovery solution MUST provide proper security. Security on CAR information and capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of routing information distribution. Security on communication of MN preferences to ARs MUST conform and interoperate with existing IETF security and AAA policies and protocols for host security, where applicable. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 11:26:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21511 for ; Thu, 14 Mar 2002 11:26:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11272 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 11:26:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09712; Thu, 14 Mar 2002 11:16:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09687 for ; Thu, 14 Mar 2002 11:16:51 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21034 for ; Thu, 14 Mar 2002 11:16:42 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA11527 for ; Thu, 14 Mar 2002 09:16:24 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA04903 for ; Thu, 14 Mar 2002 09:04:29 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <1LKF3MH7>; Thu, 14 Mar 2002 10:16:22 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF91@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 10:16:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I think your second sentence is putting most of its emphasis on protecting routing information. I don't know what parameters the CAR discovery mechanism needs, and what type of capabilities are communicated, but whatever parameters those are, if they are sensitive, they must be protected. So a stronger alternative would be: The Seamoby CAR discovery solution MUST provide proper security and protection for network's sensitive information. Furthermore, security on CAR information and capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of network information distribution. Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 13, 2002 1:52 PM To: seamoby@ietf.org Subject: [Seamoby] Security Requirments for CAR Discovery The current requirements draft is a little thin on security. Here's a proposal: The Seamoby CAR discovery solution MUST provide proper security. Security on CAR information and capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of routing information distribution. Security on communication of MN preferences to ARs MUST conform and interoperate with existing IETF security and AAA policies and protocols for host security, where applicable. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 11:35:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20201 for ; Thu, 14 Mar 2002 10:48:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06845 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 10:48:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06112; Thu, 14 Mar 2002 10:38:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06079 for ; Thu, 14 Mar 2002 10:38:05 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19677 for ; Thu, 14 Mar 2002 10:38:02 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA04689 for ; Thu, 14 Mar 2002 08:38:04 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA22029 for ; Thu, 14 Mar 2002 08:38:03 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 14 Mar 2002 09:38:03 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF8E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements ... Call for Comments Date: Thu, 14 Mar 2002 09:38:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, Sorry for the delay, I just came back from vacation :) See my comments below, >Madjid>OK. However, remember that the original attraction of >CAR as a protocol will be greatly diminished (IMHO) if it can't >handle inter-domain. > ----> Thats why we have to decide whether it is a SHOULD or a MUST. Madjid>> Well, to make it brief, I would say, if you want me as a costumer for your "CAR", make interdomain a MUST, otherwise, I will buy domestic and not from Seamoby:) [snip] > >Madjid>> Well, not quite, there are two issues, first >The AR-AR SA is a big IF, in case of inter-domain (I am guessing >you are dealing with more than just one new AR, right). Now, since >inter-domain is a should, I give up on this, lets move to the second >issue, you seem to be assuming that from oldAR-MN and oldAR-NewAR >SA you can deduce newAR-MN SA? How, you said that CAR comes before >Context transfer. ------> Agreed that old AR - new AR SA maybe a toughie, maybe SIKED can help us with this :) But once that is established we can have two tunnels is it not? One tunnel to the old AR from the MN and then another tunnel to the new AR. Ofcourse, this is a trivial solution and may not be the optimal way to go, but wont this work? Madjid>> Intra domain this works (I assume, by "tunnel", you are talking about a secure tunnel, otherwise I fail to see the need for a tunnel. Regards, Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 11:37:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21800 for ; Thu, 14 Mar 2002 11:37:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11626; Thu, 14 Mar 2002 11:29:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11597 for ; Thu, 14 Mar 2002 11:29:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21672 for ; Thu, 14 Mar 2002 11:29:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EGSVI28276; Thu, 14 Mar 2002 08:28:31 -0800 (PST) Message-ID: <002301c1cb75$0e9b1060$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Govind Krishnamurthi'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB09@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 08:26:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Re. the comments on security, maybe we need a more comprehensive threat analysis such as Claude did for paging? The requirement I did was pretty generic. jak ----- Original Message ----- From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" ; Sent: Wednesday, March 13, 2002 5:55 PM Subject: RE: [Seamoby] comments on CAR Discovery Requirements > >I have some brief general comments on the > > >draft and some minor specific ones. I'm afraid > > >my old comment still applies. See below: > > > > > >General comments: > > > > > >1. I think (somewhere in the intro or a dedicated > > >section) that there should be some description > > >of the entities participating in the CAR > > >discovery, without getting into a solution. > > >I still think the requirements are vague because > > >they don't explain which entities are affected > > >by these requirements. They are on such a high level, > > >that they could apply to anything. > > > > [Govind] ASAIK, the requirements were designed for ANY protocol > > involved in CAR discovery > > => This is the problem. The requirements are on such > high level, that makes it hard to address any > issues in detail. > > irrespective what entities may actually > > be part of in a solution. It might be difficult to anticipate > > every solution and prepare requirements for different entities > > probably in the solution. > > => We know the entities already don't we? > The MN, The AR and one or more GAARs. There is > nothing more is there ? > > > However, could you provide a paragraph to the WG so > > that we can then understand your concern more clearly. I remember > > you saying that you will be sending in some text but we > > never got it. > > => OK > > > >2. The security requirements are noon-existent > > >as James said, and I don't think one requirement > > >is enough, several issues need to be addressed: > > >- Authorisation > > >- DoS attacks > > >- Replay protection > > >....etc > > >There needs to be a separate security section. > > >And again, detailing these requirements will show > > >who/which part of the protocol is affected by it. > > > > [Govind] I guess James has proposed a requirement and > > we are discussing this in a separate thread. May be > > you can post your requirement there along with the justification > > text there so that we don't have to deal with > > two threads dealing with this topic. > > => OK, but this is not about a single requirement, > you need to have a few of them. > > > > > > >Requirement 3.3 seems to mix site-local/private > > >addresses with IPv4/IPv6 and is a bit vague. > > >This area is quite large and some proposals are > > >already on the table in ngtrans. Can you be a bit > > >specific with what is actually required? > > > > [Govind] The requirement is very simple. It is > > attempting to look into a situation wherein APs > > adjacent to each other may be > > connected to ARs not directly reachable from each other. > > => The entire CAR discovery problem looks at > this scenario, but how does IPv4/v6, Site-local > issues come into this? > > > Again if this is not clear, could you send in text which > > more appropriately describes what you have in mind. > > > > => I'll try, but I can't guarantee it. It doesn't > make the comments less valid though. > > Hesham > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 11:37:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21809 for ; Thu, 14 Mar 2002 11:37:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12639 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 11:37:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11626; Thu, 14 Mar 2002 11:29:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11597 for ; Thu, 14 Mar 2002 11:29:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21672 for ; Thu, 14 Mar 2002 11:29:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EGSVI28276; Thu, 14 Mar 2002 08:28:31 -0800 (PST) Message-ID: <002301c1cb75$0e9b1060$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Govind Krishnamurthi'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB09@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 08:26:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Re. the comments on security, maybe we need a more comprehensive threat analysis such as Claude did for paging? The requirement I did was pretty generic. jak ----- Original Message ----- From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" ; Sent: Wednesday, March 13, 2002 5:55 PM Subject: RE: [Seamoby] comments on CAR Discovery Requirements > >I have some brief general comments on the > > >draft and some minor specific ones. I'm afraid > > >my old comment still applies. See below: > > > > > >General comments: > > > > > >1. I think (somewhere in the intro or a dedicated > > >section) that there should be some description > > >of the entities participating in the CAR > > >discovery, without getting into a solution. > > >I still think the requirements are vague because > > >they don't explain which entities are affected > > >by these requirements. They are on such a high level, > > >that they could apply to anything. > > > > [Govind] ASAIK, the requirements were designed for ANY protocol > > involved in CAR discovery > > => This is the problem. The requirements are on such > high level, that makes it hard to address any > issues in detail. > > irrespective what entities may actually > > be part of in a solution. It might be difficult to anticipate > > every solution and prepare requirements for different entities > > probably in the solution. > > => We know the entities already don't we? > The MN, The AR and one or more GAARs. There is > nothing more is there ? > > > However, could you provide a paragraph to the WG so > > that we can then understand your concern more clearly. I remember > > you saying that you will be sending in some text but we > > never got it. > > => OK > > > >2. The security requirements are noon-existent > > >as James said, and I don't think one requirement > > >is enough, several issues need to be addressed: > > >- Authorisation > > >- DoS attacks > > >- Replay protection > > >....etc > > >There needs to be a separate security section. > > >And again, detailing these requirements will show > > >who/which part of the protocol is affected by it. > > > > [Govind] I guess James has proposed a requirement and > > we are discussing this in a separate thread. May be > > you can post your requirement there along with the justification > > text there so that we don't have to deal with > > two threads dealing with this topic. > > => OK, but this is not about a single requirement, > you need to have a few of them. > > > > > > >Requirement 3.3 seems to mix site-local/private > > >addresses with IPv4/IPv6 and is a bit vague. > > >This area is quite large and some proposals are > > >already on the table in ngtrans. Can you be a bit > > >specific with what is actually required? > > > > [Govind] The requirement is very simple. It is > > attempting to look into a situation wherein APs > > adjacent to each other may be > > connected to ARs not directly reachable from each other. > > => The entire CAR discovery problem looks at > this scenario, but how does IPv4/v6, Site-local > issues come into this? > > > Again if this is not clear, could you send in text which > > more appropriately describes what you have in mind. > > > > => I'll try, but I can't guarantee it. It doesn't > make the comments less valid though. > > Hesham > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 12:07:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22794 for ; Thu, 14 Mar 2002 12:07:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13660; Thu, 14 Mar 2002 11:51:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13631 for ; Thu, 14 Mar 2002 11:51:27 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22310 for ; Thu, 14 Mar 2002 11:51:23 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2EGpbZ00983 for ; Thu, 14 Mar 2002 18:51:37 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Mar 2002 10:51:23 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 10:50:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Thu, 14 Mar 2002 11:50:56 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHLcTXHz/MHPugWSwi9IZh6yeo+TgABpqxw To: , X-OriginalArrivalTime: 14 Mar 2002 16:50:57.0131 (UTC) FILETIME=[699A2BB0:01C1CB78] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA13632 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Madjid, I'm not saying that MN's requirements have to be spelled out again. 'Means to express the requirements' includes some mechanisms to define these requirements somehow and the means that they can be used as an input to the CAR discovery protocol. It is certainly possible that the first part is done by currently existing protocols, but the requirement merely states that the means are mandatory for the CAR discovery solution, otherwise it cannot fulfil its task. Maybe, here's some confusion in general sometimes that the requirements always mandate NEW functionality. This is not the case. The requirements merely describe the functionality that is needed to do the job. Whether or not this will be done in the final proposal by existing protocols, modifications to existing ones, or new mechanisms is out of the scope of the requirements. Regards, Dirk -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Thursday, March 14, 2002 10:59 AM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Sorry for the late response, isn't MN's requirement spelled out in MN's user profile or SLA or something else recorded in the policy server of the MN's network? why does the MN has to express them again. if the new network needs it (I don't know why it would in a CAR selection), then it can get it from old network, if the old network needs, it gets it from policy server. I think what this should concentrate on is: CAR discovery protocol MUST provide means for signaling parameters needed for a TAR selection mechanims (regardless of whether it is done at MN or at AR). I know that the selection process is out of scope, but providing input for it should be in scope. signaling MN's requirements for service is a different issue. Regards, Madjid "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 12:07:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22805 for ; Thu, 14 Mar 2002 12:07:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16456 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 12:07:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13660; Thu, 14 Mar 2002 11:51:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13631 for ; Thu, 14 Mar 2002 11:51:27 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22310 for ; Thu, 14 Mar 2002 11:51:23 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2EGpbZ00983 for ; Thu, 14 Mar 2002 18:51:37 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Mar 2002 10:51:23 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 10:50:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CAR Discovery Requirements Date: Thu, 14 Mar 2002 11:50:56 -0500 Message-ID: Thread-Topic: [Seamoby] CAR Discovery Requirements Thread-Index: AcHLcTXHz/MHPugWSwi9IZh6yeo+TgABpqxw To: , X-OriginalArrivalTime: 14 Mar 2002 16:50:57.0131 (UTC) FILETIME=[699A2BB0:01C1CB78] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA13632 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Madjid, I'm not saying that MN's requirements have to be spelled out again. 'Means to express the requirements' includes some mechanisms to define these requirements somehow and the means that they can be used as an input to the CAR discovery protocol. It is certainly possible that the first part is done by currently existing protocols, but the requirement merely states that the means are mandatory for the CAR discovery solution, otherwise it cannot fulfil its task. Maybe, here's some confusion in general sometimes that the requirements always mandate NEW functionality. This is not the case. The requirements merely describe the functionality that is needed to do the job. Whether or not this will be done in the final proposal by existing protocols, modifications to existing ones, or new mechanisms is out of the scope of the requirements. Regards, Dirk -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Thursday, March 14, 2002 10:59 AM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Sorry for the late response, isn't MN's requirement spelled out in MN's user profile or SLA or something else recorded in the policy server of the MN's network? why does the MN has to express them again. if the new network needs it (I don't know why it would in a CAR selection), then it can get it from old network, if the old network needs, it gets it from policy server. I think what this should concentrate on is: CAR discovery protocol MUST provide means for signaling parameters needed for a TAR selection mechanims (regardless of whether it is done at MN or at AR). I know that the selection process is out of scope, but providing input for it should be in scope. signaling MN's requirements for service is a different issue. Regards, Madjid "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 13:16:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24577 for ; Thu, 14 Mar 2002 13:16:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21213; Thu, 14 Mar 2002 13:10:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21181 for ; Thu, 14 Mar 2002 13:10:54 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24440 for ; Thu, 14 Mar 2002 13:10:52 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EIANI01460; Thu, 14 Mar 2002 10:10:23 -0800 (PST) Message-ID: <01a301c1cb83$48f2a3a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 10:08:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I think these are individual requirements, and should be separated out as such. > a) A CAR Discovery protocol MUST provide means for an AR to to verify that > another AR claiming to be its GAAR is genuine. In other words, the other AR > is indeed a GAAR and it is an authentic router. The authenticity of a router > MAY mean that it is authorized to act as an access router by the > jurisdiction of the environment (operator network, organizatoinal LAN, home > network etc.) that the router resides in. > OK, this is what I was saying about hooking into the security provided by the routing infrastructure, but you have spelled it out in more detail here. Good. > b)A CAR discovery protocol MUST provide means for secure capability exchange > between an AR and its GAAR. > > c)A CAR discovery protocol MUST provide secure means for the expression of > MN requirements to CAR discovery protocol." > These are also OK. However, I disagree with "A CAR discovery protocol". The implication here is that there is one protocol that does both. It is not clear to me at this point that this is so. I would prefer "A solution to the CAR discovery problem" or "Protocols involved in CAR discovery", something like that. Other than that, I think these are fine. > I do not have any disconnet here. I exactly know what CAR discovery is > about and agree with your detailed description above. However, I do not call > it routing reachability which has completely different connotations in IP > community. > One of the issues I have with this whole discussion is an assumption, which I think I'm seeing, that the problems Seamoby is addressing are somehow so radically different from those of the rest of the Internet that new terms must be invented to describe them. It reminds me of the early days of object oriented programming where people felt they had to invent all kinds of new terminology to describe what was essentially a function call with a default first argument. Extraordinary claims require extraordinary proof. I've not found any such proof so far that convinces me that radically new terminology is needed for what's been around in the Internet for 30 years. If you can provide it for me, I'll be happy to accept some new terminology. > > I think that there are some fundamental differences between capability > attributes of OSPF, BGP and what is required for CAR. Some of them that come > to mind are as follows: > > - Subjects of OSPF and BGP are all routers in a domain and all ASs in the > Internet, respectively. While, CAR discovery affects only a small percentage > of routers, namely the access routers. > > - Routing protocols employ generous aggregation techniques at the inerdomain > boundaries. This is not in the interest of CAR, as every router in a given > domain may actually have different capabilities (best examples are load and > lower layer IDs). > > - Attributes exchanged by inter-domain routing protocls are typically > relevant for domains as a whole (e.g. AS policy in BGP). It does not seem > that these will suffice for CAR as here we have to exchange very fine > grained and possibly fast changing attributes of different ARs. > > - Either the AR or GAAR may actually not be a part of routing information > exchange. For example, a router in my home can be statically configured to > forward IP packets to some router in the Internet. However, I still may want > it to exchange capabilities with another AR. > I'm not arguing that the *content* of the attributes currently exchanged by these routing protocols is different. What I am arguing is that the *concept* of exchanging attributes is essentially the same as capability exchange. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 13:16:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24586 for ; Thu, 14 Mar 2002 13:16:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21602 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 13:16:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21213; Thu, 14 Mar 2002 13:10:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21181 for ; Thu, 14 Mar 2002 13:10:54 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24440 for ; Thu, 14 Mar 2002 13:10:52 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EIANI01460; Thu, 14 Mar 2002 10:10:23 -0800 (PST) Message-ID: <01a301c1cb83$48f2a3a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 10:08:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I think these are individual requirements, and should be separated out as such. > a) A CAR Discovery protocol MUST provide means for an AR to to verify that > another AR claiming to be its GAAR is genuine. In other words, the other AR > is indeed a GAAR and it is an authentic router. The authenticity of a router > MAY mean that it is authorized to act as an access router by the > jurisdiction of the environment (operator network, organizatoinal LAN, home > network etc.) that the router resides in. > OK, this is what I was saying about hooking into the security provided by the routing infrastructure, but you have spelled it out in more detail here. Good. > b)A CAR discovery protocol MUST provide means for secure capability exchange > between an AR and its GAAR. > > c)A CAR discovery protocol MUST provide secure means for the expression of > MN requirements to CAR discovery protocol." > These are also OK. However, I disagree with "A CAR discovery protocol". The implication here is that there is one protocol that does both. It is not clear to me at this point that this is so. I would prefer "A solution to the CAR discovery problem" or "Protocols involved in CAR discovery", something like that. Other than that, I think these are fine. > I do not have any disconnet here. I exactly know what CAR discovery is > about and agree with your detailed description above. However, I do not call > it routing reachability which has completely different connotations in IP > community. > One of the issues I have with this whole discussion is an assumption, which I think I'm seeing, that the problems Seamoby is addressing are somehow so radically different from those of the rest of the Internet that new terms must be invented to describe them. It reminds me of the early days of object oriented programming where people felt they had to invent all kinds of new terminology to describe what was essentially a function call with a default first argument. Extraordinary claims require extraordinary proof. I've not found any such proof so far that convinces me that radically new terminology is needed for what's been around in the Internet for 30 years. If you can provide it for me, I'll be happy to accept some new terminology. > > I think that there are some fundamental differences between capability > attributes of OSPF, BGP and what is required for CAR. Some of them that come > to mind are as follows: > > - Subjects of OSPF and BGP are all routers in a domain and all ASs in the > Internet, respectively. While, CAR discovery affects only a small percentage > of routers, namely the access routers. > > - Routing protocols employ generous aggregation techniques at the inerdomain > boundaries. This is not in the interest of CAR, as every router in a given > domain may actually have different capabilities (best examples are load and > lower layer IDs). > > - Attributes exchanged by inter-domain routing protocls are typically > relevant for domains as a whole (e.g. AS policy in BGP). It does not seem > that these will suffice for CAR as here we have to exchange very fine > grained and possibly fast changing attributes of different ARs. > > - Either the AR or GAAR may actually not be a part of routing information > exchange. For example, a router in my home can be statically configured to > forward IP packets to some router in the Internet. However, I still may want > it to exchange capabilities with another AR. > I'm not arguing that the *content* of the attributes currently exchanged by these routing protocols is different. What I am arguing is that the *concept* of exchanging attributes is essentially the same as capability exchange. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 15:25:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29437 for ; Thu, 14 Mar 2002 15:25:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03138; Thu, 14 Mar 2002 15:17:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03105 for ; Thu, 14 Mar 2002 15:17:09 -0500 (EST) Received: from hotmail.com (f43.law7.hotmail.com [216.33.237.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29157 for ; Thu, 14 Mar 2002 15:17:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 12:16:37 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 20:16:37 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 20:16:37 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 20:16:37.0680 (UTC) FILETIME=[25248300:01C1CB95] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I am happy that we have made progress towards stating the security concerns in our protocol more clearly. Your suggestions about replacing "A protocol" by other alternatives is well taken. (Also, not that it matters to the business at hand, but how do you like the terminology "handoff reachability" defined as the reachability of an AR from another AR for "MN handoffs". "Routing reachability" means reachability of one router from another router for "IP packet routing". Since the concepts are clearly different, different terminology may help to avoid confusion. Again, it does not matter as to what terminology both of us like, as long as we are in sync on the issues). Cheers, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Security Requirments for CAR Discovery >Date: Thu, 14 Mar 2002 10:08:46 -0800 > >Hemant, > >I think these are individual requirements, and should be separated out >as such. > > > a) A CAR Discovery protocol MUST provide means for an AR to to verify >that > > another AR claiming to be its GAAR is genuine. In other words, the >other AR > > is indeed a GAAR and it is an authentic router. The authenticity of a >router > > MAY mean that it is authorized to act as an access router by the > > jurisdiction of the environment (operator network, organizatoinal LAN, >home > > network etc.) that the router resides in. > > > >OK, this is what I was saying about hooking into the security provided >by the >routing infrastructure, but you have spelled it out in more detail here. >Good. > > > b)A CAR discovery protocol MUST provide means for secure capability >exchange > > between an AR and its GAAR. > > > > c)A CAR discovery protocol MUST provide secure means for the >expression of > > MN requirements to CAR discovery protocol." > > > >These are also OK. > >However, I disagree with "A CAR discovery protocol". The implication >here is that there is >one protocol that does both. It is not clear to me at this point that >this is so. >I would prefer "A solution to the CAR discovery problem" or "Protocols >involved in CAR discovery", something like that. > >Other than that, I think these are fine. > > > I do not have any disconnet here. I exactly know what CAR >discovery is > > about and agree with your detailed description above. However, I do >not call > > it routing reachability which has completely different connotations in >IP > > community. > > > >One of the issues I have with this whole discussion is an assumption, >which I think >I'm seeing, that the problems Seamoby is addressing are somehow so >radically different from those of the rest of the Internet that new >terms must >be invented to describe them. It reminds me of the early days of object >oriented programming where people felt they had to invent all kinds of >new >terminology to describe what was essentially a function call with a >default >first argument. Extraordinary claims require extraordinary proof. I've >not found any such proof so far that convinces me that radically new >terminology is needed for what's been around in the Internet for 30 >years. >If you can provide it for me, I'll be happy to accept some new >terminology. > > > > > I think that there are some fundamental differences between >capability > > attributes of OSPF, BGP and what is required for CAR. Some of them >that come > > to mind are as follows: > > > > - Subjects of OSPF and BGP are all routers in a domain and all ASs in >the > > Internet, respectively. While, CAR discovery affects only a small >percentage > > of routers, namely the access routers. > > > > - Routing protocols employ generous aggregation techniques at the >inerdomain > > boundaries. This is not in the interest of CAR, as every router in a >given > > domain may actually have different capabilities (best examples are >load and > > lower layer IDs). > > > > - Attributes exchanged by inter-domain routing protocls are typically > > relevant for domains as a whole (e.g. AS policy in BGP). It does not >seem > > that these will suffice for CAR as here we have to exchange very fine > > grained and possibly fast changing attributes of different ARs. > > > > - Either the AR or GAAR may actually not be a part of routing >information > > exchange. For example, a router in my home can be statically >configured to > > forward IP packets to some router in the Internet. However, I still >may want > > it to exchange capabilities with another AR. > > > >I'm not arguing that the *content* of the attributes currently exchanged >by >these routing protocols is different. What I am arguing is that the >*concept* >of exchanging attributes is essentially the same as capability exchange. > > > jak > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 15:25:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29450 for ; Thu, 14 Mar 2002 15:25:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04056 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 15:25:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03138; Thu, 14 Mar 2002 15:17:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03105 for ; Thu, 14 Mar 2002 15:17:09 -0500 (EST) Received: from hotmail.com (f43.law7.hotmail.com [216.33.237.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29157 for ; Thu, 14 Mar 2002 15:17:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 12:16:37 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 20:16:37 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 20:16:37 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 20:16:37.0680 (UTC) FILETIME=[25248300:01C1CB95] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I am happy that we have made progress towards stating the security concerns in our protocol more clearly. Your suggestions about replacing "A protocol" by other alternatives is well taken. (Also, not that it matters to the business at hand, but how do you like the terminology "handoff reachability" defined as the reachability of an AR from another AR for "MN handoffs". "Routing reachability" means reachability of one router from another router for "IP packet routing". Since the concepts are clearly different, different terminology may help to avoid confusion. Again, it does not matter as to what terminology both of us like, as long as we are in sync on the issues). Cheers, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Security Requirments for CAR Discovery >Date: Thu, 14 Mar 2002 10:08:46 -0800 > >Hemant, > >I think these are individual requirements, and should be separated out >as such. > > > a) A CAR Discovery protocol MUST provide means for an AR to to verify >that > > another AR claiming to be its GAAR is genuine. In other words, the >other AR > > is indeed a GAAR and it is an authentic router. The authenticity of a >router > > MAY mean that it is authorized to act as an access router by the > > jurisdiction of the environment (operator network, organizatoinal LAN, >home > > network etc.) that the router resides in. > > > >OK, this is what I was saying about hooking into the security provided >by the >routing infrastructure, but you have spelled it out in more detail here. >Good. > > > b)A CAR discovery protocol MUST provide means for secure capability >exchange > > between an AR and its GAAR. > > > > c)A CAR discovery protocol MUST provide secure means for the >expression of > > MN requirements to CAR discovery protocol." > > > >These are also OK. > >However, I disagree with "A CAR discovery protocol". The implication >here is that there is >one protocol that does both. It is not clear to me at this point that >this is so. >I would prefer "A solution to the CAR discovery problem" or "Protocols >involved in CAR discovery", something like that. > >Other than that, I think these are fine. > > > I do not have any disconnet here. I exactly know what CAR >discovery is > > about and agree with your detailed description above. However, I do >not call > > it routing reachability which has completely different connotations in >IP > > community. > > > >One of the issues I have with this whole discussion is an assumption, >which I think >I'm seeing, that the problems Seamoby is addressing are somehow so >radically different from those of the rest of the Internet that new >terms must >be invented to describe them. It reminds me of the early days of object >oriented programming where people felt they had to invent all kinds of >new >terminology to describe what was essentially a function call with a >default >first argument. Extraordinary claims require extraordinary proof. I've >not found any such proof so far that convinces me that radically new >terminology is needed for what's been around in the Internet for 30 >years. >If you can provide it for me, I'll be happy to accept some new >terminology. > > > > > I think that there are some fundamental differences between >capability > > attributes of OSPF, BGP and what is required for CAR. Some of them >that come > > to mind are as follows: > > > > - Subjects of OSPF and BGP are all routers in a domain and all ASs in >the > > Internet, respectively. While, CAR discovery affects only a small >percentage > > of routers, namely the access routers. > > > > - Routing protocols employ generous aggregation techniques at the >inerdomain > > boundaries. This is not in the interest of CAR, as every router in a >given > > domain may actually have different capabilities (best examples are >load and > > lower layer IDs). > > > > - Attributes exchanged by inter-domain routing protocls are typically > > relevant for domains as a whole (e.g. AS policy in BGP). It does not >seem > > that these will suffice for CAR as here we have to exchange very fine > > grained and possibly fast changing attributes of different ARs. > > > > - Either the AR or GAAR may actually not be a part of routing >information > > exchange. For example, a router in my home can be statically >configured to > > forward IP packets to some router in the Internet. However, I still >may want > > it to exchange capabilities with another AR. > > > >I'm not arguing that the *content* of the attributes currently exchanged >by >these routing protocols is different. What I am arguing is that the >*concept* >of exchanging attributes is essentially the same as capability exchange. > > > jak > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 16:09:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00953 for ; Thu, 14 Mar 2002 16:09:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07688; Thu, 14 Mar 2002 16:02:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07656 for ; Thu, 14 Mar 2002 16:02:01 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00706 for ; Thu, 14 Mar 2002 16:01:59 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EL1VI07292; Thu, 14 Mar 2002 13:01:31 -0800 (PST) Message-ID: <088d01c1cb9b$3101b750$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 12:59:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Also, not that it matters to the business at hand, but how do you like the > terminology "handoff reachability" defined as the reachability of an AR from > another AR for "MN handoffs". "Routing reachability" means reachability of > one router from another router for "IP packet routing". Since the concepts > are clearly different, different terminology may help to avoid confusion. > Again, it does not matter as to what terminology both of us like, as long as > we are in sync on the issues. > Hmm, off the top of my head, it sounds better. Or maybe "access router reachability." I think I see now where you are coming from on this. There is an aspect here that is not involved in wired, but I don't believe it is as different as, for example, handoff itself. Essentially, what the current AR offers as CARs is not much different than what is offered on a wired network as choices for a default router, at least from a security standpoint. The real difference is how the AR gets those choices. For CAR discovery, they may only be available through the host because only the host may have radio connection to the access points. On the wired network, the choices are offered directly by the routers themselves via RAs or are solicited by the host. So there is no need to consolidate them at one router. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 16:09:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00966 for ; Thu, 14 Mar 2002 16:09:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08195 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 16:09:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07688; Thu, 14 Mar 2002 16:02:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07656 for ; Thu, 14 Mar 2002 16:02:01 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00706 for ; Thu, 14 Mar 2002 16:01:59 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EL1VI07292; Thu, 14 Mar 2002 13:01:31 -0800 (PST) Message-ID: <088d01c1cb9b$3101b750$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 12:59:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Also, not that it matters to the business at hand, but how do you like the > terminology "handoff reachability" defined as the reachability of an AR from > another AR for "MN handoffs". "Routing reachability" means reachability of > one router from another router for "IP packet routing". Since the concepts > are clearly different, different terminology may help to avoid confusion. > Again, it does not matter as to what terminology both of us like, as long as > we are in sync on the issues. > Hmm, off the top of my head, it sounds better. Or maybe "access router reachability." I think I see now where you are coming from on this. There is an aspect here that is not involved in wired, but I don't believe it is as different as, for example, handoff itself. Essentially, what the current AR offers as CARs is not much different than what is offered on a wired network as choices for a default router, at least from a security standpoint. The real difference is how the AR gets those choices. For CAR discovery, they may only be available through the host because only the host may have radio connection to the access points. On the wired network, the choices are offered directly by the routers themselves via RAs or are solicited by the host. So there is no need to consolidate them at one router. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 16:18:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01216 for ; Thu, 14 Mar 2002 16:18:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08292; Thu, 14 Mar 2002 16:10:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08254 for ; Thu, 14 Mar 2002 16:10:11 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00986 for ; Thu, 14 Mar 2002 16:10:08 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id C220E600D80 for ; Thu, 14 Mar 2002 13:09:40 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id NAA12292 for ; Thu, 14 Mar 2002 13:09:47 -0800 (PST) Date: Thu, 14 Mar 2002 13:09:45 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: seamoby@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] little help Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello, I am trying to subscribe to this mailing list but the instructions in the seamoby page seem to be incorrect. The Majordomo result says that seamoby is an unknown list.... Is there any other way I can subscribe to this list? thanks! Siva _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Thu Mar 14 16:18:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01225 for ; Thu, 14 Mar 2002 16:18:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08934 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 16:18:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08292; Thu, 14 Mar 2002 16:10:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08254 for ; Thu, 14 Mar 2002 16:10:11 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00986 for ; Thu, 14 Mar 2002 16:10:08 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id C220E600D80 for ; Thu, 14 Mar 2002 13:09:40 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id NAA12292 for ; Thu, 14 Mar 2002 13:09:47 -0800 (PST) Date: Thu, 14 Mar 2002 13:09:45 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: seamoby@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] little help Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello, I am trying to subscribe to this mailing list but the instructions in the seamoby page seem to be incorrect. The Majordomo result says that seamoby is an unknown list.... Is there any other way I can subscribe to this list? thanks! Siva _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 17:11:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02645 for ; Thu, 14 Mar 2002 17:11:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12193; Thu, 14 Mar 2002 17:06:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12160 for ; Thu, 14 Mar 2002 17:06:45 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02517 for ; Thu, 14 Mar 2002 17:06:42 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2EM6iUw026798 for ; Thu, 14 Mar 2002 23:06:44 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 14 23:06:44 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 23:05:07 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB14@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Hesham Soliman (ERA)" , "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 23:06:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > Re. the comments on security, maybe we need a more > comprehensive threat > analysis such as Claude did for paging? > The requirement I did was pretty generic. => Agreed. No need for a separate doc. This is what I was hinting at when I said 'I can try'. Because this is something that will take time. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 17:11:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02654 for ; Thu, 14 Mar 2002 17:11:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12385 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 17:11:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12193; Thu, 14 Mar 2002 17:06:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12160 for ; Thu, 14 Mar 2002 17:06:45 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02517 for ; Thu, 14 Mar 2002 17:06:42 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2EM6iUw026798 for ; Thu, 14 Mar 2002 23:06:44 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 14 23:06:44 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 23:05:07 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB14@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Hesham Soliman (ERA)" , "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 23:06:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > Re. the comments on security, maybe we need a more > comprehensive threat > analysis such as Claude did for paging? > The requirement I did was pretty generic. => Agreed. No need for a separate doc. This is what I was hinting at when I said 'I can try'. Because this is something that will take time. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 17:11:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02675 for ; Thu, 14 Mar 2002 17:11:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12065; Thu, 14 Mar 2002 17:04:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12034 for ; Thu, 14 Mar 2002 17:04:12 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02480 for ; Thu, 14 Mar 2002 17:04:08 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2EM4BUw026436 for ; Thu, 14 Mar 2002 23:04:11 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 14 23:04:10 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 22:54:14 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB13@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 23:04:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Govind, > >=> The entire CAR discovery problem looks at > >this scenario, but how does IPv4/v6, Site-local > >issues come into this? > [Govind] I don't understand your question. As I explained before, > the point is just to introduce the "practical scenario" of having > ARs belonging to private domains ending up as GAARs. > => There is a big difference between: - Handover from private IPv4 to public IPv4 domains - Handover from IPv6 to IPv4 domains - Handover from one IPv6 site to another. Totally different solutions would be needed. That's why I'm puzzled about putting them together without explicitly stating the exact requirement for each case. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 17:11:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02685 for ; Thu, 14 Mar 2002 17:11:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12405 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 17:11:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12065; Thu, 14 Mar 2002 17:04:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12034 for ; Thu, 14 Mar 2002 17:04:12 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02480 for ; Thu, 14 Mar 2002 17:04:08 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2EM4BUw026436 for ; Thu, 14 Mar 2002 23:04:11 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 14 23:04:10 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 22:54:14 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB13@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 23:04:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Govind, > >=> The entire CAR discovery problem looks at > >this scenario, but how does IPv4/v6, Site-local > >issues come into this? > [Govind] I don't understand your question. As I explained before, > the point is just to introduce the "practical scenario" of having > ARs belonging to private domains ending up as GAARs. > => There is a big difference between: - Handover from private IPv4 to public IPv4 domains - Handover from IPv6 to IPv4 domains - Handover from one IPv6 site to another. Totally different solutions would be needed. That's why I'm puzzled about putting them together without explicitly stating the exact requirement for each case. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 17:23:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02923 for ; Thu, 14 Mar 2002 17:23:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12503; Thu, 14 Mar 2002 17:14:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12473 for ; Thu, 14 Mar 2002 17:14:49 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02756 for ; Thu, 14 Mar 2002 17:14:46 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2EMF0Z06940 for ; Fri, 15 Mar 2002 00:15:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 00:14:48 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 00:14:48 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 16:14:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 17:14:25 -0500 Message-ID: Thread-Topic: [Seamoby] comments on CAR Discovery Requirements Thread-Index: AcHLpDsujGfzBwYgSUSNNf++Or5lAgAAHBeQ To: , , X-OriginalArrivalTime: 14 Mar 2002 22:14:27.0313 (UTC) FILETIME=[9AF8E610:01C1CBA5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA12474 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, see inline... -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Thursday, March 14, 2002 5:04 PM To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Hi Govind, > >=> The entire CAR discovery problem looks at > >this scenario, but how does IPv4/v6, Site-local > >issues come into this? > [Govind] I don't understand your question. As I explained before, > the point is just to introduce the "practical scenario" of having > ARs belonging to private domains ending up as GAARs. > => There is a big difference between: - Handover from private IPv4 to public IPv4 domains - Handover from IPv6 to IPv4 domains - Handover from one IPv6 site to another. Totally different solutions would be needed. [DOT] ...which is not of interest during the requirements definition... That's why I'm puzzled about putting them together without explicitly stating the exact requirement for each case. [DOT] Right now, the requirement states "...CAR discovery protocols MUST be able to identify GAARs and their capabilities when moving in and out of private and site-local address spaces.". [DOT] Apart from your separation of different handover scenarios, is it possible for you that you provide said 'exact' wording for a requirement (or even so strongly suggested set of requirements) that would satifies said cases. Not only is this the constructive way of providing input to this discussion, it would also allow all of us to see how these requirements would be different from each other and different from the one that is already in the document. Basically, the best way to 'explicitly state the exact requirement' is to send it to the list rather than just asking for an 'exact' requirement. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 17:23:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02933 for ; Thu, 14 Mar 2002 17:23:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12902 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 17:23:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12503; Thu, 14 Mar 2002 17:14:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12473 for ; Thu, 14 Mar 2002 17:14:49 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02756 for ; Thu, 14 Mar 2002 17:14:46 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2EMF0Z06940 for ; Fri, 15 Mar 2002 00:15:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 00:14:48 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 00:14:48 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 16:14:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 17:14:25 -0500 Message-ID: Thread-Topic: [Seamoby] comments on CAR Discovery Requirements Thread-Index: AcHLpDsujGfzBwYgSUSNNf++Or5lAgAAHBeQ To: , , X-OriginalArrivalTime: 14 Mar 2002 22:14:27.0313 (UTC) FILETIME=[9AF8E610:01C1CBA5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA12474 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, see inline... -----Original Message----- From: ext Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Thursday, March 14, 2002 5:04 PM To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Hi Govind, > >=> The entire CAR discovery problem looks at > >this scenario, but how does IPv4/v6, Site-local > >issues come into this? > [Govind] I don't understand your question. As I explained before, > the point is just to introduce the "practical scenario" of having > ARs belonging to private domains ending up as GAARs. > => There is a big difference between: - Handover from private IPv4 to public IPv4 domains - Handover from IPv6 to IPv4 domains - Handover from one IPv6 site to another. Totally different solutions would be needed. [DOT] ...which is not of interest during the requirements definition... That's why I'm puzzled about putting them together without explicitly stating the exact requirement for each case. [DOT] Right now, the requirement states "...CAR discovery protocols MUST be able to identify GAARs and their capabilities when moving in and out of private and site-local address spaces.". [DOT] Apart from your separation of different handover scenarios, is it possible for you that you provide said 'exact' wording for a requirement (or even so strongly suggested set of requirements) that would satifies said cases. Not only is this the constructive way of providing input to this discussion, it would also allow all of us to see how these requirements would be different from each other and different from the one that is already in the document. Basically, the best way to 'explicitly state the exact requirement' is to send it to the list rather than just asking for an 'exact' requirement. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 17:44:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03392 for ; Thu, 14 Mar 2002 17:44:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13810; Thu, 14 Mar 2002 17:36:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13785 for ; Thu, 14 Mar 2002 17:36:38 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03182 for ; Thu, 14 Mar 2002 17:36:35 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EMa5I10438; Thu, 14 Mar 2002 14:36:05 -0800 (PST) Message-ID: <08f901c1cba8$675c96f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Govind Krishnamurthi'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB14@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 14:34:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hesham, > > Re. the comments on security, maybe we need a more > > comprehensive threat > > analysis such as Claude did for paging? > > The requirement I did was pretty generic. > > => Agreed. No need for a separate doc. This > is what I was hinting at when I said 'I can try'. > Because this is something that will take time. > Good, let's talk about this in the Minne-apple. Maybe we can get together a small group of volunteers to help. It should not take much time, and I agree that we don't need a separate document, but I think we need something more than we have now. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 17:44:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03402 for ; Thu, 14 Mar 2002 17:44:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14092 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 17:44:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13810; Thu, 14 Mar 2002 17:36:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13785 for ; Thu, 14 Mar 2002 17:36:38 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03182 for ; Thu, 14 Mar 2002 17:36:35 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EMa5I10438; Thu, 14 Mar 2002 14:36:05 -0800 (PST) Message-ID: <08f901c1cba8$675c96f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Govind Krishnamurthi'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB14@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 14:34:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hesham, > > Re. the comments on security, maybe we need a more > > comprehensive threat > > analysis such as Claude did for paging? > > The requirement I did was pretty generic. > > => Agreed. No need for a separate doc. This > is what I was hinting at when I said 'I can try'. > Because this is something that will take time. > Good, let's talk about this in the Minne-apple. Maybe we can get together a small group of volunteers to help. It should not take much time, and I agree that we don't need a separate document, but I think we need something more than we have now. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 18:11:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03958 for ; Thu, 14 Mar 2002 18:11:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15294; Thu, 14 Mar 2002 18:01:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15253 for ; Thu, 14 Mar 2002 18:01:07 -0500 (EST) Received: from hotmail.com (f175.law7.hotmail.com [216.33.237.175]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03741 for ; Thu, 14 Mar 2002 18:01:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 15:00:37 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 23:00:37 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 23:00:37 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 23:00:37.0543 (UTC) FILETIME=[0E287370:01C1CBAC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Rather than starting from scratch again in Minneapolis, may I propose that we start from the following baseline text for security requirements. I think this text very clearly and explicitly brings out the security issues involved. If any additional statements are needed we can fill them in. Sorry to repeat this, but I did not see any reference to earlier discussion on this text in Hesham's email. "Solution to CAR discovery MUST address the security concerns involved in the various aspects such as GAAR discovery, capability exchange and CAR selection. In particular, a) The solution MUST provide means for an AR to to verify that another AR claiming to be its GAAR is genuine. In other words, the other AR is indeed a GAAR and it is an authentic router. The authenticity of a router MAY mean that it is authorized to act as an access router by the jurisdiction of the environment (operator network, organizatoinal LAN, home network etc.) that the router resides in. b)It MUST provide means for secure capability exchange between an AR and its GAAR. c)It MUST provide secure means for the expression of MN requirements to CAR selection algorithms." Regards, Hemant >From: "James Kempf" >To: "Hesham Soliman \(ERA\)" , >"'Govind Krishnamurthi'" , >Subject: Re: [Seamoby] comments on CAR Discovery Requirements >Date: Thu, 14 Mar 2002 14:34:29 -0800 > >Hesham, > > > > Re. the comments on security, maybe we need a more > > > comprehensive threat > > > analysis such as Claude did for paging? > > > The requirement I did was pretty generic. > > > > => Agreed. No need for a separate doc. This > > is what I was hinting at when I said 'I can try'. > > Because this is something that will take time. > > > >Good, let's talk about this in the Minne-apple. >Maybe we can get together a small group >of volunteers to help. It should >not take much time, and I agree that we >don't need a separate document, but >I think we need something more than >we have now. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 18:11:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03969 for ; Thu, 14 Mar 2002 18:11:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15736 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 18:11:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15294; Thu, 14 Mar 2002 18:01:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15253 for ; Thu, 14 Mar 2002 18:01:07 -0500 (EST) Received: from hotmail.com (f175.law7.hotmail.com [216.33.237.175]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03741 for ; Thu, 14 Mar 2002 18:01:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 15:00:37 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 23:00:37 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 23:00:37 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 23:00:37.0543 (UTC) FILETIME=[0E287370:01C1CBAC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Rather than starting from scratch again in Minneapolis, may I propose that we start from the following baseline text for security requirements. I think this text very clearly and explicitly brings out the security issues involved. If any additional statements are needed we can fill them in. Sorry to repeat this, but I did not see any reference to earlier discussion on this text in Hesham's email. "Solution to CAR discovery MUST address the security concerns involved in the various aspects such as GAAR discovery, capability exchange and CAR selection. In particular, a) The solution MUST provide means for an AR to to verify that another AR claiming to be its GAAR is genuine. In other words, the other AR is indeed a GAAR and it is an authentic router. The authenticity of a router MAY mean that it is authorized to act as an access router by the jurisdiction of the environment (operator network, organizatoinal LAN, home network etc.) that the router resides in. b)It MUST provide means for secure capability exchange between an AR and its GAAR. c)It MUST provide secure means for the expression of MN requirements to CAR selection algorithms." Regards, Hemant >From: "James Kempf" >To: "Hesham Soliman \(ERA\)" , >"'Govind Krishnamurthi'" , >Subject: Re: [Seamoby] comments on CAR Discovery Requirements >Date: Thu, 14 Mar 2002 14:34:29 -0800 > >Hesham, > > > > Re. the comments on security, maybe we need a more > > > comprehensive threat > > > analysis such as Claude did for paging? > > > The requirement I did was pretty generic. > > > > => Agreed. No need for a separate doc. This > > is what I was hinting at when I said 'I can try'. > > Because this is something that will take time. > > > >Good, let's talk about this in the Minne-apple. >Maybe we can get together a small group >of volunteers to help. It should >not take much time, and I agree that we >don't need a separate document, but >I think we need something more than >we have now. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 18:26:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04309 for ; Thu, 14 Mar 2002 18:26:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15593; Thu, 14 Mar 2002 18:08:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15566 for ; Thu, 14 Mar 2002 18:08:48 -0500 (EST) Received: from hotmail.com (f66.law9.hotmail.com [64.4.9.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03877 for ; Thu, 14 Mar 2002 18:08:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 15:08:18 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 23:08:17 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 18:08:17 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 23:08:18.0146 (UTC) FILETIME=[20B2E420:01C1CBAD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Please take a look at some of the requirements which came in this afternoon (from Hemant and James). Please see whether they satisfy all the security issues. I look forward to seeing your comments on these. I also agree with you about not needing a separate document. Best regards, Govind. > > Re. the comments on security, maybe we need a more > > comprehensive threat > > analysis such as Claude did for paging? > > The requirement I did was pretty generic. > >=> Agreed. No need for a separate doc. This >is what I was hinting at when I said 'I can try'. >Because this is something that will take time. > >Hesham _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 18:26:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04320 for ; Thu, 14 Mar 2002 18:26:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA16337 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 18:26:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15593; Thu, 14 Mar 2002 18:08:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15566 for ; Thu, 14 Mar 2002 18:08:48 -0500 (EST) Received: from hotmail.com (f66.law9.hotmail.com [64.4.9.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03877 for ; Thu, 14 Mar 2002 18:08:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 15:08:18 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 23:08:17 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 18:08:17 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 23:08:18.0146 (UTC) FILETIME=[20B2E420:01C1CBAD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Please take a look at some of the requirements which came in this afternoon (from Hemant and James). Please see whether they satisfy all the security issues. I look forward to seeing your comments on these. I also agree with you about not needing a separate document. Best regards, Govind. > > Re. the comments on security, maybe we need a more > > comprehensive threat > > analysis such as Claude did for paging? > > The requirement I did was pretty generic. > >=> Agreed. No need for a separate doc. This >is what I was hinting at when I said 'I can try'. >Because this is something that will take time. > >Hesham _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 18:27:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04369 for ; Thu, 14 Mar 2002 18:27:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15396; Thu, 14 Mar 2002 18:04:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15366 for ; Thu, 14 Mar 2002 18:04:21 -0500 (EST) Received: from hotmail.com (f3.law9.hotmail.com [64.4.9.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03799 for ; Thu, 14 Mar 2002 18:04:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 15:03:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 23:03:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 18:03:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 23:03:42.0721 (UTC) FILETIME=[7C885F10:01C1CBAC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham, >=> There is a big difference between: > >- Handover from private IPv4 to public IPv4 domains >- Handover from IPv6 to IPv4 domains >- Handover from one IPv6 site to another. [Govind] I agree with this but from a CAR discovery requirement point of view isn't it just the ability of these happening which is important? Anyways, if you will supply the requisite wording that you deem necessary I will be happy to add it if there is WG concensus. > >Totally different solutions would be needed. [Govind] Again totally different solutions being needed is again a statement we don't need to go into now, as this would take us into solution space. >That's why I'm puzzled about putting them together >without explicitly stating the exact requirement >for each case. Best regards, Govind. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 18:27:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04378 for ; Thu, 14 Mar 2002 18:27:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA16381 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 18:27:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15396; Thu, 14 Mar 2002 18:04:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15366 for ; Thu, 14 Mar 2002 18:04:21 -0500 (EST) Received: from hotmail.com (f3.law9.hotmail.com [64.4.9.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03799 for ; Thu, 14 Mar 2002 18:04:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 15:03:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 14 Mar 2002 23:03:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 18:03:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Mar 2002 23:03:42.0721 (UTC) FILETIME=[7C885F10:01C1CBAC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham, >=> There is a big difference between: > >- Handover from private IPv4 to public IPv4 domains >- Handover from IPv6 to IPv4 domains >- Handover from one IPv6 site to another. [Govind] I agree with this but from a CAR discovery requirement point of view isn't it just the ability of these happening which is important? Anyways, if you will supply the requisite wording that you deem necessary I will be happy to add it if there is WG concensus. > >Totally different solutions would be needed. [Govind] Again totally different solutions being needed is again a statement we don't need to go into now, as this would take us into solution space. >That's why I'm puzzled about putting them together >without explicitly stating the exact requirement >for each case. Best regards, Govind. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 18:51:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05050 for ; Thu, 14 Mar 2002 18:51:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17301; Thu, 14 Mar 2002 18:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17270 for ; Thu, 14 Mar 2002 18:43:37 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04794 for ; Thu, 14 Mar 2002 18:43:30 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2ENh0I12875; Thu, 14 Mar 2002 15:43:00 -0800 (PST) Message-ID: <098301c1cbb1$bfe30260$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 15:41:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I think it would be useful to have a threat analysis. The threat analysis that was done for paging was extremely useful in uncovering necessary security requirements. What you have listed below are fairly high level goals. A more detailed threat analysis with these goals in mind might turn up some more specific requiremnts. Hesham has indicted some interest in participating, perhaps you would like to as well? jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Thursday, March 14, 2002 11:00 PM Subject: Re: [Seamoby] comments on CAR Discovery Requirements > Hi James: > > Rather than starting from scratch again in Minneapolis, may I propose that > we start from the following baseline text for security requirements. I think > this text very clearly and explicitly brings out the security issues > involved. If any additional statements are needed we can fill them in. Sorry > to repeat this, but I did not see any reference to earlier discussion on > this text in Hesham's email. > > "Solution to CAR discovery MUST address the security concerns involved in > the various aspects such as GAAR discovery, capability exchange and CAR > selection. In particular, > > a) The solution MUST provide means for an AR to to verify that another AR > claiming to be its GAAR is genuine. In other words, the other AR is indeed a > GAAR and it is an authentic router. The authenticity of a router MAY mean > that it is authorized to act as an access router by the jurisdiction of the > environment (operator network, organizatoinal LAN, home network etc.) that > the router resides in. > > b)It MUST provide means for secure capability exchange between an AR and its > GAAR. > > c)It MUST provide secure means for the expression of MN requirements to CAR > selection algorithms." > > Regards, > Hemant > > >From: "James Kempf" > >To: "Hesham Soliman \(ERA\)" , > >"'Govind Krishnamurthi'" , > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > >Hesham, > > > > > > Re. the comments on security, maybe we need a more > > > > comprehensive threat > > > > analysis such as Claude did for paging? > > > > The requirement I did was pretty generic. > > > > > > => Agreed. No need for a separate doc. This > > > is what I was hinting at when I said 'I can try'. > > > Because this is something that will take time. > > > > > > >Good, let's talk about this in the Minne-apple. > >Maybe we can get together a small group > >of volunteers to help. It should > >not take much time, and I agree that we > >don't need a separate document, but > >I think we need something more than > >we have now. > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 18:51:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05059 for ; Thu, 14 Mar 2002 18:51:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17528 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 18:51:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17301; Thu, 14 Mar 2002 18:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17270 for ; Thu, 14 Mar 2002 18:43:37 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04794 for ; Thu, 14 Mar 2002 18:43:30 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2ENh0I12875; Thu, 14 Mar 2002 15:43:00 -0800 (PST) Message-ID: <098301c1cbb1$bfe30260$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Thu, 14 Mar 2002 15:41:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I think it would be useful to have a threat analysis. The threat analysis that was done for paging was extremely useful in uncovering necessary security requirements. What you have listed below are fairly high level goals. A more detailed threat analysis with these goals in mind might turn up some more specific requiremnts. Hesham has indicted some interest in participating, perhaps you would like to as well? jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Thursday, March 14, 2002 11:00 PM Subject: Re: [Seamoby] comments on CAR Discovery Requirements > Hi James: > > Rather than starting from scratch again in Minneapolis, may I propose that > we start from the following baseline text for security requirements. I think > this text very clearly and explicitly brings out the security issues > involved. If any additional statements are needed we can fill them in. Sorry > to repeat this, but I did not see any reference to earlier discussion on > this text in Hesham's email. > > "Solution to CAR discovery MUST address the security concerns involved in > the various aspects such as GAAR discovery, capability exchange and CAR > selection. In particular, > > a) The solution MUST provide means for an AR to to verify that another AR > claiming to be its GAAR is genuine. In other words, the other AR is indeed a > GAAR and it is an authentic router. The authenticity of a router MAY mean > that it is authorized to act as an access router by the jurisdiction of the > environment (operator network, organizatoinal LAN, home network etc.) that > the router resides in. > > b)It MUST provide means for secure capability exchange between an AR and its > GAAR. > > c)It MUST provide secure means for the expression of MN requirements to CAR > selection algorithms." > > Regards, > Hemant > > >From: "James Kempf" > >To: "Hesham Soliman \(ERA\)" , > >"'Govind Krishnamurthi'" , > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > >Hesham, > > > > > > Re. the comments on security, maybe we need a more > > > > comprehensive threat > > > > analysis such as Claude did for paging? > > > > The requirement I did was pretty generic. > > > > > > => Agreed. No need for a separate doc. This > > > is what I was hinting at when I said 'I can try'. > > > Because this is something that will take time. > > > > > > >Good, let's talk about this in the Minne-apple. > >Maybe we can get together a small group > >of volunteers to help. It should > >not take much time, and I agree that we > >don't need a separate document, but > >I think we need something more than > >we have now. > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 14 22:02:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09842 for ; Thu, 14 Mar 2002 22:02:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29806; Thu, 14 Mar 2002 21:54:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29775 for ; Thu, 14 Mar 2002 21:54:56 -0500 (EST) Received: from hotmail.com (oe43.law4.hotmail.com [216.33.148.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09796 for ; Thu, 14 Mar 2002 21:54:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 18:54:24 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: <025501c1cac8$95738390$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 21:59:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 15 Mar 2002 02:54:24.0890 (UTC) FILETIME=[B71BBDA0:01C1CBCC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, I'd appreciate if you provide pointers to some documents describing those policies. I am just eager to read them to help my understanding of those security policies. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: Sent: Wednesday, March 13, 2002 11:52 AM Subject: [Seamoby] Security Requirments for CAR Discovery > The current requirements draft is a little thin on security. Here's a > proposal: > > The Seamoby CAR discovery solution MUST provide proper security. > Security on CAR information and capabilities distribution MUST > conform > and interoperate with existing IETF security policies and protocols > on > the security of routing information distribution. Security on > communication > of MN preferences to ARs MUST conform and interoperate with existing > IETF security and AAA policies and protocols for host security, > where > applicable. > > Comments? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 14 22:02:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09856 for ; Thu, 14 Mar 2002 22:02:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA00630 for seamoby-archive@odin.ietf.org; Thu, 14 Mar 2002 22:02:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29806; Thu, 14 Mar 2002 21:54:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29775 for ; Thu, 14 Mar 2002 21:54:56 -0500 (EST) Received: from hotmail.com (oe43.law4.hotmail.com [216.33.148.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09796 for ; Thu, 14 Mar 2002 21:54:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Mar 2002 18:54:24 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: <025501c1cac8$95738390$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Security Requirments for CAR Discovery Date: Thu, 14 Mar 2002 21:59:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 15 Mar 2002 02:54:24.0890 (UTC) FILETIME=[B71BBDA0:01C1CBCC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, I'd appreciate if you provide pointers to some documents describing those policies. I am just eager to read them to help my understanding of those security policies. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: Sent: Wednesday, March 13, 2002 11:52 AM Subject: [Seamoby] Security Requirments for CAR Discovery > The current requirements draft is a little thin on security. Here's a > proposal: > > The Seamoby CAR discovery solution MUST provide proper security. > Security on CAR information and capabilities distribution MUST > conform > and interoperate with existing IETF security policies and protocols > on > the security of routing information distribution. Security on > communication > of MN preferences to ARs MUST conform and interoperate with existing > IETF security and AAA policies and protocols for host security, > where > applicable. > > Comments? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 15 09:50:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00583 for ; Fri, 15 Mar 2002 09:50:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26071; Fri, 15 Mar 2002 09:33:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25975 for ; Fri, 15 Mar 2002 09:33:26 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29988 for ; Fri, 15 Mar 2002 09:33:22 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FEZdx10713 for ; Fri, 15 Mar 2002 08:35:39 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 08:33:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 08:32:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Fri, 15 Mar 2002 09:32:47 -0500 Message-ID: Thread-Topic: [Seamoby] comments on CAR Discovery Requirements Thread-Index: AcHLshwfw7dsSBhjTSyL9HJOVzoHLQAej4eg To: , , X-OriginalArrivalTime: 15 Mar 2002 14:32:47.0822 (UTC) FILETIME=[4733BEE0:01C1CC2E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA25976 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, March 14, 2002 6:41 PM To: Hemant Chaskar; seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Hemant, I think it would be useful to have a threat analysis. The threat analysis that was done for paging was extremely useful in uncovering necessary security requirements. What you have listed below are fairly high level goals. A more detailed threat analysis with these goals in mind might turn up some more specific requiremnts. [DOT]frankly speaking, I have my doubts that the output would be more than now. What we are targetting right now is the clear and complete statement of security issues, and we are having progress in this. Plainly raising concerns without providing input is not what I see as a threat analysis. I don't see that any new process, called threat analysis or whatever, would bring more than the process now. If people are not willing to provide proper input (and that's what we need) now, why should they in a newly created threat analysis. It simply creates a new process, and therefore new overhead without guaranteeing any increased output. Hesham has indicted some interest in participating, [DOT] Frankly, Hesham has been indicating his interest in participating for quite a while, and several people, including myself, strongly invited him to do so. Apart from raising concerns, other input has not been provided, only the promise to do so. If we want to have progress with CAR discovery, we have to do the work rather than promising to do the job. ...perhaps you would like to as well? [DOT] That's exactly the difference. Hemant has been participating in providing input in forms of requiremens for quite a while, so there is no need to invite him for participation. If we have to announce our interest again in providing input, I'll do so, too. Regards, Dirk ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Thursday, March 14, 2002 11:00 PM Subject: Re: [Seamoby] comments on CAR Discovery Requirements > Hi James: > > Rather than starting from scratch again in Minneapolis, may I propose that > we start from the following baseline text for security requirements. I think > this text very clearly and explicitly brings out the security issues > involved. If any additional statements are needed we can fill them in. Sorry > to repeat this, but I did not see any reference to earlier discussion on > this text in Hesham's email. > > "Solution to CAR discovery MUST address the security concerns involved in > the various aspects such as GAAR discovery, capability exchange and CAR > selection. In particular, > > a) The solution MUST provide means for an AR to to verify that another AR > claiming to be its GAAR is genuine. In other words, the other AR is indeed a > GAAR and it is an authentic router. The authenticity of a router MAY mean > that it is authorized to act as an access router by the jurisdiction of the > environment (operator network, organizatoinal LAN, home network etc.) that > the router resides in. > > b)It MUST provide means for secure capability exchange between an AR and its > GAAR. > > c)It MUST provide secure means for the expression of MN requirements to CAR > selection algorithms." > > Regards, > Hemant > > >From: "James Kempf" > >To: "Hesham Soliman \(ERA\)" , > >"'Govind Krishnamurthi'" , > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > >Hesham, > > > > > > Re. the comments on security, maybe we need a more > > > > comprehensive threat > > > > analysis such as Claude did for paging? > > > > The requirement I did was pretty generic. > > > > > > => Agreed. No need for a separate doc. This > > > is what I was hinting at when I said 'I can try'. > > > Because this is something that will take time. > > > > > > >Good, let's talk about this in the Minne-apple. > >Maybe we can get together a small group > >of volunteers to help. It should > >not take much time, and I agree that we > >don't need a separate document, but > >I think we need something more than > >we have now. > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 15 10:41:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00591 for ; Fri, 15 Mar 2002 09:50:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27353 for seamoby-archive@odin.ietf.org; Fri, 15 Mar 2002 09:50:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26071; Fri, 15 Mar 2002 09:33:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25975 for ; Fri, 15 Mar 2002 09:33:26 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29988 for ; Fri, 15 Mar 2002 09:33:22 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FEZdx10713 for ; Fri, 15 Mar 2002 08:35:39 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 08:33:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 08:32:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Fri, 15 Mar 2002 09:32:47 -0500 Message-ID: Thread-Topic: [Seamoby] comments on CAR Discovery Requirements Thread-Index: AcHLshwfw7dsSBhjTSyL9HJOVzoHLQAej4eg To: , , X-OriginalArrivalTime: 15 Mar 2002 14:32:47.0822 (UTC) FILETIME=[4733BEE0:01C1CC2E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA25976 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, March 14, 2002 6:41 PM To: Hemant Chaskar; seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Hemant, I think it would be useful to have a threat analysis. The threat analysis that was done for paging was extremely useful in uncovering necessary security requirements. What you have listed below are fairly high level goals. A more detailed threat analysis with these goals in mind might turn up some more specific requiremnts. [DOT]frankly speaking, I have my doubts that the output would be more than now. What we are targetting right now is the clear and complete statement of security issues, and we are having progress in this. Plainly raising concerns without providing input is not what I see as a threat analysis. I don't see that any new process, called threat analysis or whatever, would bring more than the process now. If people are not willing to provide proper input (and that's what we need) now, why should they in a newly created threat analysis. It simply creates a new process, and therefore new overhead without guaranteeing any increased output. Hesham has indicted some interest in participating, [DOT] Frankly, Hesham has been indicating his interest in participating for quite a while, and several people, including myself, strongly invited him to do so. Apart from raising concerns, other input has not been provided, only the promise to do so. If we want to have progress with CAR discovery, we have to do the work rather than promising to do the job. ...perhaps you would like to as well? [DOT] That's exactly the difference. Hemant has been participating in providing input in forms of requiremens for quite a while, so there is no need to invite him for participation. If we have to announce our interest again in providing input, I'll do so, too. Regards, Dirk ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Thursday, March 14, 2002 11:00 PM Subject: Re: [Seamoby] comments on CAR Discovery Requirements > Hi James: > > Rather than starting from scratch again in Minneapolis, may I propose that > we start from the following baseline text for security requirements. I think > this text very clearly and explicitly brings out the security issues > involved. If any additional statements are needed we can fill them in. Sorry > to repeat this, but I did not see any reference to earlier discussion on > this text in Hesham's email. > > "Solution to CAR discovery MUST address the security concerns involved in > the various aspects such as GAAR discovery, capability exchange and CAR > selection. In particular, > > a) The solution MUST provide means for an AR to to verify that another AR > claiming to be its GAAR is genuine. In other words, the other AR is indeed a > GAAR and it is an authentic router. The authenticity of a router MAY mean > that it is authorized to act as an access router by the jurisdiction of the > environment (operator network, organizatoinal LAN, home network etc.) that > the router resides in. > > b)It MUST provide means for secure capability exchange between an AR and its > GAAR. > > c)It MUST provide secure means for the expression of MN requirements to CAR > selection algorithms." > > Regards, > Hemant > > >From: "James Kempf" > >To: "Hesham Soliman \(ERA\)" , > >"'Govind Krishnamurthi'" , > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > >Hesham, > > > > > > Re. the comments on security, maybe we need a more > > > > comprehensive threat > > > > analysis such as Claude did for paging? > > > > The requirement I did was pretty generic. > > > > > > => Agreed. No need for a separate doc. This > > > is what I was hinting at when I said 'I can try'. > > > Because this is something that will take time. > > > > > > >Good, let's talk about this in the Minne-apple. > >Maybe we can get together a small group > >of volunteers to help. It should > >not take much time, and I agree that we > >don't need a separate document, but > >I think we need something more than > >we have now. > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 15 14:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07788 for ; Fri, 15 Mar 2002 14:26:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19531; Fri, 15 Mar 2002 14:20:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19505 for ; Fri, 15 Mar 2002 14:19:59 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07597 for ; Fri, 15 Mar 2002 14:19:56 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2FJJuUw004563 for ; Fri, 15 Mar 2002 20:19:57 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 15 20:19:56 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 20:20:15 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB2B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , kempf@docomolabs-usa.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Fri, 15 Mar 2002 20:19:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > [DOT] Frankly, Hesham has been indicating his interest in > participating > for quite a while, and several people, including myself, > strongly invited > him to do so. Apart from raising concerns, other input has not been > provided, only the promise to do so. If we want to have > progress with > CAR discovery, we have to do the work rather than promising > to do the > job. => You need to understand the difference between making comments to improve the document and putting those comments in the document. I haven't had time to actively participate, that doesn't make the comments invalid. I don't have to send text (although I'd like to) to prove to you that the comments are valid. Simply saying' well if you have comments send text or be forever silent' is complete nonsense. Whatever happened to trying to understand and discuss comments on the mailing list! Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 15 14:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07797 for ; Fri, 15 Mar 2002 14:26:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19887 for seamoby-archive@odin.ietf.org; Fri, 15 Mar 2002 14:26:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19531; Fri, 15 Mar 2002 14:20:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19505 for ; Fri, 15 Mar 2002 14:19:59 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07597 for ; Fri, 15 Mar 2002 14:19:56 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2FJJuUw004563 for ; Fri, 15 Mar 2002 20:19:57 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 15 20:19:56 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 20:20:15 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB2B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , kempf@docomolabs-usa.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Fri, 15 Mar 2002 20:19:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > [DOT] Frankly, Hesham has been indicating his interest in > participating > for quite a while, and several people, including myself, > strongly invited > him to do so. Apart from raising concerns, other input has not been > provided, only the promise to do so. If we want to have > progress with > CAR discovery, we have to do the work rather than promising > to do the > job. => You need to understand the difference between making comments to improve the document and putting those comments in the document. I haven't had time to actively participate, that doesn't make the comments invalid. I don't have to send text (although I'd like to) to prove to you that the comments are valid. Simply saying' well if you have comments send text or be forever silent' is complete nonsense. Whatever happened to trying to understand and discuss comments on the mailing list! Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 15 14:55:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08489 for ; Fri, 15 Mar 2002 14:55:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21776 for seamoby-archive@odin.ietf.org; Fri, 15 Mar 2002 14:55:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21501; Fri, 15 Mar 2002 14:49:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21471 for ; Fri, 15 Mar 2002 14:49:35 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08297 for ; Fri, 15 Mar 2002 14:49:31 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FJmrI09256; Fri, 15 Mar 2002 11:48:53 -0800 (PST) Message-ID: <018d01c1cc5a$367ba3c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , , , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB2B@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Fri, 15 Mar 2002 11:47:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hesham, > => You need to understand the difference between > making comments to improve the document and putting > those comments in the document. I haven't had > time to actively participate, that doesn't make > the comments invalid. I don't have to send text > (although I'd like to) to prove to you that the > comments are valid. Simply saying' well if you have > comments send text or be forever silent' is > complete nonsense. Whatever happened to trying > to understand and discuss comments on the mailing > list! One of the problems we've been having in Seamoby is that people seem quite willing to contribute criticism or their opinion, but when it comes time to contribute some solid text, they disappear or plead lack of time. This does nothing to advance the spec, because then the draft editor has to guess what the complainer's intent is, leading to further complaints that the guess was incorrect, etc. It is much more efficient to have those people who have some problem with the spec to come up with text for it expressing what they have in mind. You have expressed a concern (which I think is quite valid) about the lack of close examination in the security requirements for CAR discovery. It would be extremely helpful if you, Hemant, and Govind could sit down for an hour at IETF and talk about the issue, maybe come up with a slide or two for Govind's presentation. If there is not enough time at IETF, then perhaps you can continue the discussion afterwards for a couple weeks. Does that sound doable? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 15 15:41:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08481 for ; Fri, 15 Mar 2002 14:55:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21501; Fri, 15 Mar 2002 14:49:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21471 for ; Fri, 15 Mar 2002 14:49:35 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08297 for ; Fri, 15 Mar 2002 14:49:31 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FJmrI09256; Fri, 15 Mar 2002 11:48:53 -0800 (PST) Message-ID: <018d01c1cc5a$367ba3c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , , , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB2B@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Fri, 15 Mar 2002 11:47:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hesham, > => You need to understand the difference between > making comments to improve the document and putting > those comments in the document. I haven't had > time to actively participate, that doesn't make > the comments invalid. I don't have to send text > (although I'd like to) to prove to you that the > comments are valid. Simply saying' well if you have > comments send text or be forever silent' is > complete nonsense. Whatever happened to trying > to understand and discuss comments on the mailing > list! One of the problems we've been having in Seamoby is that people seem quite willing to contribute criticism or their opinion, but when it comes time to contribute some solid text, they disappear or plead lack of time. This does nothing to advance the spec, because then the draft editor has to guess what the complainer's intent is, leading to further complaints that the guess was incorrect, etc. It is much more efficient to have those people who have some problem with the spec to come up with text for it expressing what they have in mind. You have expressed a concern (which I think is quite valid) about the lack of close examination in the security requirements for CAR discovery. It would be extremely helpful if you, Hemant, and Govind could sit down for an hour at IETF and talk about the issue, maybe come up with a slide or two for Govind's presentation. If there is not enough time at IETF, then perhaps you can continue the discussion afterwards for a couple weeks. Does that sound doable? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 15 18:07:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13188 for ; Fri, 15 Mar 2002 18:07:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02296; Fri, 15 Mar 2002 17:58:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02268 for ; Fri, 15 Mar 2002 17:58:21 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12966 for ; Fri, 15 Mar 2002 17:58:18 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA13909 for ; Fri, 15 Mar 2002 15:58:21 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA22860 for ; Fri, 15 Mar 2002 15:46:25 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 15 Mar 2002 16:58:20 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FFA7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Dirk.Trossen@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Date: Fri, 15 Mar 2002 16:57:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Dirk, I think it is sufficient to point out that the CAR disc protocol needs to provide means of signaling the necessary input for the selection process, including network capabilities and MN's preferences (profile). My point was that: Since the selection process is either done by MN or oldAR in the old network, no external signaling is necessary, because they are both aware of MN's preferences, unless CAR is happening at a different network entity at the old network. And I don't think CAR is performed at the target network either, do you? Regards, Madjid -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Thursday, March 14, 2002 10:51 AM To: Madjid Nakhjiri; seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Hi Madjid, I'm not saying that MN's requirements have to be spelled out again. 'Means to express the requirements' includes some mechanisms to define these requirements somehow and the means that they can be used as an input to the CAR discovery protocol. It is certainly possible that the first part is done by currently existing protocols, but the requirement merely states that the means are mandatory for the CAR discovery solution, otherwise it cannot fulfil its task. Maybe, here's some confusion in general sometimes that the requirements always mandate NEW functionality. This is not the case. The requirements merely describe the functionality that is needed to do the job. Whether or not this will be done in the final proposal by existing protocols, modifications to existing ones, or new mechanisms is out of the scope of the requirements. Regards, Dirk -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Thursday, March 14, 2002 10:59 AM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Sorry for the late response, isn't MN's requirement spelled out in MN's user profile or SLA or something else recorded in the policy server of the MN's network? why does the MN has to express them again. if the new network needs it (I don't know why it would in a CAR selection), then it can get it from old network, if the old network needs, it gets it from policy server. I think what this should concentrate on is: CAR discovery protocol MUST provide means for signaling parameters needed for a TAR selection mechanims (regardless of whether it is done at MN or at AR). I know that the selection process is out of scope, but providing input for it should be in scope. signaling MN's requirements for service is a different issue. Regards, Madjid "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 15 18:07:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13198 for ; Fri, 15 Mar 2002 18:07:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03028 for seamoby-archive@odin.ietf.org; Fri, 15 Mar 2002 18:07:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02296; Fri, 15 Mar 2002 17:58:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02268 for ; Fri, 15 Mar 2002 17:58:21 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12966 for ; Fri, 15 Mar 2002 17:58:18 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA13909 for ; Fri, 15 Mar 2002 15:58:21 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA22860 for ; Fri, 15 Mar 2002 15:46:25 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 15 Mar 2002 16:58:20 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FFA7@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Dirk.Trossen@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Date: Fri, 15 Mar 2002 16:57:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Dirk, I think it is sufficient to point out that the CAR disc protocol needs to provide means of signaling the necessary input for the selection process, including network capabilities and MN's preferences (profile). My point was that: Since the selection process is either done by MN or oldAR in the old network, no external signaling is necessary, because they are both aware of MN's preferences, unless CAR is happening at a different network entity at the old network. And I don't think CAR is performed at the target network either, do you? Regards, Madjid -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: Thursday, March 14, 2002 10:51 AM To: Madjid Nakhjiri; seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Hi Madjid, I'm not saying that MN's requirements have to be spelled out again. 'Means to express the requirements' includes some mechanisms to define these requirements somehow and the means that they can be used as an input to the CAR discovery protocol. It is certainly possible that the first part is done by currently existing protocols, but the requirement merely states that the means are mandatory for the CAR discovery solution, otherwise it cannot fulfil its task. Maybe, here's some confusion in general sometimes that the requirements always mandate NEW functionality. This is not the case. The requirements merely describe the functionality that is needed to do the job. Whether or not this will be done in the final proposal by existing protocols, modifications to existing ones, or new mechanisms is out of the scope of the requirements. Regards, Dirk -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Thursday, March 14, 2002 10:59 AM To: Trossen Dirk (NRC/Boston); seamoby@ietf.org Subject: RE: [Seamoby] CAR Discovery Requirements Sorry for the late response, isn't MN's requirement spelled out in MN's user profile or SLA or something else recorded in the policy server of the MN's network? why does the MN has to express them again. if the new network needs it (I don't know why it would in a CAR selection), then it can get it from old network, if the old network needs, it gets it from policy server. I think what this should concentrate on is: CAR discovery protocol MUST provide means for signaling parameters needed for a TAR selection mechanims (regardless of whether it is done at MN or at AR). I know that the selection process is out of scope, but providing input for it should be in scope. signaling MN's requirements for service is a different issue. Regards, Madjid "3.xx Providing MN's requirement for Determination of CARs The fundamental task of CAR discovery is to determine candidate access routers (from the set of GAARs) that meet MN's requirements, if known at the time of handoff. A CAR discovery protocol MUST determine a set of CARs that meet MN's requirements. For this, a CAR discovery protocol MUST provide means for the MN to express these requirements." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 15 18:13:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13416 for ; Fri, 15 Mar 2002 18:13:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03159; Fri, 15 Mar 2002 18:08:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03134 for ; Fri, 15 Mar 2002 18:08:36 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13224 for ; Fri, 15 Mar 2002 18:08:32 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2FN8YR27848 for ; Sat, 16 Mar 2002 00:08:34 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Mar 16 00:08:34 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 16 Mar 2002 00:08:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB3F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Dirk.Trossen@nokia.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 00:08:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > One of the problems we've been having in Seamoby > is that people seem quite willing to contribute criticism > or their opinion, but when it comes time to contribute > some solid text, they disappear or plead lack of time. > This does nothing to advance the spec, because then > the draft editor has to guess what the complainer's > intent is, leading to further complaints that the guess > was incorrect, etc. => There is no need to guess. Every draft receives comments from people, they are discussed on the mailing list and the editor(s) then add them as they see fit... It is much more efficient to have > those people who have some problem with the > spec to come up with text for it expressing > what they have in mind. => Of course, but editors should be open to comments. I shouldn't have to rewrite the draft (which is what happens when there is a structural comment) to make sure my comments are acceptable. If people agree or disagree with the comments, then we can move forward. If the comments are not clear at all, I'm more than happy to clarify. But an answer of 'OK if you see a problem send text', is just...not helpful. Questions like: is there any agreement on the comments? Do they make any sense at all ?? ...etc should be addressed, not just 'send text'. Can't we spend this time discussing technical comments?!!! Every time I comment on this draft I get procedural answers from the authors! Sigh > > You have expressed a concern (which I think is quite > valid) about the lack of close examination in the > security requirements for CAR discovery. It would > be extremely helpful if you, Hemant, and Govind > could sit down for an hour at IETF and talk > about the issue, maybe come up with a slide > or two for Govind's presentation. If there is > not enough time at IETF, then perhaps you > can continue the discussion afterwards for > a couple weeks. > > Does that sound doable? => Yes. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 15 18:13:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13425 for ; Fri, 15 Mar 2002 18:13:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03490 for seamoby-archive@odin.ietf.org; Fri, 15 Mar 2002 18:14:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03159; Fri, 15 Mar 2002 18:08:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03134 for ; Fri, 15 Mar 2002 18:08:36 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13224 for ; Fri, 15 Mar 2002 18:08:32 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2FN8YR27848 for ; Sat, 16 Mar 2002 00:08:34 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Mar 16 00:08:34 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 16 Mar 2002 00:08:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB3F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Dirk.Trossen@nokia.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 00:08:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > One of the problems we've been having in Seamoby > is that people seem quite willing to contribute criticism > or their opinion, but when it comes time to contribute > some solid text, they disappear or plead lack of time. > This does nothing to advance the spec, because then > the draft editor has to guess what the complainer's > intent is, leading to further complaints that the guess > was incorrect, etc. => There is no need to guess. Every draft receives comments from people, they are discussed on the mailing list and the editor(s) then add them as they see fit... It is much more efficient to have > those people who have some problem with the > spec to come up with text for it expressing > what they have in mind. => Of course, but editors should be open to comments. I shouldn't have to rewrite the draft (which is what happens when there is a structural comment) to make sure my comments are acceptable. If people agree or disagree with the comments, then we can move forward. If the comments are not clear at all, I'm more than happy to clarify. But an answer of 'OK if you see a problem send text', is just...not helpful. Questions like: is there any agreement on the comments? Do they make any sense at all ?? ...etc should be addressed, not just 'send text'. Can't we spend this time discussing technical comments?!!! Every time I comment on this draft I get procedural answers from the authors! Sigh > > You have expressed a concern (which I think is quite > valid) about the lack of close examination in the > security requirements for CAR discovery. It would > be extremely helpful if you, Hemant, and Govind > could sit down for an hour at IETF and talk > about the issue, maybe come up with a slide > or two for Govind's presentation. If there is > not enough time at IETF, then perhaps you > can continue the discussion afterwards for > a couple weeks. > > Does that sound doable? => Yes. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 16 02:11:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29558 for ; Sat, 16 Mar 2002 02:11:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02843; Sat, 16 Mar 2002 02:00:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02803 for ; Sat, 16 Mar 2002 02:00:55 -0500 (EST) Received: from hotmail.com (oe38.law4.hotmail.com [216.33.148.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22594 for ; Sat, 16 Mar 2002 02:00:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Mar 2002 23:00:19 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 16:05:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 16 Mar 2002 07:00:19.0784 (UTC) FILETIME=[3C1FA480:01C1CCB8] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I think it is very difficult to verify that the AR claiming to be a GAAR is indeed a GAAR even though it is very desirable. So I'd be reluctant to put it as a requirement. I have no problem about verifying the authenticity of a router. > > a) The solution MUST provide means for an AR to to verify that another > AR > > claiming to be its GAAR is genuine. In other words, the other AR is > indeed a > > GAAR and it is an authentic router. Thanks. Eunsoo > ----- Original Message ----- > From: "Hemant Chaskar" > To: > Sent: Thursday, March 14, 2002 11:00 PM > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > Hi James: > > > > Rather than starting from scratch again in Minneapolis, may I propose > that > > we start from the following baseline text for security requirements. I > think > > this text very clearly and explicitly brings out the security issues > > involved. If any additional statements are needed we can fill them in. > Sorry > > to repeat this, but I did not see any reference to earlier discussion > on > > this text in Hesham's email. > > > > "Solution to CAR discovery MUST address the security concerns > involved in > > the various aspects such as GAAR discovery, capability exchange and > CAR > > selection. In particular, > > > > a) The solution MUST provide means for an AR to to verify that another > AR > > claiming to be its GAAR is genuine. In other words, the other AR is > indeed a > > GAAR and it is an authentic router. The authenticity of a router MAY > mean > > that it is authorized to act as an access router by the jurisdiction > of the > > environment (operator network, organizatoinal LAN, home network etc.) > that > > the router resides in. > > > > b)It MUST provide means for secure capability exchange between an AR > and its > > GAAR. > > > > c)It MUST provide secure means for the expression of MN requirements > to CAR > > selection algorithms." > > > > Regards, > > Hemant > > > > >From: "James Kempf" > > >To: "Hesham Soliman \(ERA\)" , > > >"'Govind Krishnamurthi'" , > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > >Hesham, > > > > > > > > Re. the comments on security, maybe we need a more > > > > > comprehensive threat > > > > > analysis such as Claude did for paging? > > > > > The requirement I did was pretty generic. > > > > > > > > => Agreed. No need for a separate doc. This > > > > is what I was hinting at when I said 'I can try'. > > > > Because this is something that will take time. > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > >Maybe we can get together a small group > > >of volunteers to help. It should > > >not take much time, and I agree that we > > >don't need a separate document, but > > >I think we need something more than > > >we have now. > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Sat Mar 16 02:11:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29571 for ; Sat, 16 Mar 2002 02:11:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA03103 for seamoby-archive@odin.ietf.org; Sat, 16 Mar 2002 02:11:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02843; Sat, 16 Mar 2002 02:00:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02803 for ; Sat, 16 Mar 2002 02:00:55 -0500 (EST) Received: from hotmail.com (oe38.law4.hotmail.com [216.33.148.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22594 for ; Sat, 16 Mar 2002 02:00:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Mar 2002 23:00:19 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 16:05:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 16 Mar 2002 07:00:19.0784 (UTC) FILETIME=[3C1FA480:01C1CCB8] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I think it is very difficult to verify that the AR claiming to be a GAAR is indeed a GAAR even though it is very desirable. So I'd be reluctant to put it as a requirement. I have no problem about verifying the authenticity of a router. > > a) The solution MUST provide means for an AR to to verify that another > AR > > claiming to be its GAAR is genuine. In other words, the other AR is > indeed a > > GAAR and it is an authentic router. Thanks. Eunsoo > ----- Original Message ----- > From: "Hemant Chaskar" > To: > Sent: Thursday, March 14, 2002 11:00 PM > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > Hi James: > > > > Rather than starting from scratch again in Minneapolis, may I propose > that > > we start from the following baseline text for security requirements. I > think > > this text very clearly and explicitly brings out the security issues > > involved. If any additional statements are needed we can fill them in. > Sorry > > to repeat this, but I did not see any reference to earlier discussion > on > > this text in Hesham's email. > > > > "Solution to CAR discovery MUST address the security concerns > involved in > > the various aspects such as GAAR discovery, capability exchange and > CAR > > selection. In particular, > > > > a) The solution MUST provide means for an AR to to verify that another > AR > > claiming to be its GAAR is genuine. In other words, the other AR is > indeed a > > GAAR and it is an authentic router. The authenticity of a router MAY > mean > > that it is authorized to act as an access router by the jurisdiction > of the > > environment (operator network, organizatoinal LAN, home network etc.) > that > > the router resides in. > > > > b)It MUST provide means for secure capability exchange between an AR > and its > > GAAR. > > > > c)It MUST provide secure means for the expression of MN requirements > to CAR > > selection algorithms." > > > > Regards, > > Hemant > > > > >From: "James Kempf" > > >To: "Hesham Soliman \(ERA\)" , > > >"'Govind Krishnamurthi'" , > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > >Hesham, > > > > > > > > Re. the comments on security, maybe we need a more > > > > > comprehensive threat > > > > > analysis such as Claude did for paging? > > > > > The requirement I did was pretty generic. > > > > > > > > => Agreed. No need for a separate doc. This > > > > is what I was hinting at when I said 'I can try'. > > > > Because this is something that will take time. > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > >Maybe we can get together a small group > > >of volunteers to help. It should > > >not take much time, and I agree that we > > >don't need a separate document, but > > >I think we need something more than > > >we have now. > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 16 04:35:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00958 for ; Sat, 16 Mar 2002 04:35:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07811; Sat, 16 Mar 2002 04:30:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07767 for ; Sat, 16 Mar 2002 04:30:10 -0500 (EST) Received: from hotmail.com (oe48.law4.hotmail.com [216.33.148.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00855 for ; Sat, 16 Mar 2002 04:30:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Mar 2002 01:29:34 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 18:34:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 16 Mar 2002 09:29:34.0068 (UTC) FILETIME=[154AF340:01C1CCCD] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I mean the purpose of security is to verify the authenticity of the message sender and the integrity of the message rather than the correctness of the information contained in the message. I think whether the claimed GAAR is indeed a GAAR is about the correctness of the information. Thanks. Eunsoo ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Saturday, March 16, 2002 4:05 PM Subject: Re: [Seamoby] comments on CAR Discovery Requirements > Hemant, > > I think it is very difficult to verify that the AR claiming to be a GAAR is > indeed a GAAR even though it is very desirable. So I'd be reluctant to put > it as a requirement. > I have no problem about verifying the authenticity of a router. > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. > > Thanks. > > Eunsoo > > > ----- Original Message ----- > > From: "Hemant Chaskar" > > To: > > Sent: Thursday, March 14, 2002 11:00 PM > > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > > > > Hi James: > > > > > > Rather than starting from scratch again in Minneapolis, may I propose > > that > > > we start from the following baseline text for security requirements. I > > think > > > this text very clearly and explicitly brings out the security issues > > > involved. If any additional statements are needed we can fill them in. > > Sorry > > > to repeat this, but I did not see any reference to earlier discussion > > on > > > this text in Hesham's email. > > > > > > "Solution to CAR discovery MUST address the security concerns > > involved in > > > the various aspects such as GAAR discovery, capability exchange and > > CAR > > > selection. In particular, > > > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. The authenticity of a router MAY > > mean > > > that it is authorized to act as an access router by the jurisdiction > > of the > > > environment (operator network, organizatoinal LAN, home network etc.) > > that > > > the router resides in. > > > > > > b)It MUST provide means for secure capability exchange between an AR > > and its > > > GAAR. > > > > > > c)It MUST provide secure means for the expression of MN requirements > > to CAR > > > selection algorithms." > > > > > > Regards, > > > Hemant > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Govind Krishnamurthi'" , > > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > > > >Hesham, > > > > > > > > > > Re. the comments on security, maybe we need a more > > > > > > comprehensive threat > > > > > > analysis such as Claude did for paging? > > > > > > The requirement I did was pretty generic. > > > > > > > > > > => Agreed. No need for a separate doc. This > > > > > is what I was hinting at when I said 'I can try'. > > > > > Because this is something that will take time. > > > > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > > >Maybe we can get together a small group > > > >of volunteers to help. It should > > > >not take much time, and I agree that we > > > >don't need a separate document, but > > > >I think we need something more than > > > >we have now. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Sat Mar 16 04:35:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00972 for ; Sat, 16 Mar 2002 04:35:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08313 for seamoby-archive@odin.ietf.org; Sat, 16 Mar 2002 04:35:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07811; Sat, 16 Mar 2002 04:30:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07767 for ; Sat, 16 Mar 2002 04:30:10 -0500 (EST) Received: from hotmail.com (oe48.law4.hotmail.com [216.33.148.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00855 for ; Sat, 16 Mar 2002 04:30:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Mar 2002 01:29:34 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 18:34:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 16 Mar 2002 09:29:34.0068 (UTC) FILETIME=[154AF340:01C1CCCD] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I mean the purpose of security is to verify the authenticity of the message sender and the integrity of the message rather than the correctness of the information contained in the message. I think whether the claimed GAAR is indeed a GAAR is about the correctness of the information. Thanks. Eunsoo ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Saturday, March 16, 2002 4:05 PM Subject: Re: [Seamoby] comments on CAR Discovery Requirements > Hemant, > > I think it is very difficult to verify that the AR claiming to be a GAAR is > indeed a GAAR even though it is very desirable. So I'd be reluctant to put > it as a requirement. > I have no problem about verifying the authenticity of a router. > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. > > Thanks. > > Eunsoo > > > ----- Original Message ----- > > From: "Hemant Chaskar" > > To: > > Sent: Thursday, March 14, 2002 11:00 PM > > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > > > > Hi James: > > > > > > Rather than starting from scratch again in Minneapolis, may I propose > > that > > > we start from the following baseline text for security requirements. I > > think > > > this text very clearly and explicitly brings out the security issues > > > involved. If any additional statements are needed we can fill them in. > > Sorry > > > to repeat this, but I did not see any reference to earlier discussion > > on > > > this text in Hesham's email. > > > > > > "Solution to CAR discovery MUST address the security concerns > > involved in > > > the various aspects such as GAAR discovery, capability exchange and > > CAR > > > selection. In particular, > > > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. The authenticity of a router MAY > > mean > > > that it is authorized to act as an access router by the jurisdiction > > of the > > > environment (operator network, organizatoinal LAN, home network etc.) > > that > > > the router resides in. > > > > > > b)It MUST provide means for secure capability exchange between an AR > > and its > > > GAAR. > > > > > > c)It MUST provide secure means for the expression of MN requirements > > to CAR > > > selection algorithms." > > > > > > Regards, > > > Hemant > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Govind Krishnamurthi'" , > > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > > > >Hesham, > > > > > > > > > > Re. the comments on security, maybe we need a more > > > > > > comprehensive threat > > > > > > analysis such as Claude did for paging? > > > > > > The requirement I did was pretty generic. > > > > > > > > > > => Agreed. No need for a separate doc. This > > > > > is what I was hinting at when I said 'I can try'. > > > > > Because this is something that will take time. > > > > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > > >Maybe we can get together a small group > > > >of volunteers to help. It should > > > >not take much time, and I agree that we > > > >don't need a separate document, but > > > >I think we need something more than > > > >we have now. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 16 18:18:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11138 for ; Sat, 16 Mar 2002 18:18:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09675; Sat, 16 Mar 2002 17:59:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09646 for ; Sat, 16 Mar 2002 17:59:21 -0500 (EST) Received: from hotmail.com (f96.law7.hotmail.com [216.33.237.96]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10884 for ; Sat, 16 Mar 2002 17:59:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Mar 2002 14:58:51 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 16 Mar 2002 22:58:50 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 22:58:50 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2002 22:58:51.0138 (UTC) FILETIME=[238FD620:01C1CD3E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Eunsoo: Since you think that this is "very desirable", shouldn't it be a MUST requirement. Also, I do not think that doing this is impossible. Hemant >From: "Eunsoo Shim" >To: >Subject: Re: [Seamoby] comments on CAR Discovery Requirements >Date: Sat, 16 Mar 2002 16:05:27 -0800 > >Hemant, > >I think it is very difficult to verify that the AR claiming to be a GAAR is >indeed a GAAR even though it is very desirable. So I'd be reluctant to put >it as a requirement. >I have no problem about verifying the authenticity of a router. > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. > >Thanks. > >Eunsoo > > > ----- Original Message ----- > > From: "Hemant Chaskar" > > To: > > Sent: Thursday, March 14, 2002 11:00 PM > > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > > > > Hi James: > > > > > > Rather than starting from scratch again in Minneapolis, may I propose > > that > > > we start from the following baseline text for security requirements. I > > think > > > this text very clearly and explicitly brings out the security issues > > > involved. If any additional statements are needed we can fill them in. > > Sorry > > > to repeat this, but I did not see any reference to earlier discussion > > on > > > this text in Hesham's email. > > > > > > "Solution to CAR discovery MUST address the security concerns > > involved in > > > the various aspects such as GAAR discovery, capability exchange and > > CAR > > > selection. In particular, > > > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. The authenticity of a router MAY > > mean > > > that it is authorized to act as an access router by the jurisdiction > > of the > > > environment (operator network, organizatoinal LAN, home network etc.) > > that > > > the router resides in. > > > > > > b)It MUST provide means for secure capability exchange between an AR > > and its > > > GAAR. > > > > > > c)It MUST provide secure means for the expression of MN requirements > > to CAR > > > selection algorithms." > > > > > > Regards, > > > Hemant > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Govind Krishnamurthi'" , > > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > > > >Hesham, > > > > > > > > > > Re. the comments on security, maybe we need a more > > > > > > comprehensive threat > > > > > > analysis such as Claude did for paging? > > > > > > The requirement I did was pretty generic. > > > > > > > > > > => Agreed. No need for a separate doc. This > > > > > is what I was hinting at when I said 'I can try'. > > > > > Because this is something that will take time. > > > > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > > >Maybe we can get together a small group > > > >of volunteers to help. It should > > > >not take much time, and I agree that we > > > >don't need a separate document, but > > > >I think we need something more than > > > >we have now. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 16 18:21:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11193 for ; Sat, 16 Mar 2002 18:21:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10234; Sat, 16 Mar 2002 18:03:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10204 for ; Sat, 16 Mar 2002 18:03:49 -0500 (EST) Received: from hotmail.com (f174.law7.hotmail.com [216.33.237.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10973 for ; Sat, 16 Mar 2002 18:03:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Mar 2002 15:03:19 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 16 Mar 2002 23:03:18 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 23:03:18 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2002 23:03:19.0055 (UTC) FILETIME=[C340B9F0:01C1CD3E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Eunsoo, In the CAR case, verifying "authenticity of sender" does involve verifying that it is your GAAR. This is because, here sender cannot be an arbitrary IP device, it has to be a GAAR. Otherwise, an AR can be trapped into exchanging capabilities with a bunch of ARs which are not actually its GAARs. The non-GAARs can then overwhelm AR with their capabilities and cause DOS attack. Hemant >From: "Eunsoo Shim" >To: >Subject: Re: [Seamoby] comments on CAR Discovery Requirements >Date: Sat, 16 Mar 2002 18:34:43 -0800 > >I mean the purpose of security is to verify the authenticity of the message >sender and the integrity of the message rather than the correctness of the >information contained in the message. I think whether the claimed GAAR is >indeed a GAAR is about the correctness of the information. >Thanks. > >Eunsoo >----- Original Message ----- >From: "Eunsoo Shim" >To: >Sent: Saturday, March 16, 2002 4:05 PM >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > Hemant, > > > > I think it is very difficult to verify that the AR claiming to be a GAAR >is > > indeed a GAAR even though it is very desirable. So I'd be reluctant to >put > > it as a requirement. > > I have no problem about verifying the authenticity of a router. > > > > > > a) The solution MUST provide means for an AR to to verify that >another > > > AR > > > > claiming to be its GAAR is genuine. In other words, the other AR is > > > indeed a > > > > GAAR and it is an authentic router. > > > > Thanks. > > > > Eunsoo > > > > > ----- Original Message ----- > > > From: "Hemant Chaskar" > > > To: > > > Sent: Thursday, March 14, 2002 11:00 PM > > > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > > > > > > > Hi James: > > > > > > > > Rather than starting from scratch again in Minneapolis, may I >propose > > > that > > > > we start from the following baseline text for security requirements. >I > > > think > > > > this text very clearly and explicitly brings out the security issues > > > > involved. If any additional statements are needed we can fill them >in. > > > Sorry > > > > to repeat this, but I did not see any reference to earlier >discussion > > > on > > > > this text in Hesham's email. > > > > > > > > "Solution to CAR discovery MUST address the security concerns > > > involved in > > > > the various aspects such as GAAR discovery, capability exchange and > > > CAR > > > > selection. In particular, > > > > > > > > a) The solution MUST provide means for an AR to to verify that >another > > > AR > > > > claiming to be its GAAR is genuine. In other words, the other AR is > > > indeed a > > > > GAAR and it is an authentic router. The authenticity of a router MAY > > > mean > > > > that it is authorized to act as an access router by the jurisdiction > > > of the > > > > environment (operator network, organizatoinal LAN, home network >etc.) > > > that > > > > the router resides in. > > > > > > > > b)It MUST provide means for secure capability exchange between an AR > > > and its > > > > GAAR. > > > > > > > > c)It MUST provide secure means for the expression of MN requirements > > > to CAR > > > > selection algorithms." > > > > > > > > Regards, > > > > Hemant > > > > > > > > >From: "James Kempf" > > > > >To: "Hesham Soliman \(ERA\)" , > > > > >"'Govind Krishnamurthi'" , > > > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > > > > > >Hesham, > > > > > > > > > > > > Re. the comments on security, maybe we need a more > > > > > > > comprehensive threat > > > > > > > analysis such as Claude did for paging? > > > > > > > The requirement I did was pretty generic. > > > > > > > > > > > > => Agreed. No need for a separate doc. This > > > > > > is what I was hinting at when I said 'I can try'. > > > > > > Because this is something that will take time. > > > > > > > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > > > >Maybe we can get together a small group > > > > >of volunteers to help. It should > > > > >not take much time, and I agree that we > > > > >don't need a separate document, but > > > > >I think we need something more than > > > > >we have now. > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Mar 16 19:11:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11146 for ; Sat, 16 Mar 2002 18:18:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10474 for seamoby-archive@odin.ietf.org; Sat, 16 Mar 2002 18:18:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09675; Sat, 16 Mar 2002 17:59:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09646 for ; Sat, 16 Mar 2002 17:59:21 -0500 (EST) Received: from hotmail.com (f96.law7.hotmail.com [216.33.237.96]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10884 for ; Sat, 16 Mar 2002 17:59:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Mar 2002 14:58:51 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 16 Mar 2002 22:58:50 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 22:58:50 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2002 22:58:51.0138 (UTC) FILETIME=[238FD620:01C1CD3E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Eunsoo: Since you think that this is "very desirable", shouldn't it be a MUST requirement. Also, I do not think that doing this is impossible. Hemant >From: "Eunsoo Shim" >To: >Subject: Re: [Seamoby] comments on CAR Discovery Requirements >Date: Sat, 16 Mar 2002 16:05:27 -0800 > >Hemant, > >I think it is very difficult to verify that the AR claiming to be a GAAR is >indeed a GAAR even though it is very desirable. So I'd be reluctant to put >it as a requirement. >I have no problem about verifying the authenticity of a router. > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. > >Thanks. > >Eunsoo > > > ----- Original Message ----- > > From: "Hemant Chaskar" > > To: > > Sent: Thursday, March 14, 2002 11:00 PM > > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > > > > Hi James: > > > > > > Rather than starting from scratch again in Minneapolis, may I propose > > that > > > we start from the following baseline text for security requirements. I > > think > > > this text very clearly and explicitly brings out the security issues > > > involved. If any additional statements are needed we can fill them in. > > Sorry > > > to repeat this, but I did not see any reference to earlier discussion > > on > > > this text in Hesham's email. > > > > > > "Solution to CAR discovery MUST address the security concerns > > involved in > > > the various aspects such as GAAR discovery, capability exchange and > > CAR > > > selection. In particular, > > > > > > a) The solution MUST provide means for an AR to to verify that another > > AR > > > claiming to be its GAAR is genuine. In other words, the other AR is > > indeed a > > > GAAR and it is an authentic router. The authenticity of a router MAY > > mean > > > that it is authorized to act as an access router by the jurisdiction > > of the > > > environment (operator network, organizatoinal LAN, home network etc.) > > that > > > the router resides in. > > > > > > b)It MUST provide means for secure capability exchange between an AR > > and its > > > GAAR. > > > > > > c)It MUST provide secure means for the expression of MN requirements > > to CAR > > > selection algorithms." > > > > > > Regards, > > > Hemant > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Govind Krishnamurthi'" , > > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > > > >Hesham, > > > > > > > > > > Re. the comments on security, maybe we need a more > > > > > > comprehensive threat > > > > > > analysis such as Claude did for paging? > > > > > > The requirement I did was pretty generic. > > > > > > > > > > => Agreed. No need for a separate doc. This > > > > > is what I was hinting at when I said 'I can try'. > > > > > Because this is something that will take time. > > > > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > > >Maybe we can get together a small group > > > >of volunteers to help. It should > > > >not take much time, and I agree that we > > > >don't need a separate document, but > > > >I think we need something more than > > > >we have now. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Mar 16 19:11:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11203 for ; Sat, 16 Mar 2002 18:21:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10539 for seamoby-archive@odin.ietf.org; Sat, 16 Mar 2002 18:21:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10234; Sat, 16 Mar 2002 18:03:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10204 for ; Sat, 16 Mar 2002 18:03:49 -0500 (EST) Received: from hotmail.com (f174.law7.hotmail.com [216.33.237.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10973 for ; Sat, 16 Mar 2002 18:03:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 16 Mar 2002 15:03:19 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sat, 16 Mar 2002 23:03:18 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] comments on CAR Discovery Requirements Date: Sat, 16 Mar 2002 23:03:18 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2002 23:03:19.0055 (UTC) FILETIME=[C340B9F0:01C1CD3E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Eunsoo, In the CAR case, verifying "authenticity of sender" does involve verifying that it is your GAAR. This is because, here sender cannot be an arbitrary IP device, it has to be a GAAR. Otherwise, an AR can be trapped into exchanging capabilities with a bunch of ARs which are not actually its GAARs. The non-GAARs can then overwhelm AR with their capabilities and cause DOS attack. Hemant >From: "Eunsoo Shim" >To: >Subject: Re: [Seamoby] comments on CAR Discovery Requirements >Date: Sat, 16 Mar 2002 18:34:43 -0800 > >I mean the purpose of security is to verify the authenticity of the message >sender and the integrity of the message rather than the correctness of the >information contained in the message. I think whether the claimed GAAR is >indeed a GAAR is about the correctness of the information. >Thanks. > >Eunsoo >----- Original Message ----- >From: "Eunsoo Shim" >To: >Sent: Saturday, March 16, 2002 4:05 PM >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > Hemant, > > > > I think it is very difficult to verify that the AR claiming to be a GAAR >is > > indeed a GAAR even though it is very desirable. So I'd be reluctant to >put > > it as a requirement. > > I have no problem about verifying the authenticity of a router. > > > > > > a) The solution MUST provide means for an AR to to verify that >another > > > AR > > > > claiming to be its GAAR is genuine. In other words, the other AR is > > > indeed a > > > > GAAR and it is an authentic router. > > > > Thanks. > > > > Eunsoo > > > > > ----- Original Message ----- > > > From: "Hemant Chaskar" > > > To: > > > Sent: Thursday, March 14, 2002 11:00 PM > > > Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > > > > > > > Hi James: > > > > > > > > Rather than starting from scratch again in Minneapolis, may I >propose > > > that > > > > we start from the following baseline text for security requirements. >I > > > think > > > > this text very clearly and explicitly brings out the security issues > > > > involved. If any additional statements are needed we can fill them >in. > > > Sorry > > > > to repeat this, but I did not see any reference to earlier >discussion > > > on > > > > this text in Hesham's email. > > > > > > > > "Solution to CAR discovery MUST address the security concerns > > > involved in > > > > the various aspects such as GAAR discovery, capability exchange and > > > CAR > > > > selection. In particular, > > > > > > > > a) The solution MUST provide means for an AR to to verify that >another > > > AR > > > > claiming to be its GAAR is genuine. In other words, the other AR is > > > indeed a > > > > GAAR and it is an authentic router. The authenticity of a router MAY > > > mean > > > > that it is authorized to act as an access router by the jurisdiction > > > of the > > > > environment (operator network, organizatoinal LAN, home network >etc.) > > > that > > > > the router resides in. > > > > > > > > b)It MUST provide means for secure capability exchange between an AR > > > and its > > > > GAAR. > > > > > > > > c)It MUST provide secure means for the expression of MN requirements > > > to CAR > > > > selection algorithms." > > > > > > > > Regards, > > > > Hemant > > > > > > > > >From: "James Kempf" > > > > >To: "Hesham Soliman \(ERA\)" , > > > > >"'Govind Krishnamurthi'" , > > > > >Subject: Re: [Seamoby] comments on CAR Discovery Requirements > > > > >Date: Thu, 14 Mar 2002 14:34:29 -0800 > > > > > > > > > >Hesham, > > > > > > > > > > > > Re. the comments on security, maybe we need a more > > > > > > > comprehensive threat > > > > > > > analysis such as Claude did for paging? > > > > > > > The requirement I did was pretty generic. > > > > > > > > > > > > => Agreed. No need for a separate doc. This > > > > > > is what I was hinting at when I said 'I can try'. > > > > > > Because this is something that will take time. > > > > > > > > > > > > > > > >Good, let's talk about this in the Minne-apple. > > > > >Maybe we can get together a small group > > > > >of volunteers to help. It should > > > > >not take much time, and I agree that we > > > > >don't need a separate document, but > > > > >I think we need something more than > > > > >we have now. > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 18 10:20:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07049 for ; Mon, 18 Mar 2002 10:20:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08458; Mon, 18 Mar 2002 10:09:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08429 for ; Mon, 18 Mar 2002 10:09:27 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06616 for ; Mon, 18 Mar 2002 10:09:21 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2IF9aZ00515 for ; Mon, 18 Mar 2002 17:09:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Mar 2002 17:09:23 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 18 Mar 2002 17:09:23 +0200 Received: from Beethoven (nokdab005178.americas.nokia.com [172.18.5.178]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA07419; Mon, 18 Mar 2002 10:05:39 -0500 (EST) Message-ID: <00a401c1ce8e$e0345b10$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B0464FFA7@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] CAR Discovery Requirements Date: Mon, 18 Mar 2002 10:09:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 18 Mar 2002 15:09:23.0604 (UTC) FILETIME=[E33ABD40:01C1CE8E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Madjid, Indeed, this requirement deals with one of the possible inputs in the CAR discovery. Since network capabilities are covered already in the requirements (capability exchange), I wanted to put MN's requirements in there. Whether the involved entities are already aware of these or not is a matter of the solution, but most likely they are. Regards, Dirk ----- Original Message ----- From: "ext Nakhjiri Madjid-MNAKHJI1" To: ; "Nakhjiri Madjid-MNAKHJI1" ; Sent: Friday, March 15, 2002 5:57 PM Subject: RE: [Seamoby] CAR Discovery Requirements > Hi Dirk, > > I think it is sufficient to point out that the CAR disc protocol > needs to provide means of signaling the necessary input > for the selection process, including network capabilities > and MN's preferences (profile). > My point was that: > Since the selection process is either done by MN or oldAR > in the old network, no external signaling is necessary, because > they are both aware of MN's preferences, unless CAR > is happening at a different network entity at the old network. > And I don't think CAR is performed at the target network either, > do you? > > Regards, > Madjid > -----Original Message----- > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > Sent: Thursday, March 14, 2002 10:51 AM > To: Madjid Nakhjiri; seamoby@ietf.org > Subject: RE: [Seamoby] CAR Discovery Requirements > > > Hi Madjid, > > I'm not saying that MN's requirements have to be spelled out again. > 'Means to express the requirements' includes some mechanisms to > define these requirements somehow and the means that they can be used > as an input to the CAR discovery protocol. It is certainly possible that > the first part is done by currently existing protocols, but the > requirement merely states that the means are mandatory for the > CAR discovery solution, otherwise it cannot fulfil its task. > > Maybe, here's some confusion in general sometimes that the requirements > always mandate NEW functionality. This is not the case. The requirements > merely describe the functionality that is needed to do the job. Whether > or not this will be done in the final proposal by existing protocols, > modifications to existing ones, or new mechanisms is out of the scope > of the requirements. > > Regards, > > > Dirk > > -----Original Message----- > From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, March 14, 2002 10:59 AM > To: Trossen Dirk (NRC/Boston); seamoby@ietf.org > Subject: RE: [Seamoby] CAR Discovery Requirements > > > Sorry for the late response, > > isn't MN's requirement spelled out in MN's user profile or > SLA or something else recorded in the policy server of the > MN's network? why does the MN has to express them again. > if the new network needs it (I don't know why it would in > a CAR selection), then it can get it from old network, if the > old network needs, it gets it from policy server. > I think what this should concentrate on is: > > CAR discovery protocol MUST provide means for signaling > parameters needed for a TAR selection mechanims (regardless > of whether it is done at MN or at AR). > > I know that the selection process is out of scope, but providing > input for it should be in scope. signaling MN's requirements for > service is a different issue. > > Regards, > > > Madjid > > > "3.xx Providing MN's requirement for Determination of CARs > > The fundamental task of CAR discovery is to determine candidate > access routers (from the set of GAARs) that meet MN's requirements, > if known at the time of handoff. A CAR discovery protocol MUST > determine a set of CARs that meet MN's requirements. For this, > a CAR discovery protocol MUST provide means for the MN to express > these requirements." > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 18 10:20:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07061 for ; Mon, 18 Mar 2002 10:20:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09334 for seamoby-archive@odin.ietf.org; Mon, 18 Mar 2002 10:20:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08458; Mon, 18 Mar 2002 10:09:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08429 for ; Mon, 18 Mar 2002 10:09:27 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06616 for ; Mon, 18 Mar 2002 10:09:21 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2IF9aZ00515 for ; Mon, 18 Mar 2002 17:09:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Mar 2002 17:09:23 +0200 Received: from miller.americas.nokia.com ([172.19.160.22]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 18 Mar 2002 17:09:23 +0200 Received: from Beethoven (nokdab005178.americas.nokia.com [172.18.5.178]) by miller.americas.nokia.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA07419; Mon, 18 Mar 2002 10:05:39 -0500 (EST) Message-ID: <00a401c1ce8e$e0345b10$6401a8c0@Beethoven> From: "Trossen Dirk \(NRC/Boston\)" To: "ext Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B0464FFA7@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] CAR Discovery Requirements Date: Mon, 18 Mar 2002 10:09:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 18 Mar 2002 15:09:23.0604 (UTC) FILETIME=[E33ABD40:01C1CE8E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Madjid, Indeed, this requirement deals with one of the possible inputs in the CAR discovery. Since network capabilities are covered already in the requirements (capability exchange), I wanted to put MN's requirements in there. Whether the involved entities are already aware of these or not is a matter of the solution, but most likely they are. Regards, Dirk ----- Original Message ----- From: "ext Nakhjiri Madjid-MNAKHJI1" To: ; "Nakhjiri Madjid-MNAKHJI1" ; Sent: Friday, March 15, 2002 5:57 PM Subject: RE: [Seamoby] CAR Discovery Requirements > Hi Dirk, > > I think it is sufficient to point out that the CAR disc protocol > needs to provide means of signaling the necessary input > for the selection process, including network capabilities > and MN's preferences (profile). > My point was that: > Since the selection process is either done by MN or oldAR > in the old network, no external signaling is necessary, because > they are both aware of MN's preferences, unless CAR > is happening at a different network entity at the old network. > And I don't think CAR is performed at the target network either, > do you? > > Regards, > Madjid > -----Original Message----- > From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] > Sent: Thursday, March 14, 2002 10:51 AM > To: Madjid Nakhjiri; seamoby@ietf.org > Subject: RE: [Seamoby] CAR Discovery Requirements > > > Hi Madjid, > > I'm not saying that MN's requirements have to be spelled out again. > 'Means to express the requirements' includes some mechanisms to > define these requirements somehow and the means that they can be used > as an input to the CAR discovery protocol. It is certainly possible that > the first part is done by currently existing protocols, but the > requirement merely states that the means are mandatory for the > CAR discovery solution, otherwise it cannot fulfil its task. > > Maybe, here's some confusion in general sometimes that the requirements > always mandate NEW functionality. This is not the case. The requirements > merely describe the functionality that is needed to do the job. Whether > or not this will be done in the final proposal by existing protocols, > modifications to existing ones, or new mechanisms is out of the scope > of the requirements. > > Regards, > > > Dirk > > -----Original Message----- > From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Thursday, March 14, 2002 10:59 AM > To: Trossen Dirk (NRC/Boston); seamoby@ietf.org > Subject: RE: [Seamoby] CAR Discovery Requirements > > > Sorry for the late response, > > isn't MN's requirement spelled out in MN's user profile or > SLA or something else recorded in the policy server of the > MN's network? why does the MN has to express them again. > if the new network needs it (I don't know why it would in > a CAR selection), then it can get it from old network, if the > old network needs, it gets it from policy server. > I think what this should concentrate on is: > > CAR discovery protocol MUST provide means for signaling > parameters needed for a TAR selection mechanims (regardless > of whether it is done at MN or at AR). > > I know that the selection process is out of scope, but providing > input for it should be in scope. signaling MN's requirements for > service is a different issue. > > Regards, > > > Madjid > > > "3.xx Providing MN's requirement for Determination of CARs > > The fundamental task of CAR discovery is to determine candidate > access routers (from the set of GAARs) that meet MN's requirements, > if known at the time of handoff. A CAR discovery protocol MUST > determine a set of CARs that meet MN's requirements. For this, > a CAR discovery protocol MUST provide means for the MN to express > these requirements." > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 18 11:18:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08831 for ; Mon, 18 Mar 2002 11:18:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12596; Mon, 18 Mar 2002 11:09:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12554 for ; Mon, 18 Mar 2002 11:09:49 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08414 for ; Mon, 18 Mar 2002 11:09:42 -0500 (EST) Received: from T23KEMPF (dhcp86.docomolabs-usa.com [172.21.96.86]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2IG95I07064; Mon, 18 Mar 2002 08:09:06 -0800 (PST) Message-ID: <002401c1ce97$01708760$566015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Date: Mon, 18 Mar 2002 08:07:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Verifying that a sender is a GAAR Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, The purpose of putting authentiation onf any GAAR information is precisely to allow a receive to trust that the information came from a reliable source. The only other way a receiver could determine that a router claiming to be a GAAR is, in fact, a GAAR would be to get information from another source that it trusted and compare it. But how would the receiver trust that? Putting a signature on the GAAR information and requiring a trust relationship ensures that the receiver can trust the GAAR information. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 18 11:18:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08848 for ; Mon, 18 Mar 2002 11:18:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13055 for seamoby-archive@odin.ietf.org; Mon, 18 Mar 2002 11:18:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12596; Mon, 18 Mar 2002 11:09:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12554 for ; Mon, 18 Mar 2002 11:09:49 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08414 for ; Mon, 18 Mar 2002 11:09:42 -0500 (EST) Received: from T23KEMPF (dhcp86.docomolabs-usa.com [172.21.96.86]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2IG95I07064; Mon, 18 Mar 2002 08:09:06 -0800 (PST) Message-ID: <002401c1ce97$01708760$566015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Date: Mon, 18 Mar 2002 08:07:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Verifying that a sender is a GAAR Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, The purpose of putting authentiation onf any GAAR information is precisely to allow a receive to trust that the information came from a reliable source. The only other way a receiver could determine that a router claiming to be a GAAR is, in fact, a GAAR would be to get information from another source that it trusted and compare it. But how would the receiver trust that? Putting a signature on the GAAR information and requiring a trust relationship ensures that the receiver can trust the GAAR information. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 18 15:41:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19379 for ; Mon, 18 Mar 2002 15:41:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04472; Mon, 18 Mar 2002 15:33:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04448 for ; Mon, 18 Mar 2002 15:33:52 -0500 (EST) Received: from hotmail.com (f80.law7.hotmail.com [216.33.237.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19120 for ; Mon, 18 Mar 2002 15:33:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Mar 2002 12:33:20 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 18 Mar 2002 20:33:20 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Mon, 18 Mar 2002 20:33:20 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Mar 2002 20:33:20.0800 (UTC) FILETIME=[24B37A00:01C1CEBC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Let us take a step-by-step view of the procedures involved: - First AR2 will receive information (by any means) that an IP address X claims to be its GAAR and intends to exchange capabilities with it. - AR2 may want to first make sure that an IP address X is an authentic access router. This is covered by the requirements text: "The solution to CAR discovery MUST provide means for an AR to verify that another AR claiming to be its GAAR is an authentic access router. The authenticity of access router MAY mean that it is authorized to act as an access router by the jurisdiction of the environment that the router resides in." - The question now is "whether AR2 would like to verify that this (now authentic) access router with IP address X is indeed its GAAR". The reason for this could be to avoid spending AR2's resources in exchanging capabilities with non-GAARs. If the answer to question is yes (WG has to decide this), then it can be covered by the following text of security requirement. "The solution MUST/SHOULD provide means for an AR to to verify that another AR claiming to be its GAAR is indeed a GAAR." I think that one can use some information from Geospace to implement this. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: [Seamoby] Verifying that a sender is a GAAR >Date: Mon, 18 Mar 2002 08:07:29 -0800 > >Hemant, > >The purpose of putting authentiation onf any GAAR information is >precisely to allow a receive to trust that the information came from a >reliable source. The only other way a receiver could determine that a >router claiming to be a GAAR is, in fact, a GAAR would be to get >information from another source that it trusted and compare it. But how >would the receiver trust that? Putting a signature on the GAAR >information and requiring a trust relationship ensures that the receiver >can trust the GAAR information. > > jak > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Mar 18 15:42:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19388 for ; Mon, 18 Mar 2002 15:42:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04905 for seamoby-archive@odin.ietf.org; Mon, 18 Mar 2002 15:42:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04472; Mon, 18 Mar 2002 15:33:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04448 for ; Mon, 18 Mar 2002 15:33:52 -0500 (EST) Received: from hotmail.com (f80.law7.hotmail.com [216.33.237.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19120 for ; Mon, 18 Mar 2002 15:33:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Mar 2002 12:33:20 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 18 Mar 2002 20:33:20 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Mon, 18 Mar 2002 20:33:20 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Mar 2002 20:33:20.0800 (UTC) FILETIME=[24B37A00:01C1CEBC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Let us take a step-by-step view of the procedures involved: - First AR2 will receive information (by any means) that an IP address X claims to be its GAAR and intends to exchange capabilities with it. - AR2 may want to first make sure that an IP address X is an authentic access router. This is covered by the requirements text: "The solution to CAR discovery MUST provide means for an AR to verify that another AR claiming to be its GAAR is an authentic access router. The authenticity of access router MAY mean that it is authorized to act as an access router by the jurisdiction of the environment that the router resides in." - The question now is "whether AR2 would like to verify that this (now authentic) access router with IP address X is indeed its GAAR". The reason for this could be to avoid spending AR2's resources in exchanging capabilities with non-GAARs. If the answer to question is yes (WG has to decide this), then it can be covered by the following text of security requirement. "The solution MUST/SHOULD provide means for an AR to to verify that another AR claiming to be its GAAR is indeed a GAAR." I think that one can use some information from Geospace to implement this. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: [Seamoby] Verifying that a sender is a GAAR >Date: Mon, 18 Mar 2002 08:07:29 -0800 > >Hemant, > >The purpose of putting authentiation onf any GAAR information is >precisely to allow a receive to trust that the information came from a >reliable source. The only other way a receiver could determine that a >router claiming to be a GAAR is, in fact, a GAAR would be to get >information from another source that it trusted and compare it. But how >would the receiver trust that? Putting a signature on the GAAR >information and requiring a trust relationship ensures that the receiver >can trust the GAAR information. > > jak > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 18 21:06:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29027 for ; Mon, 18 Mar 2002 21:06:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26701; Mon, 18 Mar 2002 20:38:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26671 for ; Mon, 18 Mar 2002 20:38:52 -0500 (EST) Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28558 for ; Mon, 18 Mar 2002 20:38:48 -0500 (EST) Received: (cpmta 23005 invoked from network); 18 Mar 2002 17:38:20 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.222) with SMTP; 18 Mar 2002 17:38:20 -0800 X-Sent: 19 Mar 2002 01:38:20 GMT Message-ID: <001c01c1cee6$c3b789f0$0902a8c0@Study> From: "Phil Neumiller \(N9FCW\)" To: "James Kempf" , "Hemant Chaskar" , References: <002401c1ce97$01708760$566015ac@T23KEMPF> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Mon, 18 Mar 2002 20:38:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit What makes you so sure of this James? Security concerns belong in the security WG. I guess I have said this about 100 times now. Recall that the charter of the WG deals with seamless mobility, not security. ----- Original Message ----- From: "James Kempf" To: "Hemant Chaskar" ; Sent: Monday, March 18, 2002 11:07 AM Subject: [Seamoby] Verifying that a sender is a GAAR > Hemant, > > The purpose of putting authentiation onf any GAAR information is > precisely to allow a receive to trust that the information came from a > reliable source. The only other way a receiver could determine that a > router claiming to be a GAAR is, in fact, a GAAR would be to get > information from another source that it trusted and compare it. But how > would the receiver trust that? Putting a signature on the GAAR > information and requiring a trust relationship ensures that the receiver > can trust the GAAR information. > > jak > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Mar 18 21:06:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29034 for ; Mon, 18 Mar 2002 21:06:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28289 for seamoby-archive@odin.ietf.org; Mon, 18 Mar 2002 21:06:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26701; Mon, 18 Mar 2002 20:38:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26671 for ; Mon, 18 Mar 2002 20:38:52 -0500 (EST) Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28558 for ; Mon, 18 Mar 2002 20:38:48 -0500 (EST) Received: (cpmta 23005 invoked from network); 18 Mar 2002 17:38:20 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.222) with SMTP; 18 Mar 2002 17:38:20 -0800 X-Sent: 19 Mar 2002 01:38:20 GMT Message-ID: <001c01c1cee6$c3b789f0$0902a8c0@Study> From: "Phil Neumiller \(N9FCW\)" To: "James Kempf" , "Hemant Chaskar" , References: <002401c1ce97$01708760$566015ac@T23KEMPF> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Mon, 18 Mar 2002 20:38:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit What makes you so sure of this James? Security concerns belong in the security WG. I guess I have said this about 100 times now. Recall that the charter of the WG deals with seamless mobility, not security. ----- Original Message ----- From: "James Kempf" To: "Hemant Chaskar" ; Sent: Monday, March 18, 2002 11:07 AM Subject: [Seamoby] Verifying that a sender is a GAAR > Hemant, > > The purpose of putting authentiation onf any GAAR information is > precisely to allow a receive to trust that the information came from a > reliable source. The only other way a receiver could determine that a > router claiming to be a GAAR is, in fact, a GAAR would be to get > information from another source that it trusted and compare it. But how > would the receiver trust that? Putting a signature on the GAAR > information and requiring a trust relationship ensures that the receiver > can trust the GAAR information. > > jak > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 18 21:21:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29272 for ; Mon, 18 Mar 2002 21:21:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28503; Mon, 18 Mar 2002 21:10:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28473 for ; Mon, 18 Mar 2002 21:10:45 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29110 for ; Mon, 18 Mar 2002 21:10:40 -0500 (EST) Received: from T23KEMPF (dhcp86.docomolabs-usa.com [172.21.96.86]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2J2A3I21090; Mon, 18 Mar 2002 18:10:04 -0800 (PST) Message-ID: <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller \(N9FCW\)" , "Hemant Chaskar" , References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Mon, 18 Mar 2002 18:08:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Phil, Every Internet draft is required to have a section called "Security Considerations." This section must deal with how the particular protocol or standard handles security. There has been a history in IETF of saying "use IPsec" in this section (commonly called "IPsec pixie dust"), thus putting the burden of security design for the protocol on the IPsec WG (in effect, deferring it). In the last year, this has changed and the IESG has been requiring that the sections contain more substance saying specifically how the protocol will use IPsec, if the WG proposes that it should, or explicitly describing how security is done if not. The theory behind pushing security back on the WG is that the WG is in a better position to know what the security solutions are for their particular protocol than the IPsec WG. Not that everybody in the WG should necessarily care, but at least someone with some security background and interest should. Thus, the security groups like IPsec and IKE now concern themselves specifically with protocols that do security and not with the security design for other protocols. It is analgous with MIBs. The SNMP working group doesn't do MIBs for other protocols, they work on SNMP. jak PS: If you don't like it, then I'd suggest you complain at the IESG Plenium on Thurs. nite if you are in Minneapolis, or to someone from the IESG Security Area Directorate if not. ----- Original Message ----- From: "Phil Neumiller (N9FCW)" To: "James Kempf" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 5:38 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > What makes you so sure of this James? Security concerns belong in the > security WG. I guess I have said this about 100 times now. Recall that > the charter of the WG deals with seamless mobility, not security. > > ----- Original Message ----- > From: "James Kempf" > To: "Hemant Chaskar" ; > Sent: Monday, March 18, 2002 11:07 AM > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > Hemant, > > > > The purpose of putting authentiation onf any GAAR information is > > precisely to allow a receive to trust that the information came from a > > reliable source. The only other way a receiver could determine that a > > router claiming to be a GAAR is, in fact, a GAAR would be to get > > information from another source that it trusted and compare it. But how > > would the receiver trust that? Putting a signature on the GAAR > > information and requiring a trust relationship ensures that the receiver > > can trust the GAAR information. > > > > jak > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Mar 18 21:21:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29286 for ; Mon, 18 Mar 2002 21:21:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29073 for seamoby-archive@odin.ietf.org; Mon, 18 Mar 2002 21:21:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28503; Mon, 18 Mar 2002 21:10:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28473 for ; Mon, 18 Mar 2002 21:10:45 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29110 for ; Mon, 18 Mar 2002 21:10:40 -0500 (EST) Received: from T23KEMPF (dhcp86.docomolabs-usa.com [172.21.96.86]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2J2A3I21090; Mon, 18 Mar 2002 18:10:04 -0800 (PST) Message-ID: <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller \(N9FCW\)" , "Hemant Chaskar" , References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Mon, 18 Mar 2002 18:08:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Phil, Every Internet draft is required to have a section called "Security Considerations." This section must deal with how the particular protocol or standard handles security. There has been a history in IETF of saying "use IPsec" in this section (commonly called "IPsec pixie dust"), thus putting the burden of security design for the protocol on the IPsec WG (in effect, deferring it). In the last year, this has changed and the IESG has been requiring that the sections contain more substance saying specifically how the protocol will use IPsec, if the WG proposes that it should, or explicitly describing how security is done if not. The theory behind pushing security back on the WG is that the WG is in a better position to know what the security solutions are for their particular protocol than the IPsec WG. Not that everybody in the WG should necessarily care, but at least someone with some security background and interest should. Thus, the security groups like IPsec and IKE now concern themselves specifically with protocols that do security and not with the security design for other protocols. It is analgous with MIBs. The SNMP working group doesn't do MIBs for other protocols, they work on SNMP. jak PS: If you don't like it, then I'd suggest you complain at the IESG Plenium on Thurs. nite if you are in Minneapolis, or to someone from the IESG Security Area Directorate if not. ----- Original Message ----- From: "Phil Neumiller (N9FCW)" To: "James Kempf" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 5:38 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > What makes you so sure of this James? Security concerns belong in the > security WG. I guess I have said this about 100 times now. Recall that > the charter of the WG deals with seamless mobility, not security. > > ----- Original Message ----- > From: "James Kempf" > To: "Hemant Chaskar" ; > Sent: Monday, March 18, 2002 11:07 AM > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > Hemant, > > > > The purpose of putting authentiation onf any GAAR information is > > precisely to allow a receive to trust that the information came from a > > reliable source. The only other way a receiver could determine that a > > router claiming to be a GAAR is, in fact, a GAAR would be to get > > information from another source that it trusted and compare it. But how > > would the receiver trust that? Putting a signature on the GAAR > > information and requiring a trust relationship ensures that the receiver > > can trust the GAAR information. > > > > jak > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 18 21:29:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29400 for ; Mon, 18 Mar 2002 21:29:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29057; Mon, 18 Mar 2002 21:21:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29024 for ; Mon, 18 Mar 2002 21:21:28 -0500 (EST) Received: from hotmail.com (oe49.law4.hotmail.com [216.33.148.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29268 for ; Mon, 18 Mar 2002 21:21:24 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Mar 2002 18:20:52 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 11:26:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 19 Mar 2002 02:20:52.0691 (UTC) FILETIME=[B1658A30:01C1CEEC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, Phil, I am not sure a single WG can look into all the protocols being designed in the IETF and provide proper security solutions in time. There must be lots of common requirements and possibility of using common infrastructure/tools but each protocol may also have considerations for security specific to it. And such considerations should be done at the same time when the protocol is designed, I believe. Thanks. Eunsoo ----- Original Message ----- From: "Phil Neumiller (N9FCW)" To: "James Kempf" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 5:38 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > What makes you so sure of this James? Security concerns belong in the > security WG. I guess I have said this about 100 times now. Recall that > the charter of the WG deals with seamless mobility, not security. > > ----- Original Message ----- > From: "James Kempf" > To: "Hemant Chaskar" ; > Sent: Monday, March 18, 2002 11:07 AM > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > Hemant, > > > > The purpose of putting authentiation onf any GAAR information is > > precisely to allow a receive to trust that the information came from a > > reliable source. The only other way a receiver could determine that a > > router claiming to be a GAAR is, in fact, a GAAR would be to get > > information from another source that it trusted and compare it. But how > > would the receiver trust that? Putting a signature on the GAAR > > information and requiring a trust relationship ensures that the receiver > > can trust the GAAR information. > > > > jak > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Mar 18 21:29:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29410 for ; Mon, 18 Mar 2002 21:29:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29373 for seamoby-archive@odin.ietf.org; Mon, 18 Mar 2002 21:29:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29057; Mon, 18 Mar 2002 21:21:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29024 for ; Mon, 18 Mar 2002 21:21:28 -0500 (EST) Received: from hotmail.com (oe49.law4.hotmail.com [216.33.148.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29268 for ; Mon, 18 Mar 2002 21:21:24 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Mar 2002 18:20:52 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 11:26:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 19 Mar 2002 02:20:52.0691 (UTC) FILETIME=[B1658A30:01C1CEEC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, Phil, I am not sure a single WG can look into all the protocols being designed in the IETF and provide proper security solutions in time. There must be lots of common requirements and possibility of using common infrastructure/tools but each protocol may also have considerations for security specific to it. And such considerations should be done at the same time when the protocol is designed, I believe. Thanks. Eunsoo ----- Original Message ----- From: "Phil Neumiller (N9FCW)" To: "James Kempf" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 5:38 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > What makes you so sure of this James? Security concerns belong in the > security WG. I guess I have said this about 100 times now. Recall that > the charter of the WG deals with seamless mobility, not security. > > ----- Original Message ----- > From: "James Kempf" > To: "Hemant Chaskar" ; > Sent: Monday, March 18, 2002 11:07 AM > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > Hemant, > > > > The purpose of putting authentiation onf any GAAR information is > > precisely to allow a receive to trust that the information came from a > > reliable source. The only other way a receiver could determine that a > > router claiming to be a GAAR is, in fact, a GAAR would be to get > > information from another source that it trusted and compare it. But how > > would the receiver trust that? Putting a signature on the GAAR > > information and requiring a trust relationship ensures that the receiver > > can trust the GAAR information. > > > > jak > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 09:10:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22168 for ; Tue, 19 Mar 2002 09:10:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17099; Tue, 19 Mar 2002 09:07:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17069 for ; Tue, 19 Mar 2002 09:07:47 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22091 for ; Tue, 19 Mar 2002 09:07:43 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 608E622E15 for ; Tue, 19 Mar 2002 16:05:50 +0200 (EET) Date: Tue, 19 Mar 2002 16:04:55 +0200 (EET) From: Teemu Rinta-aho To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Problem joining the list Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org How should I join this list? If I follow the instructions found at the WG home page, I only get the following: >>>> subscribe seamoby teemu.rinta-aho@nomadiclab.com **** subscribe: unknown list 'seamoby'. >>>> end END OF COMMANDS -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Mobile: +358 40 562 3066 Oy L M Ericsson Ab E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 19 09:10:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22175 for ; Tue, 19 Mar 2002 09:10:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17182 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 09:10:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17099; Tue, 19 Mar 2002 09:07:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17069 for ; Tue, 19 Mar 2002 09:07:47 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22091 for ; Tue, 19 Mar 2002 09:07:43 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 608E622E15 for ; Tue, 19 Mar 2002 16:05:50 +0200 (EET) Date: Tue, 19 Mar 2002 16:04:55 +0200 (EET) From: Teemu Rinta-aho To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Problem joining the list Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org How should I join this list? If I follow the instructions found at the WG home page, I only get the following: >>>> subscribe seamoby teemu.rinta-aho@nomadiclab.com **** subscribe: unknown list 'seamoby'. >>>> end END OF COMMANDS -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Mobile: +358 40 562 3066 Oy L M Ericsson Ab E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 19:30:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08784 for ; Tue, 19 Mar 2002 19:30:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27860; Tue, 19 Mar 2002 19:21:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27832 for ; Tue, 19 Mar 2002 19:21:48 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08643 for ; Tue, 19 Mar 2002 19:21:46 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2K0LBx22110 for ; Tue, 19 Mar 2002 18:21:12 -0600 (CST) Message-ID: <3C97D5F4.5040102@alcatel.com> Date: Tue, 19 Mar 2002 18:21:08 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting References: <012f01c1c924$e1915bd0$7e6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------050007090305010209040303" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------050007090305010209040303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jim and Pat, Is it possible to know what will be discussed in the agenda items on Paging? Myself and other colleagues have been raising several issues so far such as Requirements 4.7 and 4.8, The layering of IP Paging protocol, should we develop a framework document, etc. I asked to Pat for a slot to discuss these issues but I received no reply from him. Does this mean that the above issues will go undiscussed at the meeting? Also Srini talked about the scope which is restricted to mobile devices in the charter to which James gave the following reply: So I guess I don't see any conflict between this and accommodating fixed hosts. Is the concern that we may need to specify something at L2? If so, then be assured that we won't. There is a move afoot to start some work on defining abstract L2 triggers, but this will not involve explicit L2s and it will not be done in Seamoby. I am concerned that such attitude of arbitrary extensions of scope could drag the work to the infinity. Is this observation shared by others? Regards, James Kempf wrote: >Folks, > >Here is the agenda for the Seamboy meeting. > > >------------------------------------------------------------------------ >---------------------------------------- > >- - Agenda Bashing (co-chairs, 5 min.) > >- - Current draft status (co-chairs, 5 min.) > >- - Proposal for CT protocol selection process (co-chairs 10 minutes) > >- - Discussion of Paging and the Internet Architecture (Mystery Guest, >10 >minutes) > >- - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) > >- - Discussion of CAR Discovery and Routing Information Distribution >(Mystery Guest, 10 minutes) > >- - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 >minutes) > > draft-krishnamurthi-car-requirements-00.txt > > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet --------------050007090305010209040303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim and Pat,
  Is it possible to know what will be discussed in the agenda items on Paging?
  Myself and other colleagues have been raising several issues so far such as Requirements 4.7 and 4.8, The layering of IP Paging protocol, should we develop a framework document, etc.
I asked to Pat for a slot to discuss these issues but I received no reply from him. Does this mean that the above issues will go undiscussed at the meeting?
  Also Srini talked about the scope which is restricted to mobile devices in the charter to which James gave the following reply:

So I guess I don't see any conflict between this and accommodating fixed
hosts. Is the concern that we may need to specify something at L2? If
so, then be assured that we won't. There is a move afoot to start some
work on defining abstract L2 triggers, but this will not involve
explicit L2s and it will not be done in Seamoby.
  I am concerned that such attitude of arbitrary extensions of scope could drag the work to the infinity. Is this observation shared by others?

Regards,
James Kempf wrote:
Folks,

Here is the agenda for the Seamboy meeting.


------------------------------------------------------------------------
----------------------------------------

- - Agenda Bashing (co-chairs, 5 min.)

- - Current draft status (co-chairs, 5 min.)

- - Proposal for CT protocol selection process (co-chairs 10 minutes)

- - Discussion of Paging and the Internet Architecture (Mystery Guest,
10
minutes)

- - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes)

- - Discussion of CAR Discovery and Routing Information Distribution
(Mystery Guest, 10 minutes)

- - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40
minutes)

        draft-krishnamurthi-car-requirements-00.txt





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
<
a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/seamoby">https://www1.ietf.org/mailman/listinfo/seamoby

-- 
Behcet

--------------050007090305010209040303-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 19 19:30:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08814 for ; Tue, 19 Mar 2002 19:30:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28443 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 19:30:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27860; Tue, 19 Mar 2002 19:21:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27832 for ; Tue, 19 Mar 2002 19:21:48 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08643 for ; Tue, 19 Mar 2002 19:21:46 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2K0LBx22110 for ; Tue, 19 Mar 2002 18:21:12 -0600 (CST) Message-ID: <3C97D5F4.5040102@alcatel.com> Date: Tue, 19 Mar 2002 18:21:08 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting References: <012f01c1c924$e1915bd0$7e6015ac@T23KEMPF> Content-Type: multipart/alternative; boundary="------------050007090305010209040303" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------050007090305010209040303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jim and Pat, Is it possible to know what will be discussed in the agenda items on Paging? Myself and other colleagues have been raising several issues so far such as Requirements 4.7 and 4.8, The layering of IP Paging protocol, should we develop a framework document, etc. I asked to Pat for a slot to discuss these issues but I received no reply from him. Does this mean that the above issues will go undiscussed at the meeting? Also Srini talked about the scope which is restricted to mobile devices in the charter to which James gave the following reply: So I guess I don't see any conflict between this and accommodating fixed hosts. Is the concern that we may need to specify something at L2? If so, then be assured that we won't. There is a move afoot to start some work on defining abstract L2 triggers, but this will not involve explicit L2s and it will not be done in Seamoby. I am concerned that such attitude of arbitrary extensions of scope could drag the work to the infinity. Is this observation shared by others? Regards, James Kempf wrote: >Folks, > >Here is the agenda for the Seamboy meeting. > > >------------------------------------------------------------------------ >---------------------------------------- > >- - Agenda Bashing (co-chairs, 5 min.) > >- - Current draft status (co-chairs, 5 min.) > >- - Proposal for CT protocol selection process (co-chairs 10 minutes) > >- - Discussion of Paging and the Internet Architecture (Mystery Guest, >10 >minutes) > >- - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) > >- - Discussion of CAR Discovery and Routing Information Distribution >(Mystery Guest, 10 minutes) > >- - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 >minutes) > > draft-krishnamurthi-car-requirements-00.txt > > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > -- Behcet --------------050007090305010209040303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jim and Pat,
  Is it possible to know what will be discussed in the agenda items on Paging?
  Myself and other colleagues have been raising several issues so far such as Requirements 4.7 and 4.8, The layering of IP Paging protocol, should we develop a framework document, etc.
I asked to Pat for a slot to discuss these issues but I received no reply from him. Does this mean that the above issues will go undiscussed at the meeting?
  Also Srini talked about the scope which is restricted to mobile devices in the charter to which James gave the following reply:

So I guess I don't see any conflict between this and accommodating fixed
hosts. Is the concern that we may need to specify something at L2? If
so, then be assured that we won't. There is a move afoot to start some
work on defining abstract L2 triggers, but this will not involve
explicit L2s and it will not be done in Seamoby.
  I am concerned that such attitude of arbitrary extensions of scope could drag the work to the infinity. Is this observation shared by others?

Regards,
James Kempf wrote:
Folks,

Here is the agenda for the Seamboy meeting.


------------------------------------------------------------------------
----------------------------------------

- - Agenda Bashing (co-chairs, 5 min.)

- - Current draft status (co-chairs, 5 min.)

- - Proposal for CT protocol selection process (co-chairs 10 minutes)

- - Discussion of Paging and the Internet Architecture (Mystery Guest,
10
minutes)

- - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes)

- - Discussion of CAR Discovery and Routing Information Distribution
(Mystery Guest, 10 minutes)

- - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40
minutes)

        draft-krishnamurthi-car-requirements-00.txt





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
<
a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/seamoby">https://www1.ietf.org/mailman/listinfo/seamoby

-- 
Behcet

--------------050007090305010209040303-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 20:38:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09741 for ; Tue, 19 Mar 2002 20:38:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01180; Tue, 19 Mar 2002 20:33:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01153 for ; Tue, 19 Mar 2002 20:33:52 -0500 (EST) Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09712 for ; Tue, 19 Mar 2002 20:33:49 -0500 (EST) Received: (cpmta 11203 invoked from network); 19 Mar 2002 17:33:20 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.219) with SMTP; 19 Mar 2002 17:33:20 -0800 X-Sent: 20 Mar 2002 01:33:20 GMT Message-ID: <002e01c1cfaf$3c2070f0$0902a8c0@Study> From: "Phil Neumiller \(N9FCW\)" To: "James Kempf" Cc: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 20:33:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Thanks for the reminder Jim. I just see soooo much discussion about security in MIP and now SeaMoby that it seems to detract from the real issues sometimes and bog things down. Maybe I believe too much in security Pixie dust.... :-) BTW, there are some nice commercial options becoming available with small foot prints for embedded devices with full PKI implementations. These packages can solve many of the problems that are discussed, however, they are not necessarilly IETF created (not invented here). Is it possible to specify a level of encryption that is required and the necessary hooks and leave the implementation up to network equipment vendors/manufacturers or does the IETF have to solve the worlds problems? Best regards, -Phil ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller (N9FCW)" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 9:08 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > Phil, > > Every Internet draft is required to have a section called "Security > Considerations." This section must deal with how the particular protocol > or standard handles security. There has been a history in IETF of saying > "use IPsec" in this section (commonly called "IPsec pixie dust"), thus > putting the burden of security design for the protocol on the IPsec WG > (in effect, deferring it). In the last year, this has changed and the > IESG has been requiring that the sections contain more substance saying > specifically how the protocol will use IPsec, if the WG proposes that it > should, or explicitly describing how security is done if not. > > The theory behind pushing security back on the WG is that the WG is in a > better position to know what the security solutions are for their > particular protocol than the IPsec WG. Not that everybody in the WG > should necessarily care, but at least someone with some security > background and interest should. > > Thus, the security groups like IPsec and IKE now concern themselves > specifically with protocols that do security and not with the security > design for other protocols. It is analgous with MIBs. The SNMP working > group doesn't do MIBs for other protocols, they work on SNMP. > > jak > > PS: If you don't like it, then I'd suggest you complain at the IESG > Plenium on Thurs. nite if you are in Minneapolis, or to someone from the > IESG Security Area Directorate if not. > > > ----- Original Message ----- > From: "Phil Neumiller (N9FCW)" > To: "James Kempf" ; "Hemant Chaskar" > ; > Sent: Monday, March 18, 2002 5:38 PM > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > What makes you so sure of this James? Security concerns belong in the > > security WG. I guess I have said this about 100 times now. Recall > that > > the charter of the WG deals with seamless mobility, not security. > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Hemant Chaskar" ; > > Sent: Monday, March 18, 2002 11:07 AM > > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > > > > Hemant, > > > > > > The purpose of putting authentiation onf any GAAR information is > > > precisely to allow a receive to trust that the information came from > a > > > reliable source. The only other way a receiver could determine that > a > > > router claiming to be a GAAR is, in fact, a GAAR would be to get > > > information from another source that it trusted and compare it. But > how > > > would the receiver trust that? Putting a signature on the GAAR > > > information and requiring a trust relationship ensures that the > receiver > > > can trust the GAAR information. > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 19 20:38:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09754 for ; Tue, 19 Mar 2002 20:38:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA01268 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 20:38:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01180; Tue, 19 Mar 2002 20:33:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01153 for ; Tue, 19 Mar 2002 20:33:52 -0500 (EST) Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09712 for ; Tue, 19 Mar 2002 20:33:49 -0500 (EST) Received: (cpmta 11203 invoked from network); 19 Mar 2002 17:33:20 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.219) with SMTP; 19 Mar 2002 17:33:20 -0800 X-Sent: 20 Mar 2002 01:33:20 GMT Message-ID: <002e01c1cfaf$3c2070f0$0902a8c0@Study> From: "Phil Neumiller \(N9FCW\)" To: "James Kempf" Cc: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 20:33:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Thanks for the reminder Jim. I just see soooo much discussion about security in MIP and now SeaMoby that it seems to detract from the real issues sometimes and bog things down. Maybe I believe too much in security Pixie dust.... :-) BTW, there are some nice commercial options becoming available with small foot prints for embedded devices with full PKI implementations. These packages can solve many of the problems that are discussed, however, they are not necessarilly IETF created (not invented here). Is it possible to specify a level of encryption that is required and the necessary hooks and leave the implementation up to network equipment vendors/manufacturers or does the IETF have to solve the worlds problems? Best regards, -Phil ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller (N9FCW)" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 9:08 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > Phil, > > Every Internet draft is required to have a section called "Security > Considerations." This section must deal with how the particular protocol > or standard handles security. There has been a history in IETF of saying > "use IPsec" in this section (commonly called "IPsec pixie dust"), thus > putting the burden of security design for the protocol on the IPsec WG > (in effect, deferring it). In the last year, this has changed and the > IESG has been requiring that the sections contain more substance saying > specifically how the protocol will use IPsec, if the WG proposes that it > should, or explicitly describing how security is done if not. > > The theory behind pushing security back on the WG is that the WG is in a > better position to know what the security solutions are for their > particular protocol than the IPsec WG. Not that everybody in the WG > should necessarily care, but at least someone with some security > background and interest should. > > Thus, the security groups like IPsec and IKE now concern themselves > specifically with protocols that do security and not with the security > design for other protocols. It is analgous with MIBs. The SNMP working > group doesn't do MIBs for other protocols, they work on SNMP. > > jak > > PS: If you don't like it, then I'd suggest you complain at the IESG > Plenium on Thurs. nite if you are in Minneapolis, or to someone from the > IESG Security Area Directorate if not. > > > ----- Original Message ----- > From: "Phil Neumiller (N9FCW)" > To: "James Kempf" ; "Hemant Chaskar" > ; > Sent: Monday, March 18, 2002 5:38 PM > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > What makes you so sure of this James? Security concerns belong in the > > security WG. I guess I have said this about 100 times now. Recall > that > > the charter of the WG deals with seamless mobility, not security. > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Hemant Chaskar" ; > > Sent: Monday, March 18, 2002 11:07 AM > > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > > > > Hemant, > > > > > > The purpose of putting authentiation onf any GAAR information is > > > precisely to allow a receive to trust that the information came from > a > > > reliable source. The only other way a receiver could determine that > a > > > router claiming to be a GAAR is, in fact, a GAAR would be to get > > > information from another source that it trusted and compare it. But > how > > > would the receiver trust that? Putting a signature on the GAAR > > > information and requiring a trust relationship ensures that the > receiver > > > can trust the GAAR information. > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 20:59:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10145 for ; Tue, 19 Mar 2002 20:58:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01502; Tue, 19 Mar 2002 20:46:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01471 for ; Tue, 19 Mar 2002 20:46:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09988 for ; Tue, 19 Mar 2002 20:46:53 -0500 (EST) Received: from T23KEMPF (dhcp149.docomolabs-usa.com [172.21.96.149]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K1kOI21356; Tue, 19 Mar 2002 17:46:24 -0800 (PST) Message-ID: <006301c1cfb0$d1e0f820$956015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller \(N9FCW\)" Cc: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> <002e01c1cfaf$3c2070f0$0902a8c0@Study> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 17:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit >Is it possible > to specify a level of > encryption that is required and the necessary hooks and leave the > implementation up to > network equipment vendors/manufacturers or does the IETF have to solve the > worlds problems? > Not only is it possible, it is desirable. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 19 20:59:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10154 for ; Tue, 19 Mar 2002 20:59:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA01869 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 20:59:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01502; Tue, 19 Mar 2002 20:46:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01471 for ; Tue, 19 Mar 2002 20:46:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09988 for ; Tue, 19 Mar 2002 20:46:53 -0500 (EST) Received: from T23KEMPF (dhcp149.docomolabs-usa.com [172.21.96.149]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K1kOI21356; Tue, 19 Mar 2002 17:46:24 -0800 (PST) Message-ID: <006301c1cfb0$d1e0f820$956015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller \(N9FCW\)" Cc: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> <002e01c1cfaf$3c2070f0$0902a8c0@Study> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 17:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit >Is it possible > to specify a level of > encryption that is required and the necessary hooks and leave the > implementation up to > network equipment vendors/manufacturers or does the IETF have to solve the > worlds problems? > Not only is it possible, it is desirable. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 21:08:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10283 for ; Tue, 19 Mar 2002 21:08:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01609; Tue, 19 Mar 2002 20:51:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01581 for ; Tue, 19 Mar 2002 20:51:52 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10084 for ; Tue, 19 Mar 2002 20:51:49 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 17:51:21 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Agenda for IETF 53 Meeting Date: Tue, 19 Mar 2002 17:51:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFB1.BBDB3170" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CFB1.BBDB3170 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We will discuss the threads that have been ongoing on the list which haven't come to a resolution, such as requirements 4.7, 4.8, etc. PatC - -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Tuesday, March 19, 2002 6:21 PM Cc: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting Hi Jim and Pat, Is it possible to know what will be discussed in the agenda items on Paging? Myself and other colleagues have been raising several issues so far such as Requirements 4.7 and 4.8, The layering of IP Paging protocol, should we develop a framework document, etc. I asked to Pat for a slot to discuss these issues but I received no reply from him. Does this mean that the above issues will go undiscussed at the meeting? Also Srini talked about the scope which is restricted to mobile devices in the charter to which James gave the following reply: So I guess I don't see any conflict between this and accommodating fixed hosts. Is the concern that we may need to specify something at L2? If so, then be assured that we won't. There is a move afoot to start some work on defining abstract L2 triggers, but this will not involve explicit L2s and it will not be done in Seamoby. I am concerned that such attitude of arbitrary extensions of scope could drag the work to the infinity. Is this observation shared by others? Regards, James Kempf wrote: Folks, Here is the agenda for the Seamboy meeting. - ---------------------------------------------------------------------- - -- - ---------------------------------------- - - - Agenda Bashing (co-chairs, 5 min.) - - - Current draft status (co-chairs, 5 min.) - - - Proposal for CT protocol selection process (co-chairs 10 minutes) - - - Discussion of Paging and the Internet Architecture (Mystery Guest, 10 minutes) - - - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) - - - Discussion of CAR Discovery and Routing Information Distribution (Mystery Guest, 10 minutes) - - - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 minutes) draft-krishnamurthi-car-requirements-00.txt _______________________________________________ Seamoby mailing list Seamoby@ietf.org < a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/seamoby">https://www1.iet f.org/mailman/listinfo/seamoby - -- Behcet -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPJfrGTN1fXKoxmisEQLzagCg+BpcvJrYPrOEmvS0C1v7E4y4i+cAn1Cj 7ONAnO/vrjY+RkUqFNC5nf9g =1LzT -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1CFB1.BBDB3170 Content-Type: text/html RE: [Seamoby] Agenda for IETF 53 Meeting

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We will discuss the threads that have been ongoing on the list which
haven't come to a resolution, such as requirements 4.7, 4.8, etc.
 
PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Tuesday, March 19, 2002 6:21 PM
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Agenda for IETF 53 Meeting


Hi Jim and Pat,
  Is it possible to know what will be discussed in the agenda items
on Paging?
  Myself and other colleagues have been raising several issues so far
such as Requirements 4.7 and 4.8, The layering of IP Paging protocol,
should we develop a framework document, etc.
I asked to Pat for a slot to discuss these issues but I received no
reply from him. Does this mean that the above issues will go
undiscussed at the meeting?
  Also Srini talked about the scope which is restricted to mobile
devices in the charter to which James gave the following reply:


So I guess I don't see any conflict between this and accommodating
fixed
hosts. Is the concern that we may need to specify something at L2? If
so, then be assured that we won't. There is a move afoot to start
some
work on defining abstract L2 triggers, but this will not involve
explicit L2s and it will not be done in Seamoby.
  I am concerned that such attitude of arbitrary extensions of scope
could drag the work to the infinity. Is this observation shared by
others?

Regards,
James Kempf wrote:


Folks,

Here is the agenda for the Seamboy meeting.


- ----------------------------------------------------------------------
- --
- ----------------------------------------

- - - Agenda Bashing (co-chairs, 5 min.)

- - - Current draft status (co-chairs, 5 min.)

- - - Proposal for CT protocol selection process (co-chairs 10 minutes)

- - - Discussion of Paging and the Internet Architecture (Mystery
Guest,
10
minutes)

- - - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes)

- - - Discussion of CAR Discovery and Routing Information Distribution
(Mystery Guest, 10 minutes)

- - - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40
minutes)

        draft-krishnamurthi-car-requirements-00.txt





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
<
a class="moz-txt-link-freetext"
href="https://www1.ietf.org/mailman/listinfo/seamoby">https://www1.iet
f.org/mailman/listinfo/seamoby


- --
Behcet



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPJfrGTN1fXKoxmisEQLzagCg+BpcvJrYPrOEmvS0C1v7E4y4i+cAn1Cj
7ONAnO/vrjY+RkUqFNC5nf9g
=1LzT
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1CFB1.BBDB3170-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 19 21:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10291 for ; Tue, 19 Mar 2002 21:08:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02509 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 21:08:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01609; Tue, 19 Mar 2002 20:51:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01581 for ; Tue, 19 Mar 2002 20:51:52 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10084 for ; Tue, 19 Mar 2002 20:51:49 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 17:51:21 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Behcet Sarikaya'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Agenda for IETF 53 Meeting Date: Tue, 19 Mar 2002 17:51:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFB1.BBDB3170" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CFB1.BBDB3170 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We will discuss the threads that have been ongoing on the list which haven't come to a resolution, such as requirements 4.7, 4.8, etc. PatC - -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Tuesday, March 19, 2002 6:21 PM Cc: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting Hi Jim and Pat, Is it possible to know what will be discussed in the agenda items on Paging? Myself and other colleagues have been raising several issues so far such as Requirements 4.7 and 4.8, The layering of IP Paging protocol, should we develop a framework document, etc. I asked to Pat for a slot to discuss these issues but I received no reply from him. Does this mean that the above issues will go undiscussed at the meeting? Also Srini talked about the scope which is restricted to mobile devices in the charter to which James gave the following reply: So I guess I don't see any conflict between this and accommodating fixed hosts. Is the concern that we may need to specify something at L2? If so, then be assured that we won't. There is a move afoot to start some work on defining abstract L2 triggers, but this will not involve explicit L2s and it will not be done in Seamoby. I am concerned that such attitude of arbitrary extensions of scope could drag the work to the infinity. Is this observation shared by others? Regards, James Kempf wrote: Folks, Here is the agenda for the Seamboy meeting. - ---------------------------------------------------------------------- - -- - ---------------------------------------- - - - Agenda Bashing (co-chairs, 5 min.) - - - Current draft status (co-chairs, 5 min.) - - - Proposal for CT protocol selection process (co-chairs 10 minutes) - - - Discussion of Paging and the Internet Architecture (Mystery Guest, 10 minutes) - - - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes) - - - Discussion of CAR Discovery and Routing Information Distribution (Mystery Guest, 10 minutes) - - - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40 minutes) draft-krishnamurthi-car-requirements-00.txt _______________________________________________ Seamoby mailing list Seamoby@ietf.org < a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/seamoby">https://www1.iet f.org/mailman/listinfo/seamoby - -- Behcet -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPJfrGTN1fXKoxmisEQLzagCg+BpcvJrYPrOEmvS0C1v7E4y4i+cAn1Cj 7ONAnO/vrjY+RkUqFNC5nf9g =1LzT -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1CFB1.BBDB3170 Content-Type: text/html RE: [Seamoby] Agenda for IETF 53 Meeting

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We will discuss the threads that have been ongoing on the list which
haven't come to a resolution, such as requirements 4.7, 4.8, etc.
 
PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Tuesday, March 19, 2002 6:21 PM
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Agenda for IETF 53 Meeting


Hi Jim and Pat,
  Is it possible to know what will be discussed in the agenda items
on Paging?
  Myself and other colleagues have been raising several issues so far
such as Requirements 4.7 and 4.8, The layering of IP Paging protocol,
should we develop a framework document, etc.
I asked to Pat for a slot to discuss these issues but I received no
reply from him. Does this mean that the above issues will go
undiscussed at the meeting?
  Also Srini talked about the scope which is restricted to mobile
devices in the charter to which James gave the following reply:


So I guess I don't see any conflict between this and accommodating
fixed
hosts. Is the concern that we may need to specify something at L2? If
so, then be assured that we won't. There is a move afoot to start
some
work on defining abstract L2 triggers, but this will not involve
explicit L2s and it will not be done in Seamoby.
  I am concerned that such attitude of arbitrary extensions of scope
could drag the work to the infinity. Is this observation shared by
others?

Regards,
James Kempf wrote:


Folks,

Here is the agenda for the Seamboy meeting.


- ----------------------------------------------------------------------
- --
- ----------------------------------------

- - - Agenda Bashing (co-chairs, 5 min.)

- - - Current draft status (co-chairs, 5 min.)

- - - Proposal for CT protocol selection process (co-chairs 10 minutes)

- - - Discussion of Paging and the Internet Architecture (Mystery
Guest,
10
minutes)

- - - Paging Technical Issues Discussion (Marco Liebsch, 40 minutes)

- - - Discussion of CAR Discovery and Routing Information Distribution
(Mystery Guest, 10 minutes)

- - - CAR Discovery Requirements Discussion (Govind Krishnamurthi, 40
minutes)

        draft-krishnamurthi-car-requirements-00.txt





_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
<
a class="moz-txt-link-freetext"
href="https://www1.ietf.org/mailman/listinfo/seamoby">https://www1.iet
f.org/mailman/listinfo/seamoby


- --
Behcet



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPJfrGTN1fXKoxmisEQLzagCg+BpcvJrYPrOEmvS0C1v7E4y4i+cAn1Cj
7ONAnO/vrjY+RkUqFNC5nf9g
=1LzT
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1CFB1.BBDB3170-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 21:09:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10328 for ; Tue, 19 Mar 2002 21:09:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01825; Tue, 19 Mar 2002 20:57:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01758 for ; Tue, 19 Mar 2002 20:57:17 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10121 for ; Tue, 19 Mar 2002 20:57:14 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 17:56:46 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Phil Neumiller (N9FCW)'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 17:56:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFB2.7D6D06B0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CFB2.7D6D06B0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That is certainly one option, but not specifying the exact details of how to secure the protocol leads to interoperability problems among vendors - not something we really want in a truly mobile world. PatC - -----Original Message----- From: Phil Neumiller (N9FCW) [mailto:pneumiller@directvinternet.com] Sent: Tuesday, March 19, 2002 7:33 PM To: James Kempf Cc: seamoby@ietf.org Subject: Re: [Seamoby] Verifying that a sender is a GAAR Thanks for the reminder Jim. I just see soooo much discussion about security in MIP and now SeaMoby that it seems to detract from the real issues sometimes and bog things down. Maybe I believe too much in security Pixie dust.... :-) BTW, there are some nice commercial options becoming available with small foot prints for embedded devices with full PKI implementations. These packages can solve many of the problems that are discussed, however, they are not necessarilly IETF created (not invented here). Is it possible to specify a level of encryption that is required and the necessary hooks and leave the implementation up to network equipment vendors/manufacturers or does the IETF have to solve the worlds problems? Best regards, - -Phil - ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller (N9FCW)" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 9:08 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > Phil, > > Every Internet draft is required to have a section called "Security > Considerations." This section must deal with how the particular > protocol or standard handles security. There has been a history in > IETF of saying "use IPsec" in this section (commonly called "IPsec > pixie dust"), thus putting the burden of security design for the > protocol on the IPsec WG (in effect, deferring it). In the last > year, this has changed and the IESG has been requiring that the > sections contain more substance saying specifically how the > protocol will use IPsec, if the WG proposes that it should, or > explicitly describing how security is done if not. > > The theory behind pushing security back on the WG is that the WG is > in a better position to know what the security solutions are for > their particular protocol than the IPsec WG. Not that everybody in > the WG should necessarily care, but at least someone with some > security > background and interest should. > > Thus, the security groups like IPsec and IKE now concern themselves > specifically with protocols that do security and not with the > security design for other protocols. It is analgous with MIBs. The > SNMP working group doesn't do MIBs for other protocols, they work > on SNMP. > > jak > > PS: If you don't like it, then I'd suggest you complain at the IESG > Plenium on Thurs. nite if you are in Minneapolis, or to someone > from the IESG Security Area Directorate if not. > > > ----- Original Message ----- > From: "Phil Neumiller (N9FCW)" > To: "James Kempf" ; "Hemant Chaskar" > ; > Sent: Monday, March 18, 2002 5:38 PM > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > What makes you so sure of this James? Security concerns belong > > in the security WG. I guess I have said this about 100 times > > now. Recall > that > > the charter of the WG deals with seamless mobility, not security. > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Hemant Chaskar" ; > > Sent: Monday, March 18, 2002 11:07 AM > > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > > > > Hemant, > > > > > > The purpose of putting authentiation onf any GAAR information > > > is precisely to allow a receive to trust that the information > > > came from > a > > > reliable source. The only other way a receiver could determine > > > that > a > > > router claiming to be a GAAR is, in fact, a GAAR would be to > > > get information from another source that it trusted and > > > compare it. But > how > > > would the receiver trust that? Putting a signature on the GAAR > > > information and requiring a trust relationship ensures that the > receiver > > > can trust the GAAR information. > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPJfsXjN1fXKoxmisEQLFmgCg407t8iQdVMy+7IgUAJdVSejZ2soAnRMf qhuQOG7rWHQVpRNRXatM43vz =QOIx -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1CFB2.7D6D06B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Verifying that a sender is a GAAR

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That is certainly one option, but not specifying the = exact details of
how to secure the protocol leads to interoperability = problems among
vendors - not something we really want in a truly = mobile world.

PatC

- -----Original Message-----
From: Phil Neumiller (N9FCW) [mailto:pneumiller@directv= internet.com]
Sent: Tuesday, March 19, 2002 7:33 PM
To: James Kempf
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Verifying that a sender is a = GAAR


Thanks for the reminder Jim.  I just see soooo = much discussion about
security in MIP and now SeaMoby that it seems to = detract from the
real issues sometimes and bog things down.
Maybe I believe too much in security Pixie dust.... = :-)    BTW, there
are
some nice commercial
options becoming available with small foot prints = for embedded
devices with full PKI implementations.  These = packages can solve many
of the problems that are discussed, however, they = are not
necessarilly IETF created (not invented here).  = Is it possible to
specify a level of encryption that is required and = the necessary
hooks and leave the implementation up to network = equipment
vendors/manufacturers or does the IETF have to solve = the worlds
problems?

Best regards,

- -Phil
- ----- Original Message -----
From: "James Kempf" = <kempf@docomolabs-usa.com>
To: "Phil Neumiller (N9FCW)" = <pneumiller@directvinternet.com>;
"Hemant Chaskar" = <hchaskar@hotmail.com>; <seamoby@ietf.org>
Sent: Monday, March 18, 2002 9:08 PM
Subject: Re: [Seamoby] Verifying that a sender is a = GAAR


> Phil,
>
> Every Internet draft is required to have a = section called "Security
>  Considerations." This section must = deal with how the particular
> protocol or standard handles security. There = has been a history in
> IETF of saying "use IPsec" in this = section (commonly called "IPsec
> pixie dust"), thus putting the burden of = security design for the
> protocol on the IPsec WG (in effect, deferring = it). In the last
> year,  this has changed and the IESG has = been requiring that the
> sections  contain more substance saying = specifically how the
> protocol will use  IPsec, if the WG = proposes that it should, or
> explicitly describing how  security is = done if not.
>
> The theory behind pushing security back on the = WG is that the WG is
> in  a better position to know what the = security solutions are for
> their  particular protocol than the IPsec = WG. Not that everybody in
> the WG  should necessarily care, but at = least someone with some
> security
> background and interest should.
>
> Thus, the security groups like IPsec and IKE = now concern themselves
>  specifically with protocols that do = security and not with the
> security  design for other protocols. It = is analgous with MIBs. The
> SNMP working  group doesn't do MIBs for = other protocols, they work
> on SNMP.
>
>          = ;   jak
>
> PS: If you don't like it, then I'd suggest you = complain at the IESG
>  Plenium on Thurs. nite if you are in = Minneapolis, or to someone
> from  the IESG  Security Area = Directorate if not.
>
>
> ----- Original Message -----
> From: "Phil Neumiller (N9FCW)" = <pneumiller@directvinternet.com>
> To: "James Kempf" = <kempf@docomolabs-usa.com>; "Hemant Chaskar"
> <hchaskar@hotmail.com>; = <seamoby@ietf.org>
> Sent: Monday, March 18, 2002 5:38 PM
> Subject: Re: [Seamoby] Verifying that a sender = is a GAAR
>
>
> > What makes you so sure of this = James?  Security concerns belong
> > in the security WG.   I = guess  I have said this about 100 times
> > now.  Recall
> that
> > the charter of the WG deals with seamless = mobility, not security.
> >
> > ----- Original Message -----
> > From: "James Kempf" = <kempf@docomolabs-usa.com>
> > To: "Hemant Chaskar" = <hchaskar@hotmail.com>; <seamoby@ietf.org>
> > Sent: Monday, March 18, 2002 11:07 = AM
> > Subject: [Seamoby] Verifying that a sender = is a GAAR
> >
> >
> > > Hemant,
> > >
> > > The purpose of putting authentiation = onf any GAAR information
> > > is  precisely to allow a receive = to trust that the information
> > > came  from
> a
> > > reliable source. The only other way a = receiver could determine
> > > that
> a
> > > router claiming to be a GAAR is, in = fact, a GAAR would be to
> > > get  information from another = source that it trusted and
> > > compare it.  But
> how
> > > would the receiver trust that? = Putting a signature on the GAAR
> > > information and requiring a trust = relationship ensures that the
> receiver
> > > can trust the GAAR = information.
> > >
> > = >           &n= bsp; jak
> > >
> > >
> > >
> > > = _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
> >
> >
> >
>
>
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPJfsXjN1fXKoxmisEQLFmgCg407t8iQdVMy+7IgUAJdVSejZ2soAnRM= f
qhuQOG7rWHQVpRNRXatM43vz
=3DQOIx
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1CFB2.7D6D06B0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 19 21:09:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10341 for ; Tue, 19 Mar 2002 21:09:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02538 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 21:09:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01825; Tue, 19 Mar 2002 20:57:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01758 for ; Tue, 19 Mar 2002 20:57:17 -0500 (EST) Received: from EXCHSRV.stormventures.com ([65.107.25.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10121 for ; Tue, 19 Mar 2002 20:57:14 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 17:56:46 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Phil Neumiller (N9FCW)'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 17:56:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFB2.7D6D06B0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CFB2.7D6D06B0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That is certainly one option, but not specifying the exact details of how to secure the protocol leads to interoperability problems among vendors - not something we really want in a truly mobile world. PatC - -----Original Message----- From: Phil Neumiller (N9FCW) [mailto:pneumiller@directvinternet.com] Sent: Tuesday, March 19, 2002 7:33 PM To: James Kempf Cc: seamoby@ietf.org Subject: Re: [Seamoby] Verifying that a sender is a GAAR Thanks for the reminder Jim. I just see soooo much discussion about security in MIP and now SeaMoby that it seems to detract from the real issues sometimes and bog things down. Maybe I believe too much in security Pixie dust.... :-) BTW, there are some nice commercial options becoming available with small foot prints for embedded devices with full PKI implementations. These packages can solve many of the problems that are discussed, however, they are not necessarilly IETF created (not invented here). Is it possible to specify a level of encryption that is required and the necessary hooks and leave the implementation up to network equipment vendors/manufacturers or does the IETF have to solve the worlds problems? Best regards, - -Phil - ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller (N9FCW)" ; "Hemant Chaskar" ; Sent: Monday, March 18, 2002 9:08 PM Subject: Re: [Seamoby] Verifying that a sender is a GAAR > Phil, > > Every Internet draft is required to have a section called "Security > Considerations." This section must deal with how the particular > protocol or standard handles security. There has been a history in > IETF of saying "use IPsec" in this section (commonly called "IPsec > pixie dust"), thus putting the burden of security design for the > protocol on the IPsec WG (in effect, deferring it). In the last > year, this has changed and the IESG has been requiring that the > sections contain more substance saying specifically how the > protocol will use IPsec, if the WG proposes that it should, or > explicitly describing how security is done if not. > > The theory behind pushing security back on the WG is that the WG is > in a better position to know what the security solutions are for > their particular protocol than the IPsec WG. Not that everybody in > the WG should necessarily care, but at least someone with some > security > background and interest should. > > Thus, the security groups like IPsec and IKE now concern themselves > specifically with protocols that do security and not with the > security design for other protocols. It is analgous with MIBs. The > SNMP working group doesn't do MIBs for other protocols, they work > on SNMP. > > jak > > PS: If you don't like it, then I'd suggest you complain at the IESG > Plenium on Thurs. nite if you are in Minneapolis, or to someone > from the IESG Security Area Directorate if not. > > > ----- Original Message ----- > From: "Phil Neumiller (N9FCW)" > To: "James Kempf" ; "Hemant Chaskar" > ; > Sent: Monday, March 18, 2002 5:38 PM > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > What makes you so sure of this James? Security concerns belong > > in the security WG. I guess I have said this about 100 times > > now. Recall > that > > the charter of the WG deals with seamless mobility, not security. > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Hemant Chaskar" ; > > Sent: Monday, March 18, 2002 11:07 AM > > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > > > > Hemant, > > > > > > The purpose of putting authentiation onf any GAAR information > > > is precisely to allow a receive to trust that the information > > > came from > a > > > reliable source. The only other way a receiver could determine > > > that > a > > > router claiming to be a GAAR is, in fact, a GAAR would be to > > > get information from another source that it trusted and > > > compare it. But > how > > > would the receiver trust that? Putting a signature on the GAAR > > > information and requiring a trust relationship ensures that the > receiver > > > can trust the GAAR information. > > > > > > jak > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPJfsXjN1fXKoxmisEQLFmgCg407t8iQdVMy+7IgUAJdVSejZ2soAnRMf qhuQOG7rWHQVpRNRXatM43vz =QOIx -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1CFB2.7D6D06B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Verifying that a sender is a GAAR

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That is certainly one option, but not specifying the = exact details of
how to secure the protocol leads to interoperability = problems among
vendors - not something we really want in a truly = mobile world.

PatC

- -----Original Message-----
From: Phil Neumiller (N9FCW) [mailto:pneumiller@directv= internet.com]
Sent: Tuesday, March 19, 2002 7:33 PM
To: James Kempf
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] Verifying that a sender is a = GAAR


Thanks for the reminder Jim.  I just see soooo = much discussion about
security in MIP and now SeaMoby that it seems to = detract from the
real issues sometimes and bog things down.
Maybe I believe too much in security Pixie dust.... = :-)    BTW, there
are
some nice commercial
options becoming available with small foot prints = for embedded
devices with full PKI implementations.  These = packages can solve many
of the problems that are discussed, however, they = are not
necessarilly IETF created (not invented here).  = Is it possible to
specify a level of encryption that is required and = the necessary
hooks and leave the implementation up to network = equipment
vendors/manufacturers or does the IETF have to solve = the worlds
problems?

Best regards,

- -Phil
- ----- Original Message -----
From: "James Kempf" = <kempf@docomolabs-usa.com>
To: "Phil Neumiller (N9FCW)" = <pneumiller@directvinternet.com>;
"Hemant Chaskar" = <hchaskar@hotmail.com>; <seamoby@ietf.org>
Sent: Monday, March 18, 2002 9:08 PM
Subject: Re: [Seamoby] Verifying that a sender is a = GAAR


> Phil,
>
> Every Internet draft is required to have a = section called "Security
>  Considerations." This section must = deal with how the particular
> protocol or standard handles security. There = has been a history in
> IETF of saying "use IPsec" in this = section (commonly called "IPsec
> pixie dust"), thus putting the burden of = security design for the
> protocol on the IPsec WG (in effect, deferring = it). In the last
> year,  this has changed and the IESG has = been requiring that the
> sections  contain more substance saying = specifically how the
> protocol will use  IPsec, if the WG = proposes that it should, or
> explicitly describing how  security is = done if not.
>
> The theory behind pushing security back on the = WG is that the WG is
> in  a better position to know what the = security solutions are for
> their  particular protocol than the IPsec = WG. Not that everybody in
> the WG  should necessarily care, but at = least someone with some
> security
> background and interest should.
>
> Thus, the security groups like IPsec and IKE = now concern themselves
>  specifically with protocols that do = security and not with the
> security  design for other protocols. It = is analgous with MIBs. The
> SNMP working  group doesn't do MIBs for = other protocols, they work
> on SNMP.
>
>          = ;   jak
>
> PS: If you don't like it, then I'd suggest you = complain at the IESG
>  Plenium on Thurs. nite if you are in = Minneapolis, or to someone
> from  the IESG  Security Area = Directorate if not.
>
>
> ----- Original Message -----
> From: "Phil Neumiller (N9FCW)" = <pneumiller@directvinternet.com>
> To: "James Kempf" = <kempf@docomolabs-usa.com>; "Hemant Chaskar"
> <hchaskar@hotmail.com>; = <seamoby@ietf.org>
> Sent: Monday, March 18, 2002 5:38 PM
> Subject: Re: [Seamoby] Verifying that a sender = is a GAAR
>
>
> > What makes you so sure of this = James?  Security concerns belong
> > in the security WG.   I = guess  I have said this about 100 times
> > now.  Recall
> that
> > the charter of the WG deals with seamless = mobility, not security.
> >
> > ----- Original Message -----
> > From: "James Kempf" = <kempf@docomolabs-usa.com>
> > To: "Hemant Chaskar" = <hchaskar@hotmail.com>; <seamoby@ietf.org>
> > Sent: Monday, March 18, 2002 11:07 = AM
> > Subject: [Seamoby] Verifying that a sender = is a GAAR
> >
> >
> > > Hemant,
> > >
> > > The purpose of putting authentiation = onf any GAAR information
> > > is  precisely to allow a receive = to trust that the information
> > > came  from
> a
> > > reliable source. The only other way a = receiver could determine
> > > that
> a
> > > router claiming to be a GAAR is, in = fact, a GAAR would be to
> > > get  information from another = source that it trusted and
> > > compare it.  But
> how
> > > would the receiver trust that? = Putting a signature on the GAAR
> > > information and requiring a trust = relationship ensures that the
> receiver
> > > can trust the GAAR = information.
> > >
> > = >           &n= bsp; jak
> > >
> > >
> > >
> > > = _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
> >
> >
> >
>
>
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPJfsXjN1fXKoxmisEQLFmgCg407t8iQdVMy+7IgUAJdVSejZ2soAnRM= f
qhuQOG7rWHQVpRNRXatM43vz
=3DQOIx
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1CFB2.7D6D06B0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 21:22:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10535 for ; Tue, 19 Mar 2002 21:22:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02719; Tue, 19 Mar 2002 21:15:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02690 for ; Tue, 19 Mar 2002 21:15:23 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10419 for ; Tue, 19 Mar 2002 21:15:16 -0500 (EST) Received: from T23KEMPF ([172.21.96.179]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K2ElI22212; Tue, 19 Mar 2002 18:14:47 -0800 (PST) Message-ID: <008601c1cfb4$c92606e0$956015ac@T23KEMPF> From: "James Kempf" To: "Pat R. Calhoun" , "'Phil Neumiller \(N9FCW\)'" Cc: References: Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 18:13:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > That is certainly one option, but not specifying the exact details of > how to secure the protocol leads to interoperability problems among > vendors - not something we really want in a truly mobile world. > The level of specification has to be up to interoperability, so that vendors can provide interoperable implementations. jak > PatC > > - -----Original Message----- > From: Phil Neumiller (N9FCW) [mailto:pneumiller@directvinternet.com] > Sent: Tuesday, March 19, 2002 7:33 PM > To: James Kempf > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > Thanks for the reminder Jim. I just see soooo much discussion about > security in MIP and now SeaMoby that it seems to detract from the > real issues sometimes and bog things down. > Maybe I believe too much in security Pixie dust.... :-) BTW, there > are > some nice commercial > options becoming available with small foot prints for embedded > devices with full PKI implementations. These packages can solve many > of the problems that are discussed, however, they are not > necessarilly IETF created (not invented here). Is it possible to > specify a level of encryption that is required and the necessary > hooks and leave the implementation up to network equipment > vendors/manufacturers or does the IETF have to solve the worlds > problems? > > Best regards, > > - -Phil > - ----- Original Message ----- > From: "James Kempf" > To: "Phil Neumiller (N9FCW)" ; > "Hemant Chaskar" ; > Sent: Monday, March 18, 2002 9:08 PM > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > Phil, > > > > Every Internet draft is required to have a section called "Security > > Considerations." This section must deal with how the particular > > protocol or standard handles security. There has been a history in > > IETF of saying "use IPsec" in this section (commonly called "IPsec > > pixie dust"), thus putting the burden of security design for the > > protocol on the IPsec WG (in effect, deferring it). In the last > > year, this has changed and the IESG has been requiring that the > > sections contain more substance saying specifically how the > > protocol will use IPsec, if the WG proposes that it should, or > > explicitly describing how security is done if not. > > > > The theory behind pushing security back on the WG is that the WG is > > in a better position to know what the security solutions are for > > their particular protocol than the IPsec WG. Not that everybody in > > the WG should necessarily care, but at least someone with some > > security > > background and interest should. > > > > Thus, the security groups like IPsec and IKE now concern themselves > > specifically with protocols that do security and not with the > > security design for other protocols. It is analgous with MIBs. The > > SNMP working group doesn't do MIBs for other protocols, they work > > on SNMP. > > > > jak > > > > PS: If you don't like it, then I'd suggest you complain at the IESG > > Plenium on Thurs. nite if you are in Minneapolis, or to someone > > from the IESG Security Area Directorate if not. > > > > > > ----- Original Message ----- > > From: "Phil Neumiller (N9FCW)" > > To: "James Kempf" ; "Hemant Chaskar" > > ; > > Sent: Monday, March 18, 2002 5:38 PM > > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > > > > What makes you so sure of this James? Security concerns belong > > > in the security WG. I guess I have said this about 100 times > > > now. Recall > > that > > > the charter of the WG deals with seamless mobility, not security. > > > > > > ----- Original Message ----- > > > From: "James Kempf" > > > To: "Hemant Chaskar" ; > > > Sent: Monday, March 18, 2002 11:07 AM > > > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > > > > > > > Hemant, > > > > > > > > The purpose of putting authentiation onf any GAAR information > > > > is precisely to allow a receive to trust that the information > > > > came from > > a > > > > reliable source. The only other way a receiver could determine > > > > that > > a > > > > router claiming to be a GAAR is, in fact, a GAAR would be to > > > > get information from another source that it trusted and > > > > compare it. But > > how > > > > would the receiver trust that? Putting a signature on the GAAR > > > > information and requiring a trust relationship ensures that the > > receiver > > > > can trust the GAAR information. > > > > > > > > jak > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPJfsXjN1fXKoxmisEQLFmgCg407t8iQdVMy+7IgUAJdVSejZ2soAnRMf > qhuQOG7rWHQVpRNRXatM43vz > =QOIx > -----END PGP SIGNATURE----- > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 19 21:22:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10545 for ; Tue, 19 Mar 2002 21:22:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02832 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 21:22:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02719; Tue, 19 Mar 2002 21:15:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02690 for ; Tue, 19 Mar 2002 21:15:23 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10419 for ; Tue, 19 Mar 2002 21:15:16 -0500 (EST) Received: from T23KEMPF ([172.21.96.179]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K2ElI22212; Tue, 19 Mar 2002 18:14:47 -0800 (PST) Message-ID: <008601c1cfb4$c92606e0$956015ac@T23KEMPF> From: "James Kempf" To: "Pat R. Calhoun" , "'Phil Neumiller \(N9FCW\)'" Cc: References: Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 18:13:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > That is certainly one option, but not specifying the exact details of > how to secure the protocol leads to interoperability problems among > vendors - not something we really want in a truly mobile world. > The level of specification has to be up to interoperability, so that vendors can provide interoperable implementations. jak > PatC > > - -----Original Message----- > From: Phil Neumiller (N9FCW) [mailto:pneumiller@directvinternet.com] > Sent: Tuesday, March 19, 2002 7:33 PM > To: James Kempf > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > Thanks for the reminder Jim. I just see soooo much discussion about > security in MIP and now SeaMoby that it seems to detract from the > real issues sometimes and bog things down. > Maybe I believe too much in security Pixie dust.... :-) BTW, there > are > some nice commercial > options becoming available with small foot prints for embedded > devices with full PKI implementations. These packages can solve many > of the problems that are discussed, however, they are not > necessarilly IETF created (not invented here). Is it possible to > specify a level of encryption that is required and the necessary > hooks and leave the implementation up to network equipment > vendors/manufacturers or does the IETF have to solve the worlds > problems? > > Best regards, > > - -Phil > - ----- Original Message ----- > From: "James Kempf" > To: "Phil Neumiller (N9FCW)" ; > "Hemant Chaskar" ; > Sent: Monday, March 18, 2002 9:08 PM > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > Phil, > > > > Every Internet draft is required to have a section called "Security > > Considerations." This section must deal with how the particular > > protocol or standard handles security. There has been a history in > > IETF of saying "use IPsec" in this section (commonly called "IPsec > > pixie dust"), thus putting the burden of security design for the > > protocol on the IPsec WG (in effect, deferring it). In the last > > year, this has changed and the IESG has been requiring that the > > sections contain more substance saying specifically how the > > protocol will use IPsec, if the WG proposes that it should, or > > explicitly describing how security is done if not. > > > > The theory behind pushing security back on the WG is that the WG is > > in a better position to know what the security solutions are for > > their particular protocol than the IPsec WG. Not that everybody in > > the WG should necessarily care, but at least someone with some > > security > > background and interest should. > > > > Thus, the security groups like IPsec and IKE now concern themselves > > specifically with protocols that do security and not with the > > security design for other protocols. It is analgous with MIBs. The > > SNMP working group doesn't do MIBs for other protocols, they work > > on SNMP. > > > > jak > > > > PS: If you don't like it, then I'd suggest you complain at the IESG > > Plenium on Thurs. nite if you are in Minneapolis, or to someone > > from the IESG Security Area Directorate if not. > > > > > > ----- Original Message ----- > > From: "Phil Neumiller (N9FCW)" > > To: "James Kempf" ; "Hemant Chaskar" > > ; > > Sent: Monday, March 18, 2002 5:38 PM > > Subject: Re: [Seamoby] Verifying that a sender is a GAAR > > > > > > > What makes you so sure of this James? Security concerns belong > > > in the security WG. I guess I have said this about 100 times > > > now. Recall > > that > > > the charter of the WG deals with seamless mobility, not security. > > > > > > ----- Original Message ----- > > > From: "James Kempf" > > > To: "Hemant Chaskar" ; > > > Sent: Monday, March 18, 2002 11:07 AM > > > Subject: [Seamoby] Verifying that a sender is a GAAR > > > > > > > > > > Hemant, > > > > > > > > The purpose of putting authentiation onf any GAAR information > > > > is precisely to allow a receive to trust that the information > > > > came from > > a > > > > reliable source. The only other way a receiver could determine > > > > that > > a > > > > router claiming to be a GAAR is, in fact, a GAAR would be to > > > > get information from another source that it trusted and > > > > compare it. But > > how > > > > would the receiver trust that? Putting a signature on the GAAR > > > > information and requiring a trust relationship ensures that the > > receiver > > > > can trust the GAAR information. > > > > > > > > jak > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPJfsXjN1fXKoxmisEQLFmgCg407t8iQdVMy+7IgUAJdVSejZ2soAnRMf > qhuQOG7rWHQVpRNRXatM43vz > =QOIx > -----END PGP SIGNATURE----- > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 19 22:39:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13514 for ; Tue, 19 Mar 2002 22:39:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05830; Tue, 19 Mar 2002 22:35:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05805 for ; Tue, 19 Mar 2002 22:35:21 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13459 for ; Tue, 19 Mar 2002 22:35:17 -0500 (EST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K3YnI23840; Tue, 19 Mar 2002 19:34:49 -0800 (PST) Message-ID: <00c301c1cfbf$f70b4a60$956015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , "Phil Neumiller \(N9FCW\)" Cc: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> <002e01c1cfaf$3c2070f0$0902a8c0@Study> <006301c1cfb0$d1e0f820$956015ac@T23KEMPF> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 19:33:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >Is it possible > > to specify a level of > > encryption that is required and the necessary hooks and leave the > > implementation up to > > network equipment vendors/manufacturers or does the IETF have to solve > the > > worlds problems? > > > > Not only is it possible, it is desirable. > All right, there seems to be some misunderstanding about my response, based on the private email I'm getting. The level of detail in the security part of the specification has to be high enough that it is possible to implement the specification so that it interoperates. Thus, it is possible to allow vendors to add value in areas such as, for example, the cryptographic algorithms. It is desirable because progress in cryptographic alogrithms is constant, so specifying one single cryptographic algorithm risks having the spec quickly become obsolete (or crackable, given increases in computing power). Additionally, it is very desirable to specify defaults that are nonIPR encumbered, while leaving space for other algorithms that may have IPR. Thus, specifying DES with the option for RSA (though I guess now the patent has expired on RSA, so it is not a good example) or another proprietary algorithm is an example. Of course, if there is no good nonIPR encumbered alternative, then there is no choice. Hope that is clearer... jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 19 22:39:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13523 for ; Tue, 19 Mar 2002 22:39:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA06027 for seamoby-archive@odin.ietf.org; Tue, 19 Mar 2002 22:39:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05830; Tue, 19 Mar 2002 22:35:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05805 for ; Tue, 19 Mar 2002 22:35:21 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13459 for ; Tue, 19 Mar 2002 22:35:17 -0500 (EST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K3YnI23840; Tue, 19 Mar 2002 19:34:49 -0800 (PST) Message-ID: <00c301c1cfbf$f70b4a60$956015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , "Phil Neumiller \(N9FCW\)" Cc: References: <002401c1ce97$01708760$566015ac@T23KEMPF> <001c01c1cee6$c3b789f0$0902a8c0@Study> <000501c1ceea$f61fc1b0$566015ac@T23KEMPF> <002e01c1cfaf$3c2070f0$0902a8c0@Study> <006301c1cfb0$d1e0f820$956015ac@T23KEMPF> Subject: Re: [Seamoby] Verifying that a sender is a GAAR Date: Tue, 19 Mar 2002 19:33:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >Is it possible > > to specify a level of > > encryption that is required and the necessary hooks and leave the > > implementation up to > > network equipment vendors/manufacturers or does the IETF have to solve > the > > worlds problems? > > > > Not only is it possible, it is desirable. > All right, there seems to be some misunderstanding about my response, based on the private email I'm getting. The level of detail in the security part of the specification has to be high enough that it is possible to implement the specification so that it interoperates. Thus, it is possible to allow vendors to add value in areas such as, for example, the cryptographic algorithms. It is desirable because progress in cryptographic alogrithms is constant, so specifying one single cryptographic algorithm risks having the spec quickly become obsolete (or crackable, given increases in computing power). Additionally, it is very desirable to specify defaults that are nonIPR encumbered, while leaving space for other algorithms that may have IPR. Thus, specifying DES with the option for RSA (though I guess now the patent has expired on RSA, so it is not a good example) or another proprietary algorithm is an example. Of course, if there is no good nonIPR encumbered alternative, then there is no choice. Hope that is clearer... jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 20 23:50:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26156 for ; Wed, 20 Mar 2002 23:50:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05409; Wed, 20 Mar 2002 23:46:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05380 for ; Wed, 20 Mar 2002 23:46:54 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26086 for ; Wed, 20 Mar 2002 23:46:49 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2L4kLx22187 for ; Wed, 20 Mar 2002 22:46:21 -0600 (CST) Message-ID: <3C99659A.7020702@alcatel.com> Date: Wed, 20 Mar 2002 22:46:18 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting References: Content-Type: multipart/alternative; boundary="------------020104040905010900060207" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------020104040905010900060207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We will discuss the threads that have been ongoing on the list which > haven't come to a resolution, such as requirements 4.7, 4.8, etc. > > I don't think so. > --behcet --------------020104040905010900060207 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Pat R. Calhoun wrote:
RE: [Seamoby] Agenda for IETF 53 Meeting

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We will discuss the threads that have been ongoing on the list which
haven't come to a resolution, such as requirements 4.7, 4.8, etc.
 

I don't think so.


--behcet
--------------020104040905010900060207-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 20 23:50:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26166 for ; Wed, 20 Mar 2002 23:50:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA05504 for seamoby-archive@odin.ietf.org; Wed, 20 Mar 2002 23:50:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05409; Wed, 20 Mar 2002 23:46:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05380 for ; Wed, 20 Mar 2002 23:46:54 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26086 for ; Wed, 20 Mar 2002 23:46:49 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2L4kLx22187 for ; Wed, 20 Mar 2002 22:46:21 -0600 (CST) Message-ID: <3C99659A.7020702@alcatel.com> Date: Wed, 20 Mar 2002 22:46:18 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: seamoby@ietf.org Subject: Re: [Seamoby] Agenda for IETF 53 Meeting References: Content-Type: multipart/alternative; boundary="------------020104040905010900060207" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------020104040905010900060207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pat R. Calhoun wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We will discuss the threads that have been ongoing on the list which > haven't come to a resolution, such as requirements 4.7, 4.8, etc. > > I don't think so. > --behcet --------------020104040905010900060207 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Pat R. Calhoun wrote:
RE: [Seamoby] Agenda for IETF 53 Meeting

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We will discuss the threads that have been ongoing on the list which
haven't come to a resolution, such as requirements 4.7, 4.8, etc.
 

I don't think so.


--behcet
--------------020104040905010900060207-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 22 12:08:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26209 for ; Fri, 22 Mar 2002 12:08:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15952; Fri, 22 Mar 2002 11:59:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15921 for ; Fri, 22 Mar 2002 11:59:25 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26097 for ; Fri, 22 Mar 2002 11:59:21 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 3907522E15 for ; Fri, 22 Mar 2002 18:57:19 +0200 (EET) Date: Fri, 22 Mar 2002 18:56:12 +0200 (EET) From: Teemu Rinta-aho To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Comments on the requirements draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi all, I am new to this group but I got interested in the draft-krishnamurthi-seamoby-car-requirements-01.txt and decided to send in some comments. I read through the mailing list archive and tried to catch up with what's been going on lately in this group so I am not sure how valuable or valid these comments are, but I think they might be of some use. I have formatted the comments in some kind of sections. It is not ready text to put directly into draft but hopefully easier to read at this point. Numbers 3.X mean they are suggestions for new possible sections. 3.5 FORMAT OF CAPABILITIES - The format of describing the capabilities MUST be extendable and flexible in a way that they support future needs that cannot be exactly defined at this stage. 3.X SECURITY - CAR discovery protocol MUST NOT weaken network security. DoS, hijacking and other possible attacks must be taken into account when designing the protocol. 3.X SCALABILITY - CAR/GAAR discovery MUST be scalable. In the future, there might be geographical locations with several (hundreds) of overlapping access points, especially when PANs emerge. This kind of situation might lead into problems when the ARs behind these APs have to constantly update their knowledge of their GAARs. 3.X INTEROPERABILITY - Interoperability MUST exist with non-CAR ARs. 3.X PERFORMANCE - CAR/GAAR protocol MUST NOT add to handover times in cases when the connection to the old AR is lost and there are ongoing communication waiting for network access. In those cases the MN must get a new AR as fast as possible, not spending much time on the TAR algorithm. General thoughts: How can an AR recognize its GAARs without the help of the MN or the link-layer protocols? This means that the amount of packets sent over the air necessarily increases, doesn't it? I mean, if the AR doesn't get the information about GAARs from the MN, then it must somehow sense the GAARs presence through the APs. But the latter is of course impossible between APs of different link layers. BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 22 12:08:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26216 for ; Fri, 22 Mar 2002 12:08:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17912 for seamoby-archive@odin.ietf.org; Fri, 22 Mar 2002 12:08:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15952; Fri, 22 Mar 2002 11:59:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15921 for ; Fri, 22 Mar 2002 11:59:25 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26097 for ; Fri, 22 Mar 2002 11:59:21 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 3907522E15 for ; Fri, 22 Mar 2002 18:57:19 +0200 (EET) Date: Fri, 22 Mar 2002 18:56:12 +0200 (EET) From: Teemu Rinta-aho To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Seamoby] Comments on the requirements draft Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi all, I am new to this group but I got interested in the draft-krishnamurthi-seamoby-car-requirements-01.txt and decided to send in some comments. I read through the mailing list archive and tried to catch up with what's been going on lately in this group so I am not sure how valuable or valid these comments are, but I think they might be of some use. I have formatted the comments in some kind of sections. It is not ready text to put directly into draft but hopefully easier to read at this point. Numbers 3.X mean they are suggestions for new possible sections. 3.5 FORMAT OF CAPABILITIES - The format of describing the capabilities MUST be extendable and flexible in a way that they support future needs that cannot be exactly defined at this stage. 3.X SECURITY - CAR discovery protocol MUST NOT weaken network security. DoS, hijacking and other possible attacks must be taken into account when designing the protocol. 3.X SCALABILITY - CAR/GAAR discovery MUST be scalable. In the future, there might be geographical locations with several (hundreds) of overlapping access points, especially when PANs emerge. This kind of situation might lead into problems when the ARs behind these APs have to constantly update their knowledge of their GAARs. 3.X INTEROPERABILITY - Interoperability MUST exist with non-CAR ARs. 3.X PERFORMANCE - CAR/GAAR protocol MUST NOT add to handover times in cases when the connection to the old AR is lost and there are ongoing communication waiting for network access. In those cases the MN must get a new AR as fast as possible, not spending much time on the TAR algorithm. General thoughts: How can an AR recognize its GAARs without the help of the MN or the link-layer protocols? This means that the amount of packets sent over the air necessarily increases, doesn't it? I mean, if the AR doesn't get the information about GAARs from the MN, then it must somehow sense the GAARs presence through the APs. But the latter is of course impossible between APs of different link layers. BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 22 15:00:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00295 for ; Fri, 22 Mar 2002 15:00:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14864; Fri, 22 Mar 2002 14:57:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14835 for ; Fri, 22 Mar 2002 14:57:13 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00184 for ; Fri, 22 Mar 2002 14:57:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2MJxW103978 for ; Fri, 22 Mar 2002 13:59:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Mar 2002 13:57:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Mar 2002 13:55:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on the requirements draft Date: Fri, 22 Mar 2002 14:55:41 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on the requirements draft Thread-Index: AcHRwxHUIZl2iwJITlCe6Zh0yZ4JBAAERcIg To: , X-OriginalArrivalTime: 22 Mar 2002 19:55:42.0637 (UTC) FILETIME=[8C6225D0:01C1D1DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA14838 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Teemu, see comments inline. 3.5 FORMAT OF CAPABILITIES - The format of describing the capabilities MUST be extendable and flexible in a way that they support future needs that cannot be exactly defined at this stage. [DOT] in addition to this, though not a requirement as such just recalling what I said in MPLS, we should evaluate what descriptions are on the table (as standards/research/products), and how they could fit into the problem space. This would prevent the re-invention of the wheel. 3.X SCALABILITY - CAR/GAAR discovery MUST be scalable. In the future, there might be geographical locations with several (hundreds) of overlapping access points, especially when PANs emerge. This kind of situation might lead into problems when the ARs behind these APs have to constantly update their knowledge of their GAARs. [DOT] I certainly agree with scalability, just some comments to the number of several hundreds of overlapping access points. Even when I consider PANs, I can hardly think of scenarios where actually hundreds of coverage areas overlap. Bluetooth coverage areas are not large enough, and I doubt that we had so many WLAN APs. But even then, what counts is the number of ARs that have overlapping APs with APs of other ARs. I don't quite see that this number would reach several hundreds. Maybe you could elaborate a bit on the scenarios you have in mind. 3.X INTEROPERABILITY - Interoperability MUST exist with non-CAR ARs. [DOT] How do you mean this? If a non-CAR is (due to the lack of identification and capability knowledge through CAR) not considered as a CAR, it should still be possible to handover to this AR? This is indeed true but not within the scope of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to be identified for that), it should be ok that a CAR solution does not include these non-CAR ARs (one reason might be that the non-CAR AR did not allow the CAR solution's GAAR identifitication - another reasons might be that the non-CAR did not reveal capabilities). However, if the MN (or the AR) would find any other means to identify this non-CAR AR, and the MN (or the AR) makes the decision to handoff to this non-CAR AR, that's fine and still possible. But this is TAR selection, which is not within the scope of CAR discovery. CAR discovery only gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE input to TAR selection (wherever latter is implemented). Another input might be the detection of non-CAR ARs which you might consider in your TAR selection algorithm as well. 3.X PERFORMANCE - CAR/GAAR protocol MUST NOT add to handover times in cases when the connection to the old AR is lost and there are ongoing communication waiting for network access. In those cases the MN must get a new AR as fast as possible, not spending much time on the TAR algorithm. [DOT] How do decide whether it is worthwhile to spend time on CAR or not? If you have a TAR selection scheme that resides in the MN, it is fairly easy to do so. If your signal strength fades for instance too fast, you just skip CAR discovery and select one of the AR from which you receive a current beacon. But again, this is TAR selection and not within the scope of the problem. But if you choose to do CAR (wherever it is implemented), it will always add to your handover time since you have to run certain mechanisms. How this tradeoff can be determined is not clear to me and looks like an implementation issue in the entity that runs the TAR selection (which again use CAR discovery as an input). General thoughts: How can an AR recognize its GAARs without the help of the MN or the link-layer protocols? This means that the amount of packets sent over the air necessarily increases, doesn't it? I mean, if the AR doesn't get the information about GAARs from the MN, then it must somehow sense the GAARs presence through the APs. But the latter is of course impossible between APs of different link layers. [DOT] Good question ;-) But is it mentioned somewhere that the identification of GAARs must not be a combined job between AR and MN? Or it might even be entirely based in the MN? Certainly, the AR-only solution sounds kind of impossible for me, too. Best Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 22 15:00:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00304 for ; Fri, 22 Mar 2002 15:00:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15260 for seamoby-archive@odin.ietf.org; Fri, 22 Mar 2002 15:00:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14864; Fri, 22 Mar 2002 14:57:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14835 for ; Fri, 22 Mar 2002 14:57:13 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00184 for ; Fri, 22 Mar 2002 14:57:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2MJxW103978 for ; Fri, 22 Mar 2002 13:59:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Mar 2002 13:57:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Mar 2002 13:55:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Comments on the requirements draft Date: Fri, 22 Mar 2002 14:55:41 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on the requirements draft Thread-Index: AcHRwxHUIZl2iwJITlCe6Zh0yZ4JBAAERcIg To: , X-OriginalArrivalTime: 22 Mar 2002 19:55:42.0637 (UTC) FILETIME=[8C6225D0:01C1D1DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA14838 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Teemu, see comments inline. 3.5 FORMAT OF CAPABILITIES - The format of describing the capabilities MUST be extendable and flexible in a way that they support future needs that cannot be exactly defined at this stage. [DOT] in addition to this, though not a requirement as such just recalling what I said in MPLS, we should evaluate what descriptions are on the table (as standards/research/products), and how they could fit into the problem space. This would prevent the re-invention of the wheel. 3.X SCALABILITY - CAR/GAAR discovery MUST be scalable. In the future, there might be geographical locations with several (hundreds) of overlapping access points, especially when PANs emerge. This kind of situation might lead into problems when the ARs behind these APs have to constantly update their knowledge of their GAARs. [DOT] I certainly agree with scalability, just some comments to the number of several hundreds of overlapping access points. Even when I consider PANs, I can hardly think of scenarios where actually hundreds of coverage areas overlap. Bluetooth coverage areas are not large enough, and I doubt that we had so many WLAN APs. But even then, what counts is the number of ARs that have overlapping APs with APs of other ARs. I don't quite see that this number would reach several hundreds. Maybe you could elaborate a bit on the scenarios you have in mind. 3.X INTEROPERABILITY - Interoperability MUST exist with non-CAR ARs. [DOT] How do you mean this? If a non-CAR is (due to the lack of identification and capability knowledge through CAR) not considered as a CAR, it should still be possible to handover to this AR? This is indeed true but not within the scope of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to be identified for that), it should be ok that a CAR solution does not include these non-CAR ARs (one reason might be that the non-CAR AR did not allow the CAR solution's GAAR identifitication - another reasons might be that the non-CAR did not reveal capabilities). However, if the MN (or the AR) would find any other means to identify this non-CAR AR, and the MN (or the AR) makes the decision to handoff to this non-CAR AR, that's fine and still possible. But this is TAR selection, which is not within the scope of CAR discovery. CAR discovery only gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE input to TAR selection (wherever latter is implemented). Another input might be the detection of non-CAR ARs which you might consider in your TAR selection algorithm as well. 3.X PERFORMANCE - CAR/GAAR protocol MUST NOT add to handover times in cases when the connection to the old AR is lost and there are ongoing communication waiting for network access. In those cases the MN must get a new AR as fast as possible, not spending much time on the TAR algorithm. [DOT] How do decide whether it is worthwhile to spend time on CAR or not? If you have a TAR selection scheme that resides in the MN, it is fairly easy to do so. If your signal strength fades for instance too fast, you just skip CAR discovery and select one of the AR from which you receive a current beacon. But again, this is TAR selection and not within the scope of the problem. But if you choose to do CAR (wherever it is implemented), it will always add to your handover time since you have to run certain mechanisms. How this tradeoff can be determined is not clear to me and looks like an implementation issue in the entity that runs the TAR selection (which again use CAR discovery as an input). General thoughts: How can an AR recognize its GAARs without the help of the MN or the link-layer protocols? This means that the amount of packets sent over the air necessarily increases, doesn't it? I mean, if the AR doesn't get the information about GAARs from the MN, then it must somehow sense the GAARs presence through the APs. But the latter is of course impossible between APs of different link layers. [DOT] Good question ;-) But is it mentioned somewhere that the identification of GAARs must not be a combined job between AR and MN? Or it might even be entirely based in the MN? Certainly, the AR-only solution sounds kind of impossible for me, too. Best Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 00:00:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01712 for ; Sun, 24 Mar 2002 00:00:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12196; Sat, 23 Mar 2002 23:52:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12154 for ; Sat, 23 Mar 2002 23:52:17 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01658 for ; Sat, 23 Mar 2002 23:52:11 -0500 (EST) Received: from T23KEMPF (dhcp165.docomolabs-usa.com [172.21.96.165]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2O4pcI01580; Sat, 23 Mar 2002 20:51:38 -0800 (PST) Message-ID: <00d701c1d2ef$5c335810$a56015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Sat, 23 Mar 2002 20:50:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit As per SteveD's presentation in the Minne-apple, the MN must be able to make the decision on its own, particularly for intertechnology. The MN must also be able to get the information through any interface, even one that is currently not up. This allows the MN to keep an interface powered down until it knows there is an active wireless network in the area == power savings. If the latter were not so, the MN could just use standard Router Discovery on the interface and there would be no need for CAR discovery. jak ----- Original Message ----- From: To: ; Sent: Friday, March 22, 2002 11:55 AM Subject: RE: [Seamoby] Comments on the requirements draft > Hi Teemu, > > see comments inline. > > > 3.5 FORMAT OF CAPABILITIES > > - The format of describing the capabilities MUST be > extendable and flexible in a way that they support > future needs that cannot be exactly defined > at this stage. > > [DOT] in addition to this, though not a requirement as such just > recalling what I said in MPLS, we should evaluate what descriptions > are on the table (as standards/research/products), and how they could > fit into the problem space. This would prevent the re-invention of > the wheel. > > 3.X SCALABILITY > > - CAR/GAAR discovery MUST be scalable. In the future, there > might be geographical locations with several (hundreds) > of overlapping access points, especially when PANs emerge. > This kind of situation might lead into problems when the > ARs behind these APs have to constantly update their > knowledge of their GAARs. > > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But even then, > what counts is the number of ARs that have overlapping APs with APs of > other ARs. I don't quite see that this number would reach several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > and capability knowledge through CAR) not considered as a CAR, it should still > be possible to handover to this AR? This is indeed true but not within the scope > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > be identified for that), it should be ok that a CAR solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > did not reveal capabilities). However, if the MN (or the AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > selection, which is not within the scope of CAR discovery. CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > input to TAR selection (wherever latter is implemented). Another input might be > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > as well. > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > If you have a TAR selection scheme that resides in the MN, it is fairly > easy to do so. If your signal strength fades for instance too fast, you just > skip CAR discovery and select one of the AR from which you receive a current > beacon. But again, this is TAR selection and not within the scope of the problem. > But if you choose to do CAR (wherever it is implemented), it will always add > to your handover time since you have to run certain mechanisms. How this tradeoff > can be determined is not clear to me and looks like an implementation issue in > the entity that runs the TAR selection (which again use CAR discovery as an input). > > General thoughts: > > How can an AR recognize its GAARs without the help of the MN > or the link-layer protocols? > > This means that the amount of packets sent over the air necessarily > increases, doesn't it? I mean, if the AR doesn't get the information about > GAARs from the MN, then it must somehow sense the GAARs presence through > the APs. But the latter is of course impossible between APs of different > link layers. > > [DOT] Good question ;-) But is it mentioned somewhere that the > identification of GAARs must not be a combined job between AR and MN? Or it > might even be entirely based in the MN? Certainly, the AR-only solution > sounds kind of impossible for me, too. > > Best Regards, > > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 00:00:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01722 for ; Sun, 24 Mar 2002 00:00:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA13575 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 00:00:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12196; Sat, 23 Mar 2002 23:52:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12154 for ; Sat, 23 Mar 2002 23:52:17 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01658 for ; Sat, 23 Mar 2002 23:52:11 -0500 (EST) Received: from T23KEMPF (dhcp165.docomolabs-usa.com [172.21.96.165]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2O4pcI01580; Sat, 23 Mar 2002 20:51:38 -0800 (PST) Message-ID: <00d701c1d2ef$5c335810$a56015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Sat, 23 Mar 2002 20:50:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit As per SteveD's presentation in the Minne-apple, the MN must be able to make the decision on its own, particularly for intertechnology. The MN must also be able to get the information through any interface, even one that is currently not up. This allows the MN to keep an interface powered down until it knows there is an active wireless network in the area == power savings. If the latter were not so, the MN could just use standard Router Discovery on the interface and there would be no need for CAR discovery. jak ----- Original Message ----- From: To: ; Sent: Friday, March 22, 2002 11:55 AM Subject: RE: [Seamoby] Comments on the requirements draft > Hi Teemu, > > see comments inline. > > > 3.5 FORMAT OF CAPABILITIES > > - The format of describing the capabilities MUST be > extendable and flexible in a way that they support > future needs that cannot be exactly defined > at this stage. > > [DOT] in addition to this, though not a requirement as such just > recalling what I said in MPLS, we should evaluate what descriptions > are on the table (as standards/research/products), and how they could > fit into the problem space. This would prevent the re-invention of > the wheel. > > 3.X SCALABILITY > > - CAR/GAAR discovery MUST be scalable. In the future, there > might be geographical locations with several (hundreds) > of overlapping access points, especially when PANs emerge. > This kind of situation might lead into problems when the > ARs behind these APs have to constantly update their > knowledge of their GAARs. > > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But even then, > what counts is the number of ARs that have overlapping APs with APs of > other ARs. I don't quite see that this number would reach several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > and capability knowledge through CAR) not considered as a CAR, it should still > be possible to handover to this AR? This is indeed true but not within the scope > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > be identified for that), it should be ok that a CAR solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > did not reveal capabilities). However, if the MN (or the AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > selection, which is not within the scope of CAR discovery. CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > input to TAR selection (wherever latter is implemented). Another input might be > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > as well. > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > If you have a TAR selection scheme that resides in the MN, it is fairly > easy to do so. If your signal strength fades for instance too fast, you just > skip CAR discovery and select one of the AR from which you receive a current > beacon. But again, this is TAR selection and not within the scope of the problem. > But if you choose to do CAR (wherever it is implemented), it will always add > to your handover time since you have to run certain mechanisms. How this tradeoff > can be determined is not clear to me and looks like an implementation issue in > the entity that runs the TAR selection (which again use CAR discovery as an input). > > General thoughts: > > How can an AR recognize its GAARs without the help of the MN > or the link-layer protocols? > > This means that the amount of packets sent over the air necessarily > increases, doesn't it? I mean, if the AR doesn't get the information about > GAARs from the MN, then it must somehow sense the GAARs presence through > the APs. But the latter is of course impossible between APs of different > link layers. > > [DOT] Good question ;-) But is it mentioned somewhere that the > identification of GAARs must not be a combined job between AR and MN? Or it > might even be entirely based in the MN? Certainly, the AR-only solution > sounds kind of impossible for me, too. > > Best Regards, > > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 12:12:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15858 for ; Sun, 24 Mar 2002 12:12:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21072; Sun, 24 Mar 2002 12:09:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21026 for ; Sun, 24 Mar 2002 12:09:14 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15836 for ; Sun, 24 Mar 2002 12:09:10 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Mar 2002 12:07:42 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'James Kempf'" , seamoby@ietf.org Cc: "Shahrier, Sharif M." Subject: [Seamoby] Requested Information. Date: Sun, 24 Mar 2002 12:07:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I think, if I'm not mistaken, that you are a co-author of the L2 triggers draft for managing multiple wireless interfaces? I don't know if this draft is a SEAMOBY or MOBILEIP document, but if you or anyone in the working group, can send me a link to the document, I would be most appreciative. I could not locate it. Thanks. Sharif. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 12:12:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15869 for ; Sun, 24 Mar 2002 12:12:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21852 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 12:13:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21072; Sun, 24 Mar 2002 12:09:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21026 for ; Sun, 24 Mar 2002 12:09:14 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15836 for ; Sun, 24 Mar 2002 12:09:10 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Mar 2002 12:07:42 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'James Kempf'" , seamoby@ietf.org Cc: "Shahrier, Sharif M." Subject: [Seamoby] Requested Information. Date: Sun, 24 Mar 2002 12:07:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I think, if I'm not mistaken, that you are a co-author of the L2 triggers draft for managing multiple wireless interfaces? I don't know if this draft is a SEAMOBY or MOBILEIP document, but if you or anyone in the working group, can send me a link to the document, I would be most appreciative. I could not locate it. Thanks. Sharif. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 15:44:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17553 for ; Sun, 24 Mar 2002 15:44:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07396; Sun, 24 Mar 2002 15:41:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07367 for ; Sun, 24 Mar 2002 15:41:31 -0500 (EST) Received: from hotmail.com (f240.law7.hotmail.com [216.33.237.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17521 for ; Sun, 24 Mar 2002 15:41:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Mar 2002 12:40:58 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 24 Mar 2002 20:40:57 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Sun, 24 Mar 2002 20:40:57 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2002 20:40:58.0198 (UTC) FILETIME=[33CF5F60:01C1D374] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some comments inline: >From: "James Kempf" >To: , , > >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Sat, 23 Mar 2002 20:50:00 -0800 > >As per SteveD's presentation in the Minne-apple, the MN must be able to >make the decision on its own, particularly for intertechnology. [HC] I agree that MN's requirements MUST always be considered during CAR discovery. I guess, that is why we have a requirement that: "MN's requirements MUST be made available to CAR discovery protocol." CAR discovery is about "comparing MN's requirements with capabilities of GAAR to identify CARs." As said in problem statement, CAR discovery does not make any decisions about handoffs or target access routers. It simply identifies CARs from GAARs by comparing MN's requirements with GAAR capabilities. Decisions are made by TAR selection which may reside in MN or in network or in both of them. TAR selection is outside the scope of CAR discovery. But the following additional requirement may help "Output of CAR discovery MUST be available for TAR selection algorithms wherever they are implemented (MN, network or hybrid)." > >The MN must also be able to get the information through any interface, >even one that is currently not up. This allows the MN to keep an >interface powered down until it knows there is an active wireless >network in the area == power savings. [HC] How will MN receive information over interface that is down? It has to receive trigger over another interface to first wake up the sleeping interface. > >If the latter were not so, the MN could just use standard Router >Discovery on the interface and there would be no need for CAR discovery. [HC]Even when other interface is awake, the capability discovery via Router Discovery is not always efficient and it is also time and power consuming. For this, MN needs to acquire link layer connectivity, then IP-layer connectivity and then receive capabilities over the new connection. You have to do this for every AP beacon that you hear. While MN is doing that its old connection may actually go down (moving into basement of building from cellular coverage) thereby causing disruption of service. Also, if the new access router does not meet MN's requirements, all this capability discovery effort (and associated power spent) goes waste. These can be avoided by doing AR_current-assisted CAR discovery while still considering MN's requirements. BR, Hemant > > jak > >----- Original Message ----- >From: >To: ; >Sent: Friday, March 22, 2002 11:55 AM >Subject: RE: [Seamoby] Comments on the requirements draft > > > > Hi Teemu, > > > > see comments inline. > > > > > > 3.5 FORMAT OF CAPABILITIES > > > > - The format of describing the capabilities MUST be > > extendable and flexible in a way that they support > > future needs that cannot be exactly defined > > at this stage. > > > > [DOT] in addition to this, though not a requirement as such just > > recalling what I said in MPLS, we should evaluate what descriptions > > are on the table (as standards/research/products), and how they could > > fit into the problem space. This would prevent the re-invention of > > the wheel. > > > > 3.X SCALABILITY > > > > - CAR/GAAR discovery MUST be scalable. In the future, there > > might be geographical locations with several (hundreds) > > of overlapping access points, especially when PANs emerge. > > This kind of situation might lead into problems when the > > ARs behind these APs have to constantly update their > > knowledge of their GAARs. > > > > [DOT] I certainly agree with scalability, just some comments to > > the number of several hundreds of overlapping access points. Even > > when I consider PANs, I can hardly think of scenarios where actually > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > large enough, and I doubt that we had so many WLAN APs. But even then, > > what counts is the number of ARs that have overlapping APs with APs of > > other ARs. I don't quite see that this number would reach several >hundreds. > > Maybe you could elaborate a bit on the scenarios you have in mind. > > > > 3.X INTEROPERABILITY > > > > - Interoperability MUST exist with non-CAR ARs. > > > > [DOT] How do you mean this? If a non-CAR is (due to the lack of >identification > > and capability knowledge through CAR) not considered as a CAR, it >should still > > be possible to handover to this AR? This is indeed true but not within >the scope > > of CAR discovery. Since CAR discovery only gives you a set of CARs >(which need to > > be identified for that), it should be ok that a CAR solution does not >include > > these non-CAR ARs (one reason might be that the non-CAR AR did not >allow the > > CAR solution's GAAR identifitication - another reasons might be that >the non-CAR > > did not reveal capabilities). However, if the MN (or the AR) would >find any other > > means to identify this non-CAR AR, and the MN (or the AR) makes the >decision to > > handoff to this non-CAR AR, that's fine and still possible. But this >is TAR > > selection, which is not within the scope of CAR discovery. CAR >discovery only > > gives you a list of CARs (i.e., ARs that match MN's requirements), >which is ONE > > input to TAR selection (wherever latter is implemented). Another input >might be > > the detection of non-CAR ARs which you might consider in your TAR >selection algorithm > > as well. > > > > > > 3.X PERFORMANCE > > > > - CAR/GAAR protocol MUST NOT add to handover times in > > cases when the connection to the old AR is lost and there > > are ongoing communication waiting for network access. In > > those cases the MN must get a new AR as fast as possible, > > not spending much time on the TAR algorithm. > > > > [DOT] How do decide whether it is worthwhile to spend time on CAR or >not? > > If you have a TAR selection scheme that resides in the MN, it is >fairly > > easy to do so. If your signal strength fades for instance too fast, >you just > > skip CAR discovery and select one of the AR from which you receive a >current > > beacon. But again, this is TAR selection and not within the scope of >the problem. > > But if you choose to do CAR (wherever it is implemented), it will >always add > > to your handover time since you have to run certain mechanisms. How >this tradeoff > > can be determined is not clear to me and looks like an implementation >issue in > > the entity that runs the TAR selection (which again use CAR discovery >as an input). > > > > General thoughts: > > > > How can an AR recognize its GAARs without the help of the MN > > or the link-layer protocols? > > > > This means that the amount of packets sent over the air necessarily > > increases, doesn't it? I mean, if the AR doesn't get the information >about > > GAARs from the MN, then it must somehow sense the GAARs presence >through > > the APs. But the latter is of course impossible between APs of >different > > link layers. > > > > [DOT] Good question ;-) But is it mentioned somewhere that the > > identification of GAARs must not be a combined job between AR and MN? >Or it > > might even be entirely based in the MN? Certainly, the AR-only >solution > > sounds kind of impossible for me, too. > > > > Best Regards, > > > > > > Dirk > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 15:44:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17563 for ; Sun, 24 Mar 2002 15:44:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08115 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 15:44:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07396; Sun, 24 Mar 2002 15:41:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07367 for ; Sun, 24 Mar 2002 15:41:31 -0500 (EST) Received: from hotmail.com (f240.law7.hotmail.com [216.33.237.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17521 for ; Sun, 24 Mar 2002 15:41:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Mar 2002 12:40:58 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 24 Mar 2002 20:40:57 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Sun, 24 Mar 2002 20:40:57 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2002 20:40:58.0198 (UTC) FILETIME=[33CF5F60:01C1D374] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some comments inline: >From: "James Kempf" >To: , , > >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Sat, 23 Mar 2002 20:50:00 -0800 > >As per SteveD's presentation in the Minne-apple, the MN must be able to >make the decision on its own, particularly for intertechnology. [HC] I agree that MN's requirements MUST always be considered during CAR discovery. I guess, that is why we have a requirement that: "MN's requirements MUST be made available to CAR discovery protocol." CAR discovery is about "comparing MN's requirements with capabilities of GAAR to identify CARs." As said in problem statement, CAR discovery does not make any decisions about handoffs or target access routers. It simply identifies CARs from GAARs by comparing MN's requirements with GAAR capabilities. Decisions are made by TAR selection which may reside in MN or in network or in both of them. TAR selection is outside the scope of CAR discovery. But the following additional requirement may help "Output of CAR discovery MUST be available for TAR selection algorithms wherever they are implemented (MN, network or hybrid)." > >The MN must also be able to get the information through any interface, >even one that is currently not up. This allows the MN to keep an >interface powered down until it knows there is an active wireless >network in the area == power savings. [HC] How will MN receive information over interface that is down? It has to receive trigger over another interface to first wake up the sleeping interface. > >If the latter were not so, the MN could just use standard Router >Discovery on the interface and there would be no need for CAR discovery. [HC]Even when other interface is awake, the capability discovery via Router Discovery is not always efficient and it is also time and power consuming. For this, MN needs to acquire link layer connectivity, then IP-layer connectivity and then receive capabilities over the new connection. You have to do this for every AP beacon that you hear. While MN is doing that its old connection may actually go down (moving into basement of building from cellular coverage) thereby causing disruption of service. Also, if the new access router does not meet MN's requirements, all this capability discovery effort (and associated power spent) goes waste. These can be avoided by doing AR_current-assisted CAR discovery while still considering MN's requirements. BR, Hemant > > jak > >----- Original Message ----- >From: >To: ; >Sent: Friday, March 22, 2002 11:55 AM >Subject: RE: [Seamoby] Comments on the requirements draft > > > > Hi Teemu, > > > > see comments inline. > > > > > > 3.5 FORMAT OF CAPABILITIES > > > > - The format of describing the capabilities MUST be > > extendable and flexible in a way that they support > > future needs that cannot be exactly defined > > at this stage. > > > > [DOT] in addition to this, though not a requirement as such just > > recalling what I said in MPLS, we should evaluate what descriptions > > are on the table (as standards/research/products), and how they could > > fit into the problem space. This would prevent the re-invention of > > the wheel. > > > > 3.X SCALABILITY > > > > - CAR/GAAR discovery MUST be scalable. In the future, there > > might be geographical locations with several (hundreds) > > of overlapping access points, especially when PANs emerge. > > This kind of situation might lead into problems when the > > ARs behind these APs have to constantly update their > > knowledge of their GAARs. > > > > [DOT] I certainly agree with scalability, just some comments to > > the number of several hundreds of overlapping access points. Even > > when I consider PANs, I can hardly think of scenarios where actually > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > large enough, and I doubt that we had so many WLAN APs. But even then, > > what counts is the number of ARs that have overlapping APs with APs of > > other ARs. I don't quite see that this number would reach several >hundreds. > > Maybe you could elaborate a bit on the scenarios you have in mind. > > > > 3.X INTEROPERABILITY > > > > - Interoperability MUST exist with non-CAR ARs. > > > > [DOT] How do you mean this? If a non-CAR is (due to the lack of >identification > > and capability knowledge through CAR) not considered as a CAR, it >should still > > be possible to handover to this AR? This is indeed true but not within >the scope > > of CAR discovery. Since CAR discovery only gives you a set of CARs >(which need to > > be identified for that), it should be ok that a CAR solution does not >include > > these non-CAR ARs (one reason might be that the non-CAR AR did not >allow the > > CAR solution's GAAR identifitication - another reasons might be that >the non-CAR > > did not reveal capabilities). However, if the MN (or the AR) would >find any other > > means to identify this non-CAR AR, and the MN (or the AR) makes the >decision to > > handoff to this non-CAR AR, that's fine and still possible. But this >is TAR > > selection, which is not within the scope of CAR discovery. CAR >discovery only > > gives you a list of CARs (i.e., ARs that match MN's requirements), >which is ONE > > input to TAR selection (wherever latter is implemented). Another input >might be > > the detection of non-CAR ARs which you might consider in your TAR >selection algorithm > > as well. > > > > > > 3.X PERFORMANCE > > > > - CAR/GAAR protocol MUST NOT add to handover times in > > cases when the connection to the old AR is lost and there > > are ongoing communication waiting for network access. In > > those cases the MN must get a new AR as fast as possible, > > not spending much time on the TAR algorithm. > > > > [DOT] How do decide whether it is worthwhile to spend time on CAR or >not? > > If you have a TAR selection scheme that resides in the MN, it is >fairly > > easy to do so. If your signal strength fades for instance too fast, >you just > > skip CAR discovery and select one of the AR from which you receive a >current > > beacon. But again, this is TAR selection and not within the scope of >the problem. > > But if you choose to do CAR (wherever it is implemented), it will >always add > > to your handover time since you have to run certain mechanisms. How >this tradeoff > > can be determined is not clear to me and looks like an implementation >issue in > > the entity that runs the TAR selection (which again use CAR discovery >as an input). > > > > General thoughts: > > > > How can an AR recognize its GAARs without the help of the MN > > or the link-layer protocols? > > > > This means that the amount of packets sent over the air necessarily > > increases, doesn't it? I mean, if the AR doesn't get the information >about > > GAARs from the MN, then it must somehow sense the GAARs presence >through > > the APs. But the latter is of course impossible between APs of >different > > link layers. > > > > [DOT] Good question ;-) But is it mentioned somewhere that the > > identification of GAARs must not be a combined job between AR and MN? >Or it > > might even be entirely based in the MN? Certainly, the AR-only >solution > > sounds kind of impossible for me, too. > > > > Best Regards, > > > > > > Dirk > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 16:39:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18665 for ; Sun, 24 Mar 2002 16:39:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19097; Sun, 24 Mar 2002 16:34:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19051 for ; Sun, 24 Mar 2002 16:34:22 -0500 (EST) Received: from hotmail.com (f196.law7.hotmail.com [216.33.237.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18612 for ; Sun, 24 Mar 2002 16:34:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Mar 2002 13:33:50 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 24 Mar 2002 21:33:50 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Date: Sun, 24 Mar 2002 21:33:50 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2002 21:33:50.0802 (UTC) FILETIME=[96D45320:01C1D37B] Subject: [Seamoby] Examples of CAR discovery Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi all: After the CAR discovery discussion in IETF53, it seems that we need to emphasize certain points about CAR discovery. They are as follows: - CAR discovery always considers MN requirements while choosing CARs from GAARs. - CAR discovery _does not_ make any handoff decisions. It merely chooses CARs (by matching MN's requirements with GAARs' capabilities) and makes this information available to TAR selection algorithms. TAR selection algorithms (whether they reside in MN or network or both) make decision about TAR for handoff. - CAR discovery does not force any handoffs and it does not advocate any network-based handoff decision making. - The problem statement does not advocate any specific way (network-based or MN-based or hybrid) of performing CAR discovery. Below are some examples of CAR discovery (two of them are paraphrased from the issues draft) that emphasize above points. They are for illustrative purposes only and not to advocate any solution. Such examples may be useful for discussing CAR discovery topic further. Example 1: ---------- Here, an MN connected to AR_current hears a beacon from a nearby access point (AP_new). Note that this beacon may not contain the IP address of AR_new that governs this AP_new. MN passes on this beacon information to AR_current, and AR_current has to map it to the IP address of AR_new. AR_current then compares the capabilities of AR_new with the requirements expressed by MN. These requirements are expressed by MN prior to handoff and are made available to AR_current for CAR discovery. If good match is found, AR_current deems AR_new as a CAR. A similar process could occur for every AP beacon heard by MN and other CARs could be discovered as well. CAR discovery ends here. CAR discovery output, i.e., this set of CARs, is one parameter used by the target AR (TAR) selection algorithm. The output of TAR selection decides where the MN actually hands off to. It could even be to an AR different than CARs discovered as above. This TAR selection algorithm may reside in the MN and/or the AR. Depending upon implementation of TAR selection process, the CAR IDs (possibly along with their capabilities) may have to be sent to the MN for selection. Example 2: ---------- In this example, an MN can actually connect to the AP_new and then by using, say, router solicitation, get the IP address of AR_new. It can then solicit the capabilities of AR_new over the new IP layer connection it has established and compare them with its requirements to identify whether AR_new is a CAR. This process can be repeated for every beacon heard by MN. Again CAR discovery ends here. The output of CAR discovery is fed as one input to the TAR selection algorithm, wherever it resides, and the TAR selection algorithm then decides the AR that the MN will be handing off to. There are performance differences between examples 1 and 2 with respect to wireless bandwidth efficiency, speed of CAR discovery, utility towards fast/smooth handoff protocols, MN power saving etc. Example 3: ---------- Here MN is connected to cellular network over one interface and its other interface (WLAN) is sleeping for power saving purposes. MN is attached to AR_current of cellular and "MN has expressed the requirement with AR_current" to let it know whenever hot-spot access opportunity exists. Note that, MN may not be able to detect hot-spot access by itself as WLAN interface is sleeping for power saving. Since AR_current knows the capabilities of GAARs (thanks to AR <-> GAAR capability exchange part of CAR discovery), it knows that WLAN access exists in neighborhood and it can intimate so to MN. It is then "upto the MN to decide" if it wants to fire up the WLAN interface and start scanning. During scanning, MN can do further capability discovery either as in example 1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned above. Note that, MN may detect more than one WLAN beacons during scanning as well. Also, it is worth noting that it is not the only option that CAR discovery information be available through WLAN interface. It could be obtained over cellular interface from AR_current (example 1) or over WLAN interface from GAAR (example 2). Performance/implementation tradeoffs will determine the best option. In fact, if AR_current's assistance is sought for CAR discovery (example 1), there may not be need to unnecessarily fire up WLAN interface if the capabilities of WLAN access do not match MN requirements. Even more power saving! Please provide your feedback on these. BR, Hemant _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 16:39:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18674 for ; Sun, 24 Mar 2002 16:39:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20365 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 16:39:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19097; Sun, 24 Mar 2002 16:34:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19051 for ; Sun, 24 Mar 2002 16:34:22 -0500 (EST) Received: from hotmail.com (f196.law7.hotmail.com [216.33.237.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18612 for ; Sun, 24 Mar 2002 16:34:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Mar 2002 13:33:50 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 24 Mar 2002 21:33:50 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Date: Sun, 24 Mar 2002 21:33:50 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2002 21:33:50.0802 (UTC) FILETIME=[96D45320:01C1D37B] Subject: [Seamoby] Examples of CAR discovery Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi all: After the CAR discovery discussion in IETF53, it seems that we need to emphasize certain points about CAR discovery. They are as follows: - CAR discovery always considers MN requirements while choosing CARs from GAARs. - CAR discovery _does not_ make any handoff decisions. It merely chooses CARs (by matching MN's requirements with GAARs' capabilities) and makes this information available to TAR selection algorithms. TAR selection algorithms (whether they reside in MN or network or both) make decision about TAR for handoff. - CAR discovery does not force any handoffs and it does not advocate any network-based handoff decision making. - The problem statement does not advocate any specific way (network-based or MN-based or hybrid) of performing CAR discovery. Below are some examples of CAR discovery (two of them are paraphrased from the issues draft) that emphasize above points. They are for illustrative purposes only and not to advocate any solution. Such examples may be useful for discussing CAR discovery topic further. Example 1: ---------- Here, an MN connected to AR_current hears a beacon from a nearby access point (AP_new). Note that this beacon may not contain the IP address of AR_new that governs this AP_new. MN passes on this beacon information to AR_current, and AR_current has to map it to the IP address of AR_new. AR_current then compares the capabilities of AR_new with the requirements expressed by MN. These requirements are expressed by MN prior to handoff and are made available to AR_current for CAR discovery. If good match is found, AR_current deems AR_new as a CAR. A similar process could occur for every AP beacon heard by MN and other CARs could be discovered as well. CAR discovery ends here. CAR discovery output, i.e., this set of CARs, is one parameter used by the target AR (TAR) selection algorithm. The output of TAR selection decides where the MN actually hands off to. It could even be to an AR different than CARs discovered as above. This TAR selection algorithm may reside in the MN and/or the AR. Depending upon implementation of TAR selection process, the CAR IDs (possibly along with their capabilities) may have to be sent to the MN for selection. Example 2: ---------- In this example, an MN can actually connect to the AP_new and then by using, say, router solicitation, get the IP address of AR_new. It can then solicit the capabilities of AR_new over the new IP layer connection it has established and compare them with its requirements to identify whether AR_new is a CAR. This process can be repeated for every beacon heard by MN. Again CAR discovery ends here. The output of CAR discovery is fed as one input to the TAR selection algorithm, wherever it resides, and the TAR selection algorithm then decides the AR that the MN will be handing off to. There are performance differences between examples 1 and 2 with respect to wireless bandwidth efficiency, speed of CAR discovery, utility towards fast/smooth handoff protocols, MN power saving etc. Example 3: ---------- Here MN is connected to cellular network over one interface and its other interface (WLAN) is sleeping for power saving purposes. MN is attached to AR_current of cellular and "MN has expressed the requirement with AR_current" to let it know whenever hot-spot access opportunity exists. Note that, MN may not be able to detect hot-spot access by itself as WLAN interface is sleeping for power saving. Since AR_current knows the capabilities of GAARs (thanks to AR <-> GAAR capability exchange part of CAR discovery), it knows that WLAN access exists in neighborhood and it can intimate so to MN. It is then "upto the MN to decide" if it wants to fire up the WLAN interface and start scanning. During scanning, MN can do further capability discovery either as in example 1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned above. Note that, MN may detect more than one WLAN beacons during scanning as well. Also, it is worth noting that it is not the only option that CAR discovery information be available through WLAN interface. It could be obtained over cellular interface from AR_current (example 1) or over WLAN interface from GAAR (example 2). Performance/implementation tradeoffs will determine the best option. In fact, if AR_current's assistance is sought for CAR discovery (example 1), there may not be need to unnecessarily fire up WLAN interface if the capabilities of WLAN access do not match MN requirements. Even more power saving! Please provide your feedback on these. BR, Hemant _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 19:19:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20113 for ; Sun, 24 Mar 2002 19:19:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24647; Sun, 24 Mar 2002 19:16:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24613 for ; Sun, 24 Mar 2002 19:16:38 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20102 for ; Sun, 24 Mar 2002 19:16:34 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0G4I14851; Sun, 24 Mar 2002 16:16:04 -0800 (PST) Message-ID: <005b01c1d392$07ef1700$356015ac@T23KEMPF> From: "James Kempf" To: "Shahrier, Sharif M." , Cc: "Shahrier, Sharif M." References: Subject: Re: [Seamoby] Requested Information. Date: Sun, 24 Mar 2002 16:14:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Try draft-manyfolks-l2-mobilereq-02.txt. As for what's happening, there was a pre-BOF at IETF 53 with Aaron Falk and Carl Williams as co-chairs, and they will be organizing a BOF at Yokohama. I think the decision was to use the PILC list for discussion, since PILC is about done with its charter and it has dealt with L2 issues. Ping Aaron if you want more information, his email is on the PILC web page. jak ----- Original Message ----- From: "Shahrier, Sharif M." To: "'James Kempf'" ; Cc: "Shahrier, Sharif M." Sent: Sunday, March 24, 2002 9:07 AM Subject: [Seamoby] Requested Information. > > James, > > I think, if I'm not mistaken, that you are a co-author of the L2 > triggers draft for managing multiple wireless interfaces? I don't know if > this draft is a SEAMOBY or MOBILEIP document, but if you or anyone in the > working group, can send me a link to the document, I would be most > appreciative. I could not locate it. > > Thanks. > > Sharif. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 19:19:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20124 for ; Sun, 24 Mar 2002 19:19:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25294 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 19:19:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24647; Sun, 24 Mar 2002 19:16:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24613 for ; Sun, 24 Mar 2002 19:16:38 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20102 for ; Sun, 24 Mar 2002 19:16:34 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0G4I14851; Sun, 24 Mar 2002 16:16:04 -0800 (PST) Message-ID: <005b01c1d392$07ef1700$356015ac@T23KEMPF> From: "James Kempf" To: "Shahrier, Sharif M." , Cc: "Shahrier, Sharif M." References: Subject: Re: [Seamoby] Requested Information. Date: Sun, 24 Mar 2002 16:14:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Try draft-manyfolks-l2-mobilereq-02.txt. As for what's happening, there was a pre-BOF at IETF 53 with Aaron Falk and Carl Williams as co-chairs, and they will be organizing a BOF at Yokohama. I think the decision was to use the PILC list for discussion, since PILC is about done with its charter and it has dealt with L2 issues. Ping Aaron if you want more information, his email is on the PILC web page. jak ----- Original Message ----- From: "Shahrier, Sharif M." To: "'James Kempf'" ; Cc: "Shahrier, Sharif M." Sent: Sunday, March 24, 2002 9:07 AM Subject: [Seamoby] Requested Information. > > James, > > I think, if I'm not mistaken, that you are a co-author of the L2 > triggers draft for managing multiple wireless interfaces? I don't know if > this draft is a SEAMOBY or MOBILEIP document, but if you or anyone in the > working group, can send me a link to the document, I would be most > appreciative. I could not locate it. > > Thanks. > > Sharif. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 19:24:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20201 for ; Sun, 24 Mar 2002 19:24:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26013; Sun, 24 Mar 2002 19:22:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25978 for ; Sun, 24 Mar 2002 19:22:38 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20154 for ; Sun, 24 Mar 2002 19:22:33 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0M0I14917; Sun, 24 Mar 2002 16:22:01 -0800 (PST) Message-ID: <006701c1d392$dc579da0$356015ac@T23KEMPF> From: "James Kempf" To: Cc: References: Date: Sun, 24 Mar 2002 16:20:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit (note: I've taken this to the list...) > - MN is attached to AR_current of cellular and "MN has expressed the requirement with AR_current" to let it know whenever hot-spot access opportunity exists. Note that, MN may not be able to detect hot-spot access by itself as WLAN interface is sleeping for power saving. Since AR_current knows the capabilities of GAARs (thanks to AR <-> GAAR capability exchange part of CAR discovery), it knows that WLAN access exists in neighborhood and it can intimate so to MN. It is then "upto the MN to decide" if it wants to fire up the WLAN interface and start scanning. > So the key is "expressed the requirement." What does this mean? Does the MN periodically poll the AR for this information, or does it send a subscription to receive a notification that then gets passed along as part of the MN's context transfer when the MN moves? > - During scanning, MN can do further capability discovery either as in example 1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned below. Note that, MN may detect more than one WLAN beacons during scanning as well. Also, it is worth noting that it is not the only option that CAR discovery information be available through WLAN interface. It could be obtained over cellular interface from AR_current (example 1) or over WLAN interface from GAAR (example 2). Performance/implementation tradeoffs will determine the best option. In fact, if AR_current's assistance is sought for CAR discovery (example 1), there may not be need to unnecessarily fire up WLAN interface if the capabilities of WLAN access do not match MN requirements. Even more power saving! > I had in mind primarily the latter. If the MN brings up the WLAN interface, there is no need for CAR discovery because it just needs to Neighbor Discovery (in IPv6). CAR discovery is only of interest if the MN wants to find out about other media options prior to bringing up the interface. > The requirement of indication of WLAN access in neighborhood, may be "expressed by MN explicitly with AR_current", or "statically configured in MN's profile" which may get transferred from AR to AR as handoffs occur. The requirement can be even more fine-tuned: "Tell me when WLAN access of certain provider (organization) is available in neighborhood" or "tell me when WLAN access which I am authorized to access is available in the neighborhood" etc. > Sure, but the issue is whether the MN periodically polls or there is some kind of subscription/notification protocol that gets passed along with context transfer. The former is simpler, the latter more bandwidth efficient. jak > Please let me know what you think about it. > > Best Regards, > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, March 24, 2002 12:31 AM > To: Chaskar Hemant (NRC/Boston); deering@cisco.com > Cc: pcalhoun@bstormnetworks.com; sob@harvard.edu; mankin@isi.edu; > Trossen Dirk (NRC/Boston); Krishnamurthi Govind (NRC/Boston); Chaskar > Hemant (NRC/Boston) > Subject: Re: Regarding CAR Discovery > > > Hemant, > > These ignore what is likely to be a common case, namely: > > Example 3: > > The MN has two interfaces, a WAN interface and a WLAN interface. The > WLAN interface is turned off to save power. The user wants to know when > the MN enters a "hot spot" area so she can switch to the WLAN interface. > The CAR discovery information must be available through the WAN > interface. > > jak > > ----- Original Message ----- > From: > To: > Cc: ; ; > ; ; ; > ; > Sent: Friday, March 22, 2002 2:20 PM > Subject: Regarding CAR Discovery > > > Hi Steve: > > Thanks for your short but insightful presentation on CAR discovery in > Seamoby @ IETF53. Allow me to say few words in this email about the > thought process that we went through during the CAR discovery problem > formulation. This will enable us to clarify some of the points that you > mentioned during this presentation. > > For this, I would like to use two illustrative examples of CAR > discovery. > > ------- > > Example 1: > > Here, an MN connected to AR_current hears a beacon from a nearby access > point (AP_new). Note that this beacon may not contain the IP address of > AR_new that governs this AP_new. MN passes on this beacon information to > AR_current, and AR_current has to map it to the IP address of AR_new. > AR_current then compares the capabilities of AR_new with the > requirements expressed by MN. These requirements are expressed by MN > prior to handoff and are made available to AR_current for CAR discovery. > If good match is found, AR_current deems AR_new as a CAR. A similar > process could occur for every AP beacon heard by MN and other CARs could > be discovered as well. CAR discovery ends here. > > CAR discovery output, i.e., this set of CARs, is one parameter used by > the target AR (TAR) selection algorithm. The output of TAR selection > decides where the MN actually hands off to. It could even be to an AR > different than CARs discovered as above. This TAR selection algorithm > may reside in the MN and/or the AR. Depending upon implementation of TAR > selection process, the CAR IDs (possibly along with their capabilities) > may have to be sent to the MN for selection. > > Example 2: > > > In this example, an MN can actually connect to the AP_new and then by > using, say, router solicitation, get the IP address of AR_new. It can > then solicit the capabilities of AR_new over the new IP layer connection > it has established and compare them with its requirements to identify > whether AR_new is a CAR. This process can be repeated for every beacon > heard by MN. Again CAR discovery ends here. > > The output of CAR discovery is fed as one input to the TAR selection > algorithm, wherever it resides, and the TAR selection algorithm then > decides the AR that the MN will be handing off to. > > ------ > > > There are performance differences between examples 1 and 2 with respect > to wireless bandwidth efficiency, speed of CAR discovery, utility > towards fast/smooth handoff protocols, MN power saving etc. > > Nonetheless, the following is true: > > - MN's requirements are always considered during CAR discovery. In > example 1, this is done by expressing them with AR_current a priori, > thereby allowing AR_current to compare them with the capabilities of > AR_new, and in example 2 by doing comparison of MN's requirements and > AR_new's capabilities in MN itself. Thus, the network does not "decide" > on behalf of MN, it however may do some processing for efficiency > purposes. > > - Following CAR discovery, it is TAR selection process which decides > where the MN is handed off to. This selection process, as pointed out > earlier, > uses CAR discovery as one possible input for this final decision. Also, > CAR discovery, either network- or MN-based, does not force any handoffs. > > Thanks for your patience in reading through this email. > > Best Regards, > > Hemant > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 19:24:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20209 for ; Sun, 24 Mar 2002 19:24:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26501 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 19:24:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26013; Sun, 24 Mar 2002 19:22:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25978 for ; Sun, 24 Mar 2002 19:22:38 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20154 for ; Sun, 24 Mar 2002 19:22:33 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0M0I14917; Sun, 24 Mar 2002 16:22:01 -0800 (PST) Message-ID: <006701c1d392$dc579da0$356015ac@T23KEMPF> From: "James Kempf" To: Cc: References: Date: Sun, 24 Mar 2002 16:20:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit (note: I've taken this to the list...) > - MN is attached to AR_current of cellular and "MN has expressed the requirement with AR_current" to let it know whenever hot-spot access opportunity exists. Note that, MN may not be able to detect hot-spot access by itself as WLAN interface is sleeping for power saving. Since AR_current knows the capabilities of GAARs (thanks to AR <-> GAAR capability exchange part of CAR discovery), it knows that WLAN access exists in neighborhood and it can intimate so to MN. It is then "upto the MN to decide" if it wants to fire up the WLAN interface and start scanning. > So the key is "expressed the requirement." What does this mean? Does the MN periodically poll the AR for this information, or does it send a subscription to receive a notification that then gets passed along as part of the MN's context transfer when the MN moves? > - During scanning, MN can do further capability discovery either as in example 1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned below. Note that, MN may detect more than one WLAN beacons during scanning as well. Also, it is worth noting that it is not the only option that CAR discovery information be available through WLAN interface. It could be obtained over cellular interface from AR_current (example 1) or over WLAN interface from GAAR (example 2). Performance/implementation tradeoffs will determine the best option. In fact, if AR_current's assistance is sought for CAR discovery (example 1), there may not be need to unnecessarily fire up WLAN interface if the capabilities of WLAN access do not match MN requirements. Even more power saving! > I had in mind primarily the latter. If the MN brings up the WLAN interface, there is no need for CAR discovery because it just needs to Neighbor Discovery (in IPv6). CAR discovery is only of interest if the MN wants to find out about other media options prior to bringing up the interface. > The requirement of indication of WLAN access in neighborhood, may be "expressed by MN explicitly with AR_current", or "statically configured in MN's profile" which may get transferred from AR to AR as handoffs occur. The requirement can be even more fine-tuned: "Tell me when WLAN access of certain provider (organization) is available in neighborhood" or "tell me when WLAN access which I am authorized to access is available in the neighborhood" etc. > Sure, but the issue is whether the MN periodically polls or there is some kind of subscription/notification protocol that gets passed along with context transfer. The former is simpler, the latter more bandwidth efficient. jak > Please let me know what you think about it. > > Best Regards, > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, March 24, 2002 12:31 AM > To: Chaskar Hemant (NRC/Boston); deering@cisco.com > Cc: pcalhoun@bstormnetworks.com; sob@harvard.edu; mankin@isi.edu; > Trossen Dirk (NRC/Boston); Krishnamurthi Govind (NRC/Boston); Chaskar > Hemant (NRC/Boston) > Subject: Re: Regarding CAR Discovery > > > Hemant, > > These ignore what is likely to be a common case, namely: > > Example 3: > > The MN has two interfaces, a WAN interface and a WLAN interface. The > WLAN interface is turned off to save power. The user wants to know when > the MN enters a "hot spot" area so she can switch to the WLAN interface. > The CAR discovery information must be available through the WAN > interface. > > jak > > ----- Original Message ----- > From: > To: > Cc: ; ; > ; ; ; > ; > Sent: Friday, March 22, 2002 2:20 PM > Subject: Regarding CAR Discovery > > > Hi Steve: > > Thanks for your short but insightful presentation on CAR discovery in > Seamoby @ IETF53. Allow me to say few words in this email about the > thought process that we went through during the CAR discovery problem > formulation. This will enable us to clarify some of the points that you > mentioned during this presentation. > > For this, I would like to use two illustrative examples of CAR > discovery. > > ------- > > Example 1: > > Here, an MN connected to AR_current hears a beacon from a nearby access > point (AP_new). Note that this beacon may not contain the IP address of > AR_new that governs this AP_new. MN passes on this beacon information to > AR_current, and AR_current has to map it to the IP address of AR_new. > AR_current then compares the capabilities of AR_new with the > requirements expressed by MN. These requirements are expressed by MN > prior to handoff and are made available to AR_current for CAR discovery. > If good match is found, AR_current deems AR_new as a CAR. A similar > process could occur for every AP beacon heard by MN and other CARs could > be discovered as well. CAR discovery ends here. > > CAR discovery output, i.e., this set of CARs, is one parameter used by > the target AR (TAR) selection algorithm. The output of TAR selection > decides where the MN actually hands off to. It could even be to an AR > different than CARs discovered as above. This TAR selection algorithm > may reside in the MN and/or the AR. Depending upon implementation of TAR > selection process, the CAR IDs (possibly along with their capabilities) > may have to be sent to the MN for selection. > > Example 2: > > > In this example, an MN can actually connect to the AP_new and then by > using, say, router solicitation, get the IP address of AR_new. It can > then solicit the capabilities of AR_new over the new IP layer connection > it has established and compare them with its requirements to identify > whether AR_new is a CAR. This process can be repeated for every beacon > heard by MN. Again CAR discovery ends here. > > The output of CAR discovery is fed as one input to the TAR selection > algorithm, wherever it resides, and the TAR selection algorithm then > decides the AR that the MN will be handing off to. > > ------ > > > There are performance differences between examples 1 and 2 with respect > to wireless bandwidth efficiency, speed of CAR discovery, utility > towards fast/smooth handoff protocols, MN power saving etc. > > Nonetheless, the following is true: > > - MN's requirements are always considered during CAR discovery. In > example 1, this is done by expressing them with AR_current a priori, > thereby allowing AR_current to compare them with the capabilities of > AR_new, and in example 2 by doing comparison of MN's requirements and > AR_new's capabilities in MN itself. Thus, the network does not "decide" > on behalf of MN, it however may do some processing for efficiency > purposes. > > - Following CAR discovery, it is TAR selection process which decides > where the MN is handed off to. This selection process, as pointed out > earlier, > uses CAR discovery as one possible input for this final decision. Also, > CAR discovery, either network- or MN-based, does not force any handoffs. > > Thanks for your patience in reading through this email. > > Best Regards, > > Hemant > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 19:39:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20413 for ; Sun, 24 Mar 2002 19:39:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27293; Sun, 24 Mar 2002 19:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27219 for ; Sun, 24 Mar 2002 19:27:41 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20248 for ; Sun, 24 Mar 2002 19:27:37 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0R4I14990; Sun, 24 Mar 2002 16:27:04 -0800 (PST) Message-ID: <006f01c1d393$91344660$356015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Sun, 24 Mar 2002 16:25:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >As per SteveD's presentation in the Minne-apple, the MN must be able to > >make the decision on its own, particularly for intertechnology. > > [HC] I agree that MN's requirements MUST always be considered during CAR > discovery. I guess, that is why we have a requirement that: "MN's > requirements MUST be made available to CAR discovery protocol." CAR > discovery is about "comparing MN's requirements with capabilities of GAAR to > identify CARs." As said in problem statement, CAR discovery does not make > any decisions about handoffs or target access routers. It simply identifies > CARs from GAARs by comparing MN's requirements with GAAR capabilities. > Decisions are made by TAR selection which may reside in MN or in network or > in both of them. TAR selection is outside the scope of CAR discovery. But > the following additional requirement may help "Output of CAR discovery MUST > be available for TAR selection algorithms wherever they are implemented (MN, > network or hybrid)." > > > > >The MN must also be able to get the information through any interface, > >even one that is currently not up. This allows the MN to keep an > >interface powered down until it knows there is an active wireless > >network in the area == power savings. > > [HC] How will MN receive information over interface that is down? It has to > receive trigger over another interface to first wake up the sleeping > interface. > It doesn't get info over a down interface, it gets it over the up interface. The protocol tells the MN what's available, including if the MN brought up the down interface. It avoids having to bring up the interface if there is nothing there. If the interface is always up, then the MN can just do standard IPv6 Neighbor Discovery and there is no need for CAR discovery. > > > >If the latter were not so, the MN could just use standard Router > >Discovery on the interface and there would be no need for CAR discovery. > > [HC]Even when other interface is awake, the capability discovery via Router > Discovery is not always efficient and it is also time and power consuming. > For this, MN needs to acquire link layer connectivity, then IP-layer > connectivity and then receive capabilities over the new connection. You have > to do this for every AP beacon that you hear. While MN is doing that its old > connection may actually go down (moving into basement of building from > cellular coverage) thereby causing disruption of service. Also, if the new > access router does not meet MN's requirements, all this capability discovery > effort (and associated power spent) goes waste. These can be avoided by > doing AR_current-assisted CAR discovery while still considering MN's > requirements. > CAR discovery is completely irrelevent if the MN brings up the interface. Neighbor Discovery is fine for discovering routers - the MN solicits router adverts, the routers send them. What's the problem? The only reason for CAR discovery is so that the MN doesn't need to bring up the interface to discover what's available. The sooner we can agree on that, the sooner we can get to the hard questions, like how to do it. jak > BR, > Hemant > > > > > > jak > > > >----- Original Message ----- > >From: > >To: ; > >Sent: Friday, March 22, 2002 11:55 AM > >Subject: RE: [Seamoby] Comments on the requirements draft > > > > > > > Hi Teemu, > > > > > > see comments inline. > > > > > > > > > 3.5 FORMAT OF CAPABILITIES > > > > > > - The format of describing the capabilities MUST be > > > extendable and flexible in a way that they support > > > future needs that cannot be exactly defined > > > at this stage. > > > > > > [DOT] in addition to this, though not a requirement as such just > > > recalling what I said in MPLS, we should evaluate what descriptions > > > are on the table (as standards/research/products), and how they could > > > fit into the problem space. This would prevent the re-invention of > > > the wheel. > > > > > > 3.X SCALABILITY > > > > > > - CAR/GAAR discovery MUST be scalable. In the future, there > > > might be geographical locations with several (hundreds) > > > of overlapping access points, especially when PANs emerge. > > > This kind of situation might lead into problems when the > > > ARs behind these APs have to constantly update their > > > knowledge of their GAARs. > > > > > > [DOT] I certainly agree with scalability, just some comments to > > > the number of several hundreds of overlapping access points. Even > > > when I consider PANs, I can hardly think of scenarios where actually > > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > > large enough, and I doubt that we had so many WLAN APs. But even then, > > > what counts is the number of ARs that have overlapping APs with APs of > > > other ARs. I don't quite see that this number would reach several > >hundreds. > > > Maybe you could elaborate a bit on the scenarios you have in mind. > > > > > > 3.X INTEROPERABILITY > > > > > > - Interoperability MUST exist with non-CAR ARs. > > > > > > [DOT] How do you mean this? If a non-CAR is (due to the lack of > >identification > > > and capability knowledge through CAR) not considered as a CAR, it > >should still > > > be possible to handover to this AR? This is indeed true but not within > >the scope > > > of CAR discovery. Since CAR discovery only gives you a set of CARs > >(which need to > > > be identified for that), it should be ok that a CAR solution does not > >include > > > these non-CAR ARs (one reason might be that the non-CAR AR did not > >allow the > > > CAR solution's GAAR identifitication - another reasons might be that > >the non-CAR > > > did not reveal capabilities). However, if the MN (or the AR) would > >find any other > > > means to identify this non-CAR AR, and the MN (or the AR) makes the > >decision to > > > handoff to this non-CAR AR, that's fine and still possible. But this > >is TAR > > > selection, which is not within the scope of CAR discovery. CAR > >discovery only > > > gives you a list of CARs (i.e., ARs that match MN's requirements), > >which is ONE > > > input to TAR selection (wherever latter is implemented). Another input > >might be > > > the detection of non-CAR ARs which you might consider in your TAR > >selection algorithm > > > as well. > > > > > > > > > 3.X PERFORMANCE > > > > > > - CAR/GAAR protocol MUST NOT add to handover times in > > > cases when the connection to the old AR is lost and there > > > are ongoing communication waiting for network access. In > > > those cases the MN must get a new AR as fast as possible, > > > not spending much time on the TAR algorithm. > > > > > > [DOT] How do decide whether it is worthwhile to spend time on CAR or > >not? > > > If you have a TAR selection scheme that resides in the MN, it is > >fairly > > > easy to do so. If your signal strength fades for instance too fast, > >you just > > > skip CAR discovery and select one of the AR from which you receive a > >current > > > beacon. But again, this is TAR selection and not within the scope of > >the problem. > > > But if you choose to do CAR (wherever it is implemented), it will > >always add > > > to your handover time since you have to run certain mechanisms. How > >this tradeoff > > > can be determined is not clear to me and looks like an implementation > >issue in > > > the entity that runs the TAR selection (which again use CAR discovery > >as an input). > > > > > > General thoughts: > > > > > > How can an AR recognize its GAARs without the help of the MN > > > or the link-layer protocols? > > > > > > This means that the amount of packets sent over the air necessarily > > > increases, doesn't it? I mean, if the AR doesn't get the information > >about > > > GAARs from the MN, then it must somehow sense the GAARs presence > >through > > > the APs. But the latter is of course impossible between APs of > >different > > > link layers. > > > > > > [DOT] Good question ;-) But is it mentioned somewhere that the > > > identification of GAARs must not be a combined job between AR and MN? > >Or it > > > might even be entirely based in the MN? Certainly, the AR-only > >solution > > > sounds kind of impossible for me, too. > > > > > > Best Regards, > > > > > > > > > Dirk > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 19:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20422 for ; Sun, 24 Mar 2002 19:39:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00044 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 19:39:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27293; Sun, 24 Mar 2002 19:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27219 for ; Sun, 24 Mar 2002 19:27:41 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20248 for ; Sun, 24 Mar 2002 19:27:37 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0R4I14990; Sun, 24 Mar 2002 16:27:04 -0800 (PST) Message-ID: <006f01c1d393$91344660$356015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Sun, 24 Mar 2002 16:25:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >As per SteveD's presentation in the Minne-apple, the MN must be able to > >make the decision on its own, particularly for intertechnology. > > [HC] I agree that MN's requirements MUST always be considered during CAR > discovery. I guess, that is why we have a requirement that: "MN's > requirements MUST be made available to CAR discovery protocol." CAR > discovery is about "comparing MN's requirements with capabilities of GAAR to > identify CARs." As said in problem statement, CAR discovery does not make > any decisions about handoffs or target access routers. It simply identifies > CARs from GAARs by comparing MN's requirements with GAAR capabilities. > Decisions are made by TAR selection which may reside in MN or in network or > in both of them. TAR selection is outside the scope of CAR discovery. But > the following additional requirement may help "Output of CAR discovery MUST > be available for TAR selection algorithms wherever they are implemented (MN, > network or hybrid)." > > > > >The MN must also be able to get the information through any interface, > >even one that is currently not up. This allows the MN to keep an > >interface powered down until it knows there is an active wireless > >network in the area == power savings. > > [HC] How will MN receive information over interface that is down? It has to > receive trigger over another interface to first wake up the sleeping > interface. > It doesn't get info over a down interface, it gets it over the up interface. The protocol tells the MN what's available, including if the MN brought up the down interface. It avoids having to bring up the interface if there is nothing there. If the interface is always up, then the MN can just do standard IPv6 Neighbor Discovery and there is no need for CAR discovery. > > > >If the latter were not so, the MN could just use standard Router > >Discovery on the interface and there would be no need for CAR discovery. > > [HC]Even when other interface is awake, the capability discovery via Router > Discovery is not always efficient and it is also time and power consuming. > For this, MN needs to acquire link layer connectivity, then IP-layer > connectivity and then receive capabilities over the new connection. You have > to do this for every AP beacon that you hear. While MN is doing that its old > connection may actually go down (moving into basement of building from > cellular coverage) thereby causing disruption of service. Also, if the new > access router does not meet MN's requirements, all this capability discovery > effort (and associated power spent) goes waste. These can be avoided by > doing AR_current-assisted CAR discovery while still considering MN's > requirements. > CAR discovery is completely irrelevent if the MN brings up the interface. Neighbor Discovery is fine for discovering routers - the MN solicits router adverts, the routers send them. What's the problem? The only reason for CAR discovery is so that the MN doesn't need to bring up the interface to discover what's available. The sooner we can agree on that, the sooner we can get to the hard questions, like how to do it. jak > BR, > Hemant > > > > > > jak > > > >----- Original Message ----- > >From: > >To: ; > >Sent: Friday, March 22, 2002 11:55 AM > >Subject: RE: [Seamoby] Comments on the requirements draft > > > > > > > Hi Teemu, > > > > > > see comments inline. > > > > > > > > > 3.5 FORMAT OF CAPABILITIES > > > > > > - The format of describing the capabilities MUST be > > > extendable and flexible in a way that they support > > > future needs that cannot be exactly defined > > > at this stage. > > > > > > [DOT] in addition to this, though not a requirement as such just > > > recalling what I said in MPLS, we should evaluate what descriptions > > > are on the table (as standards/research/products), and how they could > > > fit into the problem space. This would prevent the re-invention of > > > the wheel. > > > > > > 3.X SCALABILITY > > > > > > - CAR/GAAR discovery MUST be scalable. In the future, there > > > might be geographical locations with several (hundreds) > > > of overlapping access points, especially when PANs emerge. > > > This kind of situation might lead into problems when the > > > ARs behind these APs have to constantly update their > > > knowledge of their GAARs. > > > > > > [DOT] I certainly agree with scalability, just some comments to > > > the number of several hundreds of overlapping access points. Even > > > when I consider PANs, I can hardly think of scenarios where actually > > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > > large enough, and I doubt that we had so many WLAN APs. But even then, > > > what counts is the number of ARs that have overlapping APs with APs of > > > other ARs. I don't quite see that this number would reach several > >hundreds. > > > Maybe you could elaborate a bit on the scenarios you have in mind. > > > > > > 3.X INTEROPERABILITY > > > > > > - Interoperability MUST exist with non-CAR ARs. > > > > > > [DOT] How do you mean this? If a non-CAR is (due to the lack of > >identification > > > and capability knowledge through CAR) not considered as a CAR, it > >should still > > > be possible to handover to this AR? This is indeed true but not within > >the scope > > > of CAR discovery. Since CAR discovery only gives you a set of CARs > >(which need to > > > be identified for that), it should be ok that a CAR solution does not > >include > > > these non-CAR ARs (one reason might be that the non-CAR AR did not > >allow the > > > CAR solution's GAAR identifitication - another reasons might be that > >the non-CAR > > > did not reveal capabilities). However, if the MN (or the AR) would > >find any other > > > means to identify this non-CAR AR, and the MN (or the AR) makes the > >decision to > > > handoff to this non-CAR AR, that's fine and still possible. But this > >is TAR > > > selection, which is not within the scope of CAR discovery. CAR > >discovery only > > > gives you a list of CARs (i.e., ARs that match MN's requirements), > >which is ONE > > > input to TAR selection (wherever latter is implemented). Another input > >might be > > > the detection of non-CAR ARs which you might consider in your TAR > >selection algorithm > > > as well. > > > > > > > > > 3.X PERFORMANCE > > > > > > - CAR/GAAR protocol MUST NOT add to handover times in > > > cases when the connection to the old AR is lost and there > > > are ongoing communication waiting for network access. In > > > those cases the MN must get a new AR as fast as possible, > > > not spending much time on the TAR algorithm. > > > > > > [DOT] How do decide whether it is worthwhile to spend time on CAR or > >not? > > > If you have a TAR selection scheme that resides in the MN, it is > >fairly > > > easy to do so. If your signal strength fades for instance too fast, > >you just > > > skip CAR discovery and select one of the AR from which you receive a > >current > > > beacon. But again, this is TAR selection and not within the scope of > >the problem. > > > But if you choose to do CAR (wherever it is implemented), it will > >always add > > > to your handover time since you have to run certain mechanisms. How > >this tradeoff > > > can be determined is not clear to me and looks like an implementation > >issue in > > > the entity that runs the TAR selection (which again use CAR discovery > >as an input). > > > > > > General thoughts: > > > > > > How can an AR recognize its GAARs without the help of the MN > > > or the link-layer protocols? > > > > > > This means that the amount of packets sent over the air necessarily > > > increases, doesn't it? I mean, if the AR doesn't get the information > >about > > > GAARs from the MN, then it must somehow sense the GAARs presence > >through > > > the APs. But the latter is of course impossible between APs of > >different > > > link layers. > > > > > > [DOT] Good question ;-) But is it mentioned somewhere that the > > > identification of GAARs must not be a combined job between AR and MN? > >Or it > > > might even be entirely based in the MN? Certainly, the AR-only > >solution > > > sounds kind of impossible for me, too. > > > > > > Best Regards, > > > > > > > > > Dirk > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 24 19:48:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20486 for ; Sun, 24 Mar 2002 19:48:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00818; Sun, 24 Mar 2002 19:43:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00791 for ; Sun, 24 Mar 2002 19:43:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20456 for ; Sun, 24 Mar 2002 19:43:12 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0gSI15166; Sun, 24 Mar 2002 16:42:29 -0800 (PST) Message-ID: <009701c1d395$b84a7600$356015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 24 Mar 2002 16:40:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > After the CAR discovery discussion in IETF53, it seems that we need to > emphasize certain points about CAR discovery. They are as follows: > > - CAR discovery always considers MN requirements while choosing CARs from > GAARs. > This statement sounds like some other entity beside the MN is doing the choosing (TAR selection). I can't see the relevance of CAR discovery other than in the following cases: 1) There are multiple wireless media options (e.g. cellular and WLAN) and one medium has wider coverage than the other (e.g. cellular is typically a WAN while WLAN is typically only for hotspots). 2) The MN has two interfaces. 3) The MN wants to keep one interface off while using the other. 4) The MN wants to be informed when it enters or leaves the coverage area of the less dense coverage option. Only the MN is in a position to make a choice, that's what Steve's talk was all about. So I would rephrase this: CAR discovery provides the MN with information on CARs for the MN to choose which TAR it wants to hand over to. > - CAR discovery _does not_ make any handoff decisions. It merely chooses > CARs (by matching MN's requirements with GAARs' capabilities) and makes this > information available to TAR selection algorithms. TAR selection algorithms > (whether they reside in MN or network or both) make decision about TAR for > handoff. > Can you give me an example of when the network would want to select? In every case where I can think of needing CAR discovery, intertechnology handover is required and the MN must be involved in order to bring up and connect the new interface. For single technology handover, you don't need CAR discovery. In that case, either the network or the MN can do it, but the choice of next AR is predetermined by the Layer 2 power characteristics. > - CAR discovery does not force any handoffs and it does not advocate any > network-based handoff decision making. > OK, but like I said, I don't see the relevence to network handover to CAR discovery. > Example 1: > ---------- > > Here, an MN connected to AR_current hears a beacon from a nearby access > point (AP_new). Note that this beacon may not contain the IP address of > AR_new that governs this AP_new. MN passes on this beacon information to > AR_current, and AR_current has to map it to the IP address of AR_new. If MN can hear the beacon, why doesn't it simply solicit a router advert? There's no need for the current AR to get involved. > AR_current then compares the capabilities of AR_new with the > requirements expressed by MN. These requirements are expressed by MN > prior to handoff and are made available to AR_current for CAR discovery. > If good match is found, AR_current deems AR_new as a CAR. A similar > process could occur for every AP beacon heard by MN and other CARs could > be discovered as well. CAR discovery ends here. > This is too complicated. After solcitiing the new RA, the MN can decide whether to connect or not. What's the point of all this communication with the old AR when the MN can already hear the new one? > CAR discovery output, i.e., this set of CARs, is one parameter used by > the target AR (TAR) selection algorithm. The output of TAR selection > decides where the MN actually hands off to. It could even be to an AR > different than CARs discovered as above. This TAR selection algorithm > may reside in the MN and/or the AR. Depending upon implementation of TAR > selection process, the CAR IDs (possibly along with their capabilities) > may have to be sent to the MN for selection. > > Example 2: > ---------- > > In this example, an MN can actually connect to the AP_new and then by > using, say, router solicitation, get the IP address of AR_new. It can > then solicit the capabilities of AR_new over the new IP layer connection > it has established and compare them with its requirements to identify > whether AR_new is a CAR. This process can be repeated for every beacon > heard by MN. Again CAR discovery ends here. > Why is this any different than Example 1? If the MN can get a beacon, why can't it solicit an RA? And if it can't solicit an RA, then what is the point of the MN even bringing up the interface to get a beacon? It should just leave the interface down and use CAR discovery with the current AR to find out if there are any routers on the other medium around. > The output of CAR discovery is fed as one input to the TAR selection > algorithm, wherever it resides, and the TAR selection algorithm then > decides the AR that the MN will be handing off to. > > There are performance differences between examples 1 and 2 with respect > to wireless bandwidth efficiency, speed of CAR discovery, utility > towards fast/smooth handoff protocols, MN power saving etc. > > > Example 3: > ---------- > > Here MN is connected to cellular network over one interface and its other > interface (WLAN) is sleeping for power saving purposes. > This is the only example I think makes sense. > MN is attached to AR_current of cellular and "MN has expressed the > requirement with AR_current" to let it know whenever hot-spot access > opportunity exists. Note that, MN may not be able to detect hot-spot access > by itself as WLAN interface is sleeping for power saving. Since AR_current > knows the capabilities of GAARs (thanks to AR <-> GAAR capability exchange > part of CAR discovery), it knows that WLAN access exists in neighborhood and > it can intimate so to MN. It is then "upto the MN to decide" if it wants to > fire up the WLAN interface and start scanning. > The current AR doesn't have to be involved if the MN periodically polls. That's an implementation assumption. > During scanning, MN can do further capability discovery either as in example > 1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned > above. Note that, MN may detect more than one WLAN beacons during scanning > as well. Also, it is worth noting that it is not the only option that CAR > discovery information be available through WLAN interface. It could be > obtained over cellular interface from AR_current (example 1) or over WLAN > interface from GAAR (example 2). Performance/implementation tradeoffs will > determine the best option. In fact, if AR_current's assistance is sought for > CAR discovery (example 1), there may not be need to unnecessarily fire up > WLAN interface if the capabilities of WLAN access do not match MN > requirements. Even more power saving! > > Please provide your feedback on these. > > BR, > Hemant > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 24 19:48:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20494 for ; Sun, 24 Mar 2002 19:48:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01971 for seamoby-archive@odin.ietf.org; Sun, 24 Mar 2002 19:48:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00818; Sun, 24 Mar 2002 19:43:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00791 for ; Sun, 24 Mar 2002 19:43:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20456 for ; Sun, 24 Mar 2002 19:43:12 -0500 (EST) Received: from T23KEMPF (dhcp53.docomolabs-usa.com [172.21.96.53]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2P0gSI15166; Sun, 24 Mar 2002 16:42:29 -0800 (PST) Message-ID: <009701c1d395$b84a7600$356015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 24 Mar 2002 16:40:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > After the CAR discovery discussion in IETF53, it seems that we need to > emphasize certain points about CAR discovery. They are as follows: > > - CAR discovery always considers MN requirements while choosing CARs from > GAARs. > This statement sounds like some other entity beside the MN is doing the choosing (TAR selection). I can't see the relevance of CAR discovery other than in the following cases: 1) There are multiple wireless media options (e.g. cellular and WLAN) and one medium has wider coverage than the other (e.g. cellular is typically a WAN while WLAN is typically only for hotspots). 2) The MN has two interfaces. 3) The MN wants to keep one interface off while using the other. 4) The MN wants to be informed when it enters or leaves the coverage area of the less dense coverage option. Only the MN is in a position to make a choice, that's what Steve's talk was all about. So I would rephrase this: CAR discovery provides the MN with information on CARs for the MN to choose which TAR it wants to hand over to. > - CAR discovery _does not_ make any handoff decisions. It merely chooses > CARs (by matching MN's requirements with GAARs' capabilities) and makes this > information available to TAR selection algorithms. TAR selection algorithms > (whether they reside in MN or network or both) make decision about TAR for > handoff. > Can you give me an example of when the network would want to select? In every case where I can think of needing CAR discovery, intertechnology handover is required and the MN must be involved in order to bring up and connect the new interface. For single technology handover, you don't need CAR discovery. In that case, either the network or the MN can do it, but the choice of next AR is predetermined by the Layer 2 power characteristics. > - CAR discovery does not force any handoffs and it does not advocate any > network-based handoff decision making. > OK, but like I said, I don't see the relevence to network handover to CAR discovery. > Example 1: > ---------- > > Here, an MN connected to AR_current hears a beacon from a nearby access > point (AP_new). Note that this beacon may not contain the IP address of > AR_new that governs this AP_new. MN passes on this beacon information to > AR_current, and AR_current has to map it to the IP address of AR_new. If MN can hear the beacon, why doesn't it simply solicit a router advert? There's no need for the current AR to get involved. > AR_current then compares the capabilities of AR_new with the > requirements expressed by MN. These requirements are expressed by MN > prior to handoff and are made available to AR_current for CAR discovery. > If good match is found, AR_current deems AR_new as a CAR. A similar > process could occur for every AP beacon heard by MN and other CARs could > be discovered as well. CAR discovery ends here. > This is too complicated. After solcitiing the new RA, the MN can decide whether to connect or not. What's the point of all this communication with the old AR when the MN can already hear the new one? > CAR discovery output, i.e., this set of CARs, is one parameter used by > the target AR (TAR) selection algorithm. The output of TAR selection > decides where the MN actually hands off to. It could even be to an AR > different than CARs discovered as above. This TAR selection algorithm > may reside in the MN and/or the AR. Depending upon implementation of TAR > selection process, the CAR IDs (possibly along with their capabilities) > may have to be sent to the MN for selection. > > Example 2: > ---------- > > In this example, an MN can actually connect to the AP_new and then by > using, say, router solicitation, get the IP address of AR_new. It can > then solicit the capabilities of AR_new over the new IP layer connection > it has established and compare them with its requirements to identify > whether AR_new is a CAR. This process can be repeated for every beacon > heard by MN. Again CAR discovery ends here. > Why is this any different than Example 1? If the MN can get a beacon, why can't it solicit an RA? And if it can't solicit an RA, then what is the point of the MN even bringing up the interface to get a beacon? It should just leave the interface down and use CAR discovery with the current AR to find out if there are any routers on the other medium around. > The output of CAR discovery is fed as one input to the TAR selection > algorithm, wherever it resides, and the TAR selection algorithm then > decides the AR that the MN will be handing off to. > > There are performance differences between examples 1 and 2 with respect > to wireless bandwidth efficiency, speed of CAR discovery, utility > towards fast/smooth handoff protocols, MN power saving etc. > > > Example 3: > ---------- > > Here MN is connected to cellular network over one interface and its other > interface (WLAN) is sleeping for power saving purposes. > This is the only example I think makes sense. > MN is attached to AR_current of cellular and "MN has expressed the > requirement with AR_current" to let it know whenever hot-spot access > opportunity exists. Note that, MN may not be able to detect hot-spot access > by itself as WLAN interface is sleeping for power saving. Since AR_current > knows the capabilities of GAARs (thanks to AR <-> GAAR capability exchange > part of CAR discovery), it knows that WLAN access exists in neighborhood and > it can intimate so to MN. It is then "upto the MN to decide" if it wants to > fire up the WLAN interface and start scanning. > The current AR doesn't have to be involved if the MN periodically polls. That's an implementation assumption. > During scanning, MN can do further capability discovery either as in example > 1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned > above. Note that, MN may detect more than one WLAN beacons during scanning > as well. Also, it is worth noting that it is not the only option that CAR > discovery information be available through WLAN interface. It could be > obtained over cellular interface from AR_current (example 1) or over WLAN > interface from GAAR (example 2). Performance/implementation tradeoffs will > determine the best option. In fact, if AR_current's assistance is sought for > CAR discovery (example 1), there may not be need to unnecessarily fire up > WLAN interface if the capabilities of WLAN access do not match MN > requirements. Even more power saving! > > Please provide your feedback on these. > > BR, > Hemant > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 02:31:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04891 for ; Mon, 25 Mar 2002 02:31:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01205; Mon, 25 Mar 2002 02:23:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01172 for ; Mon, 25 Mar 2002 02:23:48 -0500 (EST) Received: from hotmail.com (oe69.law4.hotmail.com [216.33.148.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04752 for ; Mon, 25 Mar 2002 02:23:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Mar 2002 23:23:17 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: <009701c1d395$b84a7600$356015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 16:28:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 25 Mar 2002 07:23:17.0247 (UTC) FILETIME=[EEDF90F0:01C1D3CD] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, James, My comments are inline. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Hemant Chaskar" ; Sent: Sunday, March 24, 2002 4:40 PM Subject: Re: [Seamoby] Examples of CAR discovery > > After the CAR discovery discussion in IETF53, it seems that we need to > > emphasize certain points about CAR discovery. They are as follows: > > > > - CAR discovery always considers MN requirements while choosing CARs > from > > GAARs. > > > > This statement sounds like some other entity beside the MN is doing the > choosing (TAR selection). I can't see the relevance of CAR discovery > other than in the following cases: > > 1) There are multiple wireless media options (e.g. cellular and WLAN) > and one medium has wider coverage than the other (e.g. cellular is > typically a WAN while WLAN is typically only for hotspots). > 2) The MN has two interfaces. > 3) The MN wants to keep one interface off while using the other. > 4) The MN wants to be informed when it enters or leaves the coverage > area of the less dense coverage option. > > Only the MN is in a position to make a choice, that's what Steve's talk > was all about. So I would rephrase this: > > CAR discovery provides the MN with information on CARs for the MN to > choose which TAR it wants to > hand over to. > > > - CAR discovery _does not_ make any handoff decisions. It merely > chooses > > CARs (by matching MN's requirements with GAARs' capabilities) and > makes this > > information available to TAR selection algorithms. TAR selection > algorithms > > (whether they reside in MN or network or both) make decision about TAR > for > > handoff. > > > > Can you give me an example of when the network would want to select? In > every case where I can think of needing CAR discovery, intertechnology > handover is required and the MN must be involved in order to bring up > and connect the new interface. For single technology handover, you don't > need CAR discovery. In that case, either the network or the MN can do > it, but the choice of next AR is predetermined by the Layer 2 power > characteristics. > Please just let me remind you that the CAR discovery protocol also provides mapping of L2 ID to IP address of the new AR which is necessary for the low-latency handoff mechanism proposed in the MobileIP WG. So there is a case CAR discovery is helpful for single technology handovers. I understand the IETF is pro-end-point-control. Anyway, regarding your question, couldn't we imagine a case when a network provider wants do a kind of load-balancing between different access networks in the wireless overlay network? > > - CAR discovery does not force any handoffs and it does not advocate > any > > network-based handoff decision making. > > > > OK, but like I said, I don't see the relevence to network handover to > CAR discovery. > > > Example 1: > > ---------- > > > > Here, an MN connected to AR_current hears a beacon from a nearby > access > > point (AP_new). Note that this beacon may not contain the IP address > of > > AR_new that governs this AP_new. MN passes on this beacon information > to > > AR_current, and AR_current has to map it to the IP address of AR_new. > > If MN can hear the beacon, why doesn't it simply solicit a router > advert? There's no need for the current AR to get involved. > I think the beacon in this example is L2 beacon. Isn't there a case the MN needs to go several steps before it can send a router solicitation message? I think it depends on the involved L2 technology. Anyway the MN can get the information it needs without soliciting the new AR by using CAR discovery. The point of this example seems to me that the MN does not go through such steps to save power. > > AR_current then compares the capabilities of AR_new with the > > requirements expressed by MN. These requirements are expressed by MN > > prior to handoff and are made available to AR_current for CAR > discovery. > > If good match is found, AR_current deems AR_new as a CAR. A similar > > process could occur for every AP beacon heard by MN and other CARs > could > > be discovered as well. CAR discovery ends here. > > > > This is too complicated. After solcitiing the new RA, the MN can decide > whether to connect or not. > What's the point of all this communication with the old AR when the MN > can already hear the > new one? > > > CAR discovery output, i.e., this set of CARs, is one parameter used by > > the target AR (TAR) selection algorithm. The output of TAR selection > > decides where the MN actually hands off to. It could even be to an AR > > different than CARs discovered as above. This TAR selection algorithm > > may reside in the MN and/or the AR. Depending upon implementation of > TAR > > selection process, the CAR IDs (possibly along with their > capabilities) > > may have to be sent to the MN for selection. > > > > Example 2: > > ---------- > > > > In this example, an MN can actually connect to the AP_new and then by > > using, say, router solicitation, get the IP address of AR_new. It can > > then solicit the capabilities of AR_new over the new IP layer > connection > > it has established and compare them with its requirements to identify > > whether AR_new is a CAR. This process can be repeated for every beacon > > heard by MN. Again CAR discovery ends here. > > > > Why is this any different than Example 1? If the MN can get a beacon, > why can't it solicit an RA? And if it can't solicit an RA, then what is > the point of the MN even bringing up the interface to get a beacon? It > should just leave the interface down and use CAR discovery with the > current AR to find out if there are any routers on the other medium > around. > > > The output of CAR discovery is fed as one input to the TAR selection > > algorithm, wherever it resides, and the TAR selection algorithm then > > decides the AR that the MN will be handing off to. > > > > There are performance differences between examples 1 and 2 with > respect > > to wireless bandwidth efficiency, speed of CAR discovery, utility > > towards fast/smooth handoff protocols, MN power saving etc. > > > > > > Example 3: > > ---------- > > > > Here MN is connected to cellular network over one interface and its > other > > interface (WLAN) is sleeping for power saving purposes. > > > > This is the only example I think makes sense. > > > MN is attached to AR_current of cellular and "MN has expressed the > > requirement with AR_current" to let it know whenever hot-spot access > > opportunity exists. Note that, MN may not be able to detect hot-spot > access > > by itself as WLAN interface is sleeping for power saving. Since > AR_current > > knows the capabilities of GAARs (thanks to AR <-> GAAR capability > exchange > > part of CAR discovery), it knows that WLAN access exists in > neighborhood and > > it can intimate so to MN. It is then "upto the MN to decide" if it > wants to > > fire up the WLAN interface and start scanning. > > > > The current AR doesn't have to be involved if the MN periodically polls. > That's an implementation assumption. > > > During scanning, MN can do further capability discovery either as in > example > > 1 (AR_current assisted) or example 2 (AR_current non-assisted) > mentioned > > above. Note that, MN may detect more than one WLAN beacons during > scanning > > as well. Also, it is worth noting that it is not the only option that > CAR > > discovery information be available through WLAN interface. It could be > > obtained over cellular interface from AR_current (example 1) or over > WLAN > > interface from GAAR (example 2). Performance/implementation tradeoffs > will > > determine the best option. In fact, if AR_current's assistance is > sought for > > CAR discovery (example 1), there may not be need to unnecessarily fire > up > > WLAN interface if the capabilities of WLAN access do not match MN > > requirements. Even more power saving! > > > > Please provide your feedback on these. > > > > BR, > > Hemant > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 02:31:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04905 for ; Mon, 25 Mar 2002 02:31:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA03064 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 02:31:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01205; Mon, 25 Mar 2002 02:23:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01172 for ; Mon, 25 Mar 2002 02:23:48 -0500 (EST) Received: from hotmail.com (oe69.law4.hotmail.com [216.33.148.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04752 for ; Mon, 25 Mar 2002 02:23:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Mar 2002 23:23:17 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: <009701c1d395$b84a7600$356015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 16:28:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 25 Mar 2002 07:23:17.0247 (UTC) FILETIME=[EEDF90F0:01C1D3CD] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, James, My comments are inline. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Hemant Chaskar" ; Sent: Sunday, March 24, 2002 4:40 PM Subject: Re: [Seamoby] Examples of CAR discovery > > After the CAR discovery discussion in IETF53, it seems that we need to > > emphasize certain points about CAR discovery. They are as follows: > > > > - CAR discovery always considers MN requirements while choosing CARs > from > > GAARs. > > > > This statement sounds like some other entity beside the MN is doing the > choosing (TAR selection). I can't see the relevance of CAR discovery > other than in the following cases: > > 1) There are multiple wireless media options (e.g. cellular and WLAN) > and one medium has wider coverage than the other (e.g. cellular is > typically a WAN while WLAN is typically only for hotspots). > 2) The MN has two interfaces. > 3) The MN wants to keep one interface off while using the other. > 4) The MN wants to be informed when it enters or leaves the coverage > area of the less dense coverage option. > > Only the MN is in a position to make a choice, that's what Steve's talk > was all about. So I would rephrase this: > > CAR discovery provides the MN with information on CARs for the MN to > choose which TAR it wants to > hand over to. > > > - CAR discovery _does not_ make any handoff decisions. It merely > chooses > > CARs (by matching MN's requirements with GAARs' capabilities) and > makes this > > information available to TAR selection algorithms. TAR selection > algorithms > > (whether they reside in MN or network or both) make decision about TAR > for > > handoff. > > > > Can you give me an example of when the network would want to select? In > every case where I can think of needing CAR discovery, intertechnology > handover is required and the MN must be involved in order to bring up > and connect the new interface. For single technology handover, you don't > need CAR discovery. In that case, either the network or the MN can do > it, but the choice of next AR is predetermined by the Layer 2 power > characteristics. > Please just let me remind you that the CAR discovery protocol also provides mapping of L2 ID to IP address of the new AR which is necessary for the low-latency handoff mechanism proposed in the MobileIP WG. So there is a case CAR discovery is helpful for single technology handovers. I understand the IETF is pro-end-point-control. Anyway, regarding your question, couldn't we imagine a case when a network provider wants do a kind of load-balancing between different access networks in the wireless overlay network? > > - CAR discovery does not force any handoffs and it does not advocate > any > > network-based handoff decision making. > > > > OK, but like I said, I don't see the relevence to network handover to > CAR discovery. > > > Example 1: > > ---------- > > > > Here, an MN connected to AR_current hears a beacon from a nearby > access > > point (AP_new). Note that this beacon may not contain the IP address > of > > AR_new that governs this AP_new. MN passes on this beacon information > to > > AR_current, and AR_current has to map it to the IP address of AR_new. > > If MN can hear the beacon, why doesn't it simply solicit a router > advert? There's no need for the current AR to get involved. > I think the beacon in this example is L2 beacon. Isn't there a case the MN needs to go several steps before it can send a router solicitation message? I think it depends on the involved L2 technology. Anyway the MN can get the information it needs without soliciting the new AR by using CAR discovery. The point of this example seems to me that the MN does not go through such steps to save power. > > AR_current then compares the capabilities of AR_new with the > > requirements expressed by MN. These requirements are expressed by MN > > prior to handoff and are made available to AR_current for CAR > discovery. > > If good match is found, AR_current deems AR_new as a CAR. A similar > > process could occur for every AP beacon heard by MN and other CARs > could > > be discovered as well. CAR discovery ends here. > > > > This is too complicated. After solcitiing the new RA, the MN can decide > whether to connect or not. > What's the point of all this communication with the old AR when the MN > can already hear the > new one? > > > CAR discovery output, i.e., this set of CARs, is one parameter used by > > the target AR (TAR) selection algorithm. The output of TAR selection > > decides where the MN actually hands off to. It could even be to an AR > > different than CARs discovered as above. This TAR selection algorithm > > may reside in the MN and/or the AR. Depending upon implementation of > TAR > > selection process, the CAR IDs (possibly along with their > capabilities) > > may have to be sent to the MN for selection. > > > > Example 2: > > ---------- > > > > In this example, an MN can actually connect to the AP_new and then by > > using, say, router solicitation, get the IP address of AR_new. It can > > then solicit the capabilities of AR_new over the new IP layer > connection > > it has established and compare them with its requirements to identify > > whether AR_new is a CAR. This process can be repeated for every beacon > > heard by MN. Again CAR discovery ends here. > > > > Why is this any different than Example 1? If the MN can get a beacon, > why can't it solicit an RA? And if it can't solicit an RA, then what is > the point of the MN even bringing up the interface to get a beacon? It > should just leave the interface down and use CAR discovery with the > current AR to find out if there are any routers on the other medium > around. > > > The output of CAR discovery is fed as one input to the TAR selection > > algorithm, wherever it resides, and the TAR selection algorithm then > > decides the AR that the MN will be handing off to. > > > > There are performance differences between examples 1 and 2 with > respect > > to wireless bandwidth efficiency, speed of CAR discovery, utility > > towards fast/smooth handoff protocols, MN power saving etc. > > > > > > Example 3: > > ---------- > > > > Here MN is connected to cellular network over one interface and its > other > > interface (WLAN) is sleeping for power saving purposes. > > > > This is the only example I think makes sense. > > > MN is attached to AR_current of cellular and "MN has expressed the > > requirement with AR_current" to let it know whenever hot-spot access > > opportunity exists. Note that, MN may not be able to detect hot-spot > access > > by itself as WLAN interface is sleeping for power saving. Since > AR_current > > knows the capabilities of GAARs (thanks to AR <-> GAAR capability > exchange > > part of CAR discovery), it knows that WLAN access exists in > neighborhood and > > it can intimate so to MN. It is then "upto the MN to decide" if it > wants to > > fire up the WLAN interface and start scanning. > > > > The current AR doesn't have to be involved if the MN periodically polls. > That's an implementation assumption. > > > During scanning, MN can do further capability discovery either as in > example > > 1 (AR_current assisted) or example 2 (AR_current non-assisted) > mentioned > > above. Note that, MN may detect more than one WLAN beacons during > scanning > > as well. Also, it is worth noting that it is not the only option that > CAR > > discovery information be available through WLAN interface. It could be > > obtained over cellular interface from AR_current (example 1) or over > WLAN > > interface from GAAR (example 2). Performance/implementation tradeoffs > will > > determine the best option. In fact, if AR_current's assistance is > sought for > > CAR discovery (example 1), there may not be need to unnecessarily fire > up > > WLAN interface if the capabilities of WLAN access do not match MN > > requirements. Even more power saving! > > > > Please provide your feedback on these. > > > > BR, > > Hemant > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 03:53:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05626 for ; Mon, 25 Mar 2002 03:53:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21890; Mon, 25 Mar 2002 03:50:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21855 for ; Mon, 25 Mar 2002 03:50:21 -0500 (EST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05596 for ; Mon, 25 Mar 2002 03:50:16 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g2P8oEK14182; Mon, 25 Mar 2002 14:20:14 +0530 (IST) Received: from SATISHJ (pcz-satishj.sasken.com [10.1.36.146]) by sunrnd2.sasken.com (8.11.6/8.11.6) with SMTP id g2P8oCL12954; Mon, 25 Mar 2002 14:20:12 +0530 (IST) Message-ID: <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> From: "Satish Jamadagni" To: "Eunsoo Shim" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 14:21:03 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dear All, Some comments on CAR discovery - We all agree that the CAR discovery protocol should assist in identifying GAARs, arrive at CARs from GAARs and finally a TAR from the CARs. Throughout this process one can see that there will be varied level of information exchange (context information basically). When identifying the GAARs either the MN or the AR or a edge device needs to know the geographic coverage of that AR (one can argue that more can be added at this stage itself). Now from GAARs to CARs one would expect that the CAR discovery protocol would provide more than just the geographic coverage. An exchange of a very high level view of QoS or context support information between ARs (QoS and context types will have to be agreed upon for this) is what is expected to arrive at a set of CARs - now till this stage the MN need not come into play at all. The use of a MNs personal settings and preferences will come into play at the stage of CARs to TAR. Usually (I dont know if in the future classes of MNs can be identified and TARs selected for them as a class) the TAR selection will be biased by the MN considerations - but then again the MN might have prevelages with the AR so that the AR itself can achieve this for a (or a class of) MNs. Also there should be provision for an AR to do a TAR selection given the fact that the service provider can have policies that can force a mobiles to handover due to load conditions, inorder to provide better QoS when the load on other ARs or the underlying L2 becomes available (One of the most critical understanding of a 4G network is that there are a host of L2s with a common IP layer and above) in the present understanding and spectrum sharing in future SDR scenarios (Please note that inter-technology handover is where much in the understanding of future 4G and SDR networks - we dont want our CAR protocol to undergo a lot of changes when the notion of seamless ness as required by a 4G or an SDR network hits the scene) . The idea of a CAR discovery protocol SHOULD be to make available the right amount of information at the right time for the GAARs to CARs to TAR process. The rest i.e. the exact selection of a subset of GAARs as CARs and the selection of a TAR should be left open for people like us to make a living by fitting algorithms in place. Also there were Qs like CAR being relavent in some scenarios - I think we should not restrict ourselves to just the MN option - you never know when the service providers would start offering that extra bit of processing at the network level as a service differentiator - The MN is of course the king in the TAR selection, but he can have a better understanding with his home network when the AR can do a TAR selection for the MN considering the MNs very private settings too. The AR if bound by a QoS policy might want a user to go to another specific AR with or without an underlying L2 change at his bidding. With all the paging and solication protocols evolving there should also be a provision for any AR to "entice" a MN into his domain - so to say there should be provision for an AR to declare to an MN that he is the best AR for the MN (target triggered case) - Of course how does the AR come to know of the MN and his QoS settings - at some high level this is possible - going lower and being sensitive to privacy issues - one will have to work out the issues. Regards, Satish Jamadagni. Research Scientist Sasken Communication Technologies Ltd Bangalore. ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Tuesday, March 26, 2002 5:58 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hi, James, > > My comments are inline. > Thanks. > > Eunsoo > ----- Original Message ----- > From: "James Kempf" > To: "Hemant Chaskar" ; > Sent: Sunday, March 24, 2002 4:40 PM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > After the CAR discovery discussion in IETF53, it seems that we need to > > > emphasize certain points about CAR discovery. They are as follows: > > > > > > - CAR discovery always considers MN requirements while choosing CARs > > from > > > GAARs. > > > > > > > This statement sounds like some other entity beside the MN is doing the > > choosing (TAR selection). I can't see the relevance of CAR discovery > > other than in the following cases: > > > > 1) There are multiple wireless media options (e.g. cellular and WLAN) > > and one medium has wider coverage than the other (e.g. cellular is > > typically a WAN while WLAN is typically only for hotspots). > > 2) The MN has two interfaces. > > 3) The MN wants to keep one interface off while using the other. > > 4) The MN wants to be informed when it enters or leaves the coverage > > area of the less dense coverage option. > > > > Only the MN is in a position to make a choice, that's what Steve's talk > > was all about. So I would rephrase this: > > > > CAR discovery provides the MN with information on CARs for the MN to > > choose which TAR it wants to > > hand over to. > > > > > - CAR discovery _does not_ make any handoff decisions. It merely > > chooses > > > CARs (by matching MN's requirements with GAARs' capabilities) and > > makes this > > > information available to TAR selection algorithms. TAR selection > > algorithms > > > (whether they reside in MN or network or both) make decision about TAR > > for > > > handoff. > > > > > > > Can you give me an example of when the network would want to select? In > > every case where I can think of needing CAR discovery, intertechnology > > handover is required and the MN must be involved in order to bring up > > and connect the new interface. For single technology handover, you don't > > need CAR discovery. In that case, either the network or the MN can do > > it, but the choice of next AR is predetermined by the Layer 2 power > > characteristics. > > > Please just let me remind you that the CAR discovery protocol also provides > mapping of L2 ID to IP address of the new AR which is necessary for the > low-latency handoff mechanism proposed in the MobileIP WG. So there is a > case CAR discovery is helpful for single technology handovers. > > I understand the IETF is pro-end-point-control. Anyway, regarding your > question, couldn't we imagine a case when a network provider wants do a kind > of load-balancing between different access networks in the wireless overlay > network? > > > > - CAR discovery does not force any handoffs and it does not advocate > > any > > > network-based handoff decision making. > > > > > > > OK, but like I said, I don't see the relevence to network handover to > > CAR discovery. > > > > > Example 1: > > > ---------- > > > > > > Here, an MN connected to AR_current hears a beacon from a nearby > > access > > > point (AP_new). Note that this beacon may not contain the IP address > > of > > > AR_new that governs this AP_new. MN passes on this beacon information > > to > > > AR_current, and AR_current has to map it to the IP address of AR_new. > > > > If MN can hear the beacon, why doesn't it simply solicit a router > > advert? There's no need for the current AR to get involved. > > > > I think the beacon in this example is L2 beacon. Isn't there a case the MN > needs to go several steps before it can send a router solicitation message? > I think it depends on the involved L2 technology. Anyway the MN can get the > information it needs without soliciting the new AR by using CAR discovery. > The point of this example seems to me that the MN does not go through such > steps to save power. > > > > AR_current then compares the capabilities of AR_new with the > > > requirements expressed by MN. These requirements are expressed by MN > > > prior to handoff and are made available to AR_current for CAR > > discovery. > > > If good match is found, AR_current deems AR_new as a CAR. A similar > > > process could occur for every AP beacon heard by MN and other CARs > > could > > > be discovered as well. CAR discovery ends here. > > > > > > > This is too complicated. After solcitiing the new RA, the MN can decide > > whether to connect or not. > > What's the point of all this communication with the old AR when the MN > > can already hear the > > new one? > > > > > CAR discovery output, i.e., this set of CARs, is one parameter used by > > > the target AR (TAR) selection algorithm. The output of TAR selection > > > decides where the MN actually hands off to. It could even be to an AR > > > different than CARs discovered as above. This TAR selection algorithm > > > may reside in the MN and/or the AR. Depending upon implementation of > > TAR > > > selection process, the CAR IDs (possibly along with their > > capabilities) > > > may have to be sent to the MN for selection. > > > > > > Example 2: > > > ---------- > > > > > > In this example, an MN can actually connect to the AP_new and then by > > > using, say, router solicitation, get the IP address of AR_new. It can > > > then solicit the capabilities of AR_new over the new IP layer > > connection > > > it has established and compare them with its requirements to identify > > > whether AR_new is a CAR. This process can be repeated for every beacon > > > heard by MN. Again CAR discovery ends here. > > > > > > > Why is this any different than Example 1? If the MN can get a beacon, > > why can't it solicit an RA? And if it can't solicit an RA, then what is > > the point of the MN even bringing up the interface to get a beacon? It > > should just leave the interface down and use CAR discovery with the > > current AR to find out if there are any routers on the other medium > > around. > > > > > The output of CAR discovery is fed as one input to the TAR selection > > > algorithm, wherever it resides, and the TAR selection algorithm then > > > decides the AR that the MN will be handing off to. > > > > > > There are performance differences between examples 1 and 2 with > > respect > > > to wireless bandwidth efficiency, speed of CAR discovery, utility > > > towards fast/smooth handoff protocols, MN power saving etc. > > > > > > > > > Example 3: > > > ---------- > > > > > > Here MN is connected to cellular network over one interface and its > > other > > > interface (WLAN) is sleeping for power saving purposes. > > > > > > > This is the only example I think makes sense. > > > > > MN is attached to AR_current of cellular and "MN has expressed the > > > requirement with AR_current" to let it know whenever hot-spot access > > > opportunity exists. Note that, MN may not be able to detect hot-spot > > access > > > by itself as WLAN interface is sleeping for power saving. Since > > AR_current > > > knows the capabilities of GAARs (thanks to AR <-> GAAR capability > > exchange > > > part of CAR discovery), it knows that WLAN access exists in > > neighborhood and > > > it can intimate so to MN. It is then "upto the MN to decide" if it > > wants to > > > fire up the WLAN interface and start scanning. > > > > > > > The current AR doesn't have to be involved if the MN periodically polls. > > That's an implementation assumption. > > > > > During scanning, MN can do further capability discovery either as in > > example > > > 1 (AR_current assisted) or example 2 (AR_current non-assisted) > > mentioned > > > above. Note that, MN may detect more than one WLAN beacons during > > scanning > > > as well. Also, it is worth noting that it is not the only option that > > CAR > > > discovery information be available through WLAN interface. It could be > > > obtained over cellular interface from AR_current (example 1) or over > > WLAN > > > interface from GAAR (example 2). Performance/implementation tradeoffs > > will > > > determine the best option. In fact, if AR_current's assistance is > > sought for > > > CAR discovery (example 1), there may not be need to unnecessarily fire > > up > > > WLAN interface if the capabilities of WLAN access do not match MN > > > requirements. Even more power saving! > > > > > > Please provide your feedback on these. > > > > > > BR, > > > Hemant > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 03:53:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05637 for ; Mon, 25 Mar 2002 03:53:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22526 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 03:53:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21890; Mon, 25 Mar 2002 03:50:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21855 for ; Mon, 25 Mar 2002 03:50:21 -0500 (EST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05596 for ; Mon, 25 Mar 2002 03:50:16 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g2P8oEK14182; Mon, 25 Mar 2002 14:20:14 +0530 (IST) Received: from SATISHJ (pcz-satishj.sasken.com [10.1.36.146]) by sunrnd2.sasken.com (8.11.6/8.11.6) with SMTP id g2P8oCL12954; Mon, 25 Mar 2002 14:20:12 +0530 (IST) Message-ID: <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> From: "Satish Jamadagni" To: "Eunsoo Shim" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 14:21:03 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dear All, Some comments on CAR discovery - We all agree that the CAR discovery protocol should assist in identifying GAARs, arrive at CARs from GAARs and finally a TAR from the CARs. Throughout this process one can see that there will be varied level of information exchange (context information basically). When identifying the GAARs either the MN or the AR or a edge device needs to know the geographic coverage of that AR (one can argue that more can be added at this stage itself). Now from GAARs to CARs one would expect that the CAR discovery protocol would provide more than just the geographic coverage. An exchange of a very high level view of QoS or context support information between ARs (QoS and context types will have to be agreed upon for this) is what is expected to arrive at a set of CARs - now till this stage the MN need not come into play at all. The use of a MNs personal settings and preferences will come into play at the stage of CARs to TAR. Usually (I dont know if in the future classes of MNs can be identified and TARs selected for them as a class) the TAR selection will be biased by the MN considerations - but then again the MN might have prevelages with the AR so that the AR itself can achieve this for a (or a class of) MNs. Also there should be provision for an AR to do a TAR selection given the fact that the service provider can have policies that can force a mobiles to handover due to load conditions, inorder to provide better QoS when the load on other ARs or the underlying L2 becomes available (One of the most critical understanding of a 4G network is that there are a host of L2s with a common IP layer and above) in the present understanding and spectrum sharing in future SDR scenarios (Please note that inter-technology handover is where much in the understanding of future 4G and SDR networks - we dont want our CAR protocol to undergo a lot of changes when the notion of seamless ness as required by a 4G or an SDR network hits the scene) . The idea of a CAR discovery protocol SHOULD be to make available the right amount of information at the right time for the GAARs to CARs to TAR process. The rest i.e. the exact selection of a subset of GAARs as CARs and the selection of a TAR should be left open for people like us to make a living by fitting algorithms in place. Also there were Qs like CAR being relavent in some scenarios - I think we should not restrict ourselves to just the MN option - you never know when the service providers would start offering that extra bit of processing at the network level as a service differentiator - The MN is of course the king in the TAR selection, but he can have a better understanding with his home network when the AR can do a TAR selection for the MN considering the MNs very private settings too. The AR if bound by a QoS policy might want a user to go to another specific AR with or without an underlying L2 change at his bidding. With all the paging and solication protocols evolving there should also be a provision for any AR to "entice" a MN into his domain - so to say there should be provision for an AR to declare to an MN that he is the best AR for the MN (target triggered case) - Of course how does the AR come to know of the MN and his QoS settings - at some high level this is possible - going lower and being sensitive to privacy issues - one will have to work out the issues. Regards, Satish Jamadagni. Research Scientist Sasken Communication Technologies Ltd Bangalore. ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Tuesday, March 26, 2002 5:58 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hi, James, > > My comments are inline. > Thanks. > > Eunsoo > ----- Original Message ----- > From: "James Kempf" > To: "Hemant Chaskar" ; > Sent: Sunday, March 24, 2002 4:40 PM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > After the CAR discovery discussion in IETF53, it seems that we need to > > > emphasize certain points about CAR discovery. They are as follows: > > > > > > - CAR discovery always considers MN requirements while choosing CARs > > from > > > GAARs. > > > > > > > This statement sounds like some other entity beside the MN is doing the > > choosing (TAR selection). I can't see the relevance of CAR discovery > > other than in the following cases: > > > > 1) There are multiple wireless media options (e.g. cellular and WLAN) > > and one medium has wider coverage than the other (e.g. cellular is > > typically a WAN while WLAN is typically only for hotspots). > > 2) The MN has two interfaces. > > 3) The MN wants to keep one interface off while using the other. > > 4) The MN wants to be informed when it enters or leaves the coverage > > area of the less dense coverage option. > > > > Only the MN is in a position to make a choice, that's what Steve's talk > > was all about. So I would rephrase this: > > > > CAR discovery provides the MN with information on CARs for the MN to > > choose which TAR it wants to > > hand over to. > > > > > - CAR discovery _does not_ make any handoff decisions. It merely > > chooses > > > CARs (by matching MN's requirements with GAARs' capabilities) and > > makes this > > > information available to TAR selection algorithms. TAR selection > > algorithms > > > (whether they reside in MN or network or both) make decision about TAR > > for > > > handoff. > > > > > > > Can you give me an example of when the network would want to select? In > > every case where I can think of needing CAR discovery, intertechnology > > handover is required and the MN must be involved in order to bring up > > and connect the new interface. For single technology handover, you don't > > need CAR discovery. In that case, either the network or the MN can do > > it, but the choice of next AR is predetermined by the Layer 2 power > > characteristics. > > > Please just let me remind you that the CAR discovery protocol also provides > mapping of L2 ID to IP address of the new AR which is necessary for the > low-latency handoff mechanism proposed in the MobileIP WG. So there is a > case CAR discovery is helpful for single technology handovers. > > I understand the IETF is pro-end-point-control. Anyway, regarding your > question, couldn't we imagine a case when a network provider wants do a kind > of load-balancing between different access networks in the wireless overlay > network? > > > > - CAR discovery does not force any handoffs and it does not advocate > > any > > > network-based handoff decision making. > > > > > > > OK, but like I said, I don't see the relevence to network handover to > > CAR discovery. > > > > > Example 1: > > > ---------- > > > > > > Here, an MN connected to AR_current hears a beacon from a nearby > > access > > > point (AP_new). Note that this beacon may not contain the IP address > > of > > > AR_new that governs this AP_new. MN passes on this beacon information > > to > > > AR_current, and AR_current has to map it to the IP address of AR_new. > > > > If MN can hear the beacon, why doesn't it simply solicit a router > > advert? There's no need for the current AR to get involved. > > > > I think the beacon in this example is L2 beacon. Isn't there a case the MN > needs to go several steps before it can send a router solicitation message? > I think it depends on the involved L2 technology. Anyway the MN can get the > information it needs without soliciting the new AR by using CAR discovery. > The point of this example seems to me that the MN does not go through such > steps to save power. > > > > AR_current then compares the capabilities of AR_new with the > > > requirements expressed by MN. These requirements are expressed by MN > > > prior to handoff and are made available to AR_current for CAR > > discovery. > > > If good match is found, AR_current deems AR_new as a CAR. A similar > > > process could occur for every AP beacon heard by MN and other CARs > > could > > > be discovered as well. CAR discovery ends here. > > > > > > > This is too complicated. After solcitiing the new RA, the MN can decide > > whether to connect or not. > > What's the point of all this communication with the old AR when the MN > > can already hear the > > new one? > > > > > CAR discovery output, i.e., this set of CARs, is one parameter used by > > > the target AR (TAR) selection algorithm. The output of TAR selection > > > decides where the MN actually hands off to. It could even be to an AR > > > different than CARs discovered as above. This TAR selection algorithm > > > may reside in the MN and/or the AR. Depending upon implementation of > > TAR > > > selection process, the CAR IDs (possibly along with their > > capabilities) > > > may have to be sent to the MN for selection. > > > > > > Example 2: > > > ---------- > > > > > > In this example, an MN can actually connect to the AP_new and then by > > > using, say, router solicitation, get the IP address of AR_new. It can > > > then solicit the capabilities of AR_new over the new IP layer > > connection > > > it has established and compare them with its requirements to identify > > > whether AR_new is a CAR. This process can be repeated for every beacon > > > heard by MN. Again CAR discovery ends here. > > > > > > > Why is this any different than Example 1? If the MN can get a beacon, > > why can't it solicit an RA? And if it can't solicit an RA, then what is > > the point of the MN even bringing up the interface to get a beacon? It > > should just leave the interface down and use CAR discovery with the > > current AR to find out if there are any routers on the other medium > > around. > > > > > The output of CAR discovery is fed as one input to the TAR selection > > > algorithm, wherever it resides, and the TAR selection algorithm then > > > decides the AR that the MN will be handing off to. > > > > > > There are performance differences between examples 1 and 2 with > > respect > > > to wireless bandwidth efficiency, speed of CAR discovery, utility > > > towards fast/smooth handoff protocols, MN power saving etc. > > > > > > > > > Example 3: > > > ---------- > > > > > > Here MN is connected to cellular network over one interface and its > > other > > > interface (WLAN) is sleeping for power saving purposes. > > > > > > > This is the only example I think makes sense. > > > > > MN is attached to AR_current of cellular and "MN has expressed the > > > requirement with AR_current" to let it know whenever hot-spot access > > > opportunity exists. Note that, MN may not be able to detect hot-spot > > access > > > by itself as WLAN interface is sleeping for power saving. Since > > AR_current > > > knows the capabilities of GAARs (thanks to AR <-> GAAR capability > > exchange > > > part of CAR discovery), it knows that WLAN access exists in > > neighborhood and > > > it can intimate so to MN. It is then "upto the MN to decide" if it > > wants to > > > fire up the WLAN interface and start scanning. > > > > > > > The current AR doesn't have to be involved if the MN periodically polls. > > That's an implementation assumption. > > > > > During scanning, MN can do further capability discovery either as in > > example > > > 1 (AR_current assisted) or example 2 (AR_current non-assisted) > > mentioned > > > above. Note that, MN may detect more than one WLAN beacons during > > scanning > > > as well. Also, it is worth noting that it is not the only option that > > CAR > > > discovery information be available through WLAN interface. It could be > > > obtained over cellular interface from AR_current (example 1) or over > > WLAN > > > interface from GAAR (example 2). Performance/implementation tradeoffs > > will > > > determine the best option. In fact, if AR_current's assistance is > > sought for > > > CAR discovery (example 1), there may not be need to unnecessarily fire > > up > > > WLAN interface if the capabilities of WLAN access do not match MN > > > requirements. Even more power saving! > > > > > > Please provide your feedback on these. > > > > > > BR, > > > Hemant > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 06:56:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07066 for ; Mon, 25 Mar 2002 06:56:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01305; Mon, 25 Mar 2002 06:43:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01233 for ; Mon, 25 Mar 2002 06:43:17 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06960 for ; Mon, 25 Mar 2002 06:43:15 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 074C322E15; Mon, 25 Mar 2002 13:40:58 +0200 (EET) Date: Mon, 25 Mar 2002 13:39:40 +0200 (EET) From: Teemu Rinta-aho To: Cc: Subject: RE: [Seamoby] Comments on the requirements draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Fri, 22 Mar 2002 Dirk.Trossen@nokia.com wrote: > Hi Teemu, > > see comments inline. > > > 3.5 FORMAT OF CAPABILITIES > > - The format of describing the capabilities MUST be > extendable and flexible in a way that they support > future needs that cannot be exactly defined > at this stage. > > [DOT] in addition to this, though not a requirement as such just > recalling what I said in MPLS, we should evaluate what descriptions > are on the table (as standards/research/products), and how they could > fit into the problem space. This would prevent the re-invention of > the wheel. I agree. > > 3.X SCALABILITY > > - CAR/GAAR discovery MUST be scalable. In the future, there > might be geographical locations with several (hundreds) > of overlapping access points, especially when PANs emerge. > This kind of situation might lead into problems when the > ARs behind these APs have to constantly update their > knowledge of their GAARs. > > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But even then, > what counts is the number of ARs that have overlapping APs with APs of > other ARs. I don't quite see that this number would reach several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. Maybe "hundreds" is too much for near future, but I wanted to give a what-if scenario where the protocol must also survive if there ever is such...? > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > and capability knowledge through CAR) not considered as a CAR, it should still > be possible to handover to this AR? This is indeed true but not within the scope > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > be identified for that), it should be ok that a CAR solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > did not reveal capabilities). However, if the MN (or the AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > selection, which is not within the scope of CAR discovery. CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > input to TAR selection (wherever latter is implemented). Another input might be > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > as well. I agree with your comment. I should have written my comment: "Interoperability MUST exist with ARs not implementing the CAR discovery protocol". What I don't know is whether interoperability is an implicit general requirement for all protocols or should it be explicitly written in the requirements draft? I guess that even if it's not in the draft nobody will probably make a solution where an MN can only handover to ARs which support the CAR discovery protocol... > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > If you have a TAR selection scheme that resides in the MN, it is fairly > easy to do so. If your signal strength fades for instance too fast, you just > skip CAR discovery and select one of the AR from which you receive a current > beacon. But again, this is TAR selection and not within the scope of the problem. > But if you choose to do CAR (wherever it is implemented), it will always add > to your handover time since you have to run certain mechanisms. How this tradeoff > can be determined is not clear to me and looks like an implementation issue in > the entity that runs the TAR selection (which again use CAR discovery as an input). I agree. > > General thoughts: > > How can an AR recognize its GAARs without the help of the MN > or the link-layer protocols? > > This means that the amount of packets sent over the air necessarily > increases, doesn't it? I mean, if the AR doesn't get the information about > GAARs from the MN, then it must somehow sense the GAARs presence through > the APs. But the latter is of course impossible between APs of different > link layers. > > [DOT] Good question ;-) But is it mentioned somewhere that the > identification of GAARs must not be a combined job between AR and MN? Or it > might even be entirely based in the MN? Certainly, the AR-only solution > sounds kind of impossible for me, too. I just wanted to make sure that I've done correct conclusions ;-) Thanks for the comments! > > Best Regards, > > > Dirk > BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 06:56:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07075 for ; Mon, 25 Mar 2002 06:56:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04347 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 06:56:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01305; Mon, 25 Mar 2002 06:43:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01233 for ; Mon, 25 Mar 2002 06:43:17 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06960 for ; Mon, 25 Mar 2002 06:43:15 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 074C322E15; Mon, 25 Mar 2002 13:40:58 +0200 (EET) Date: Mon, 25 Mar 2002 13:39:40 +0200 (EET) From: Teemu Rinta-aho To: Cc: Subject: RE: [Seamoby] Comments on the requirements draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Fri, 22 Mar 2002 Dirk.Trossen@nokia.com wrote: > Hi Teemu, > > see comments inline. > > > 3.5 FORMAT OF CAPABILITIES > > - The format of describing the capabilities MUST be > extendable and flexible in a way that they support > future needs that cannot be exactly defined > at this stage. > > [DOT] in addition to this, though not a requirement as such just > recalling what I said in MPLS, we should evaluate what descriptions > are on the table (as standards/research/products), and how they could > fit into the problem space. This would prevent the re-invention of > the wheel. I agree. > > 3.X SCALABILITY > > - CAR/GAAR discovery MUST be scalable. In the future, there > might be geographical locations with several (hundreds) > of overlapping access points, especially when PANs emerge. > This kind of situation might lead into problems when the > ARs behind these APs have to constantly update their > knowledge of their GAARs. > > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But even then, > what counts is the number of ARs that have overlapping APs with APs of > other ARs. I don't quite see that this number would reach several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. Maybe "hundreds" is too much for near future, but I wanted to give a what-if scenario where the protocol must also survive if there ever is such...? > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > and capability knowledge through CAR) not considered as a CAR, it should still > be possible to handover to this AR? This is indeed true but not within the scope > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > be identified for that), it should be ok that a CAR solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > did not reveal capabilities). However, if the MN (or the AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > selection, which is not within the scope of CAR discovery. CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > input to TAR selection (wherever latter is implemented). Another input might be > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > as well. I agree with your comment. I should have written my comment: "Interoperability MUST exist with ARs not implementing the CAR discovery protocol". What I don't know is whether interoperability is an implicit general requirement for all protocols or should it be explicitly written in the requirements draft? I guess that even if it's not in the draft nobody will probably make a solution where an MN can only handover to ARs which support the CAR discovery protocol... > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > If you have a TAR selection scheme that resides in the MN, it is fairly > easy to do so. If your signal strength fades for instance too fast, you just > skip CAR discovery and select one of the AR from which you receive a current > beacon. But again, this is TAR selection and not within the scope of the problem. > But if you choose to do CAR (wherever it is implemented), it will always add > to your handover time since you have to run certain mechanisms. How this tradeoff > can be determined is not clear to me and looks like an implementation issue in > the entity that runs the TAR selection (which again use CAR discovery as an input). I agree. > > General thoughts: > > How can an AR recognize its GAARs without the help of the MN > or the link-layer protocols? > > This means that the amount of packets sent over the air necessarily > increases, doesn't it? I mean, if the AR doesn't get the information about > GAARs from the MN, then it must somehow sense the GAARs presence through > the APs. But the latter is of course impossible between APs of different > link layers. > > [DOT] Good question ;-) But is it mentioned somewhere that the > identification of GAARs must not be a combined job between AR and MN? Or it > might even be entirely based in the MN? Certainly, the AR-only solution > sounds kind of impossible for me, too. I just wanted to make sure that I've done correct conclusions ;-) Thanks for the comments! > > Best Regards, > > > Dirk > BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 06:59:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07101 for ; Mon, 25 Mar 2002 06:59:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03413; Mon, 25 Mar 2002 06:52:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03383 for ; Mon, 25 Mar 2002 06:52:13 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07043 for ; Mon, 25 Mar 2002 06:52:12 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id B0C1022E15; Mon, 25 Mar 2002 13:49:59 +0200 (EET) Date: Mon, 25 Mar 2002 13:48:41 +0200 (EET) From: Teemu Rinta-aho To: James Kempf Cc: Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: <00d701c1d2ef$5c335810$a56015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Sat, 23 Mar 2002, James Kempf wrote: > As per SteveD's presentation in the Minne-apple, the MN must be able to > make the decision on its own, particularly for intertechnology. > > The MN must also be able to get the information through any interface, > even one that is currently not up. This allows the MN to keep an > interface powered down until it knows there is an active wireless > network in the area == power savings. > > If the latter were not so, the MN could just use standard Router > Discovery on the interface and there would be no need for CAR discovery. I am not a layer 2 expert, but wouldn't that require that the interface first does a layer 2 handover from the old access point to the new one before anything can be done at the IP layer? And at that point all communications going through the old AP/AR would cease... At least I don't know any WLAN card or other L2 device that could attach to several access points simultaneously. I thought CAR protocol was to be useful also in cases where you have only one interface and you want to keep track of the CARs to make fast handovers? BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 06:59:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07112 for ; Mon, 25 Mar 2002 06:59:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05081 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 06:59:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03413; Mon, 25 Mar 2002 06:52:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03383 for ; Mon, 25 Mar 2002 06:52:13 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07043 for ; Mon, 25 Mar 2002 06:52:12 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id B0C1022E15; Mon, 25 Mar 2002 13:49:59 +0200 (EET) Date: Mon, 25 Mar 2002 13:48:41 +0200 (EET) From: Teemu Rinta-aho To: James Kempf Cc: Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: <00d701c1d2ef$5c335810$a56015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Sat, 23 Mar 2002, James Kempf wrote: > As per SteveD's presentation in the Minne-apple, the MN must be able to > make the decision on its own, particularly for intertechnology. > > The MN must also be able to get the information through any interface, > even one that is currently not up. This allows the MN to keep an > interface powered down until it knows there is an active wireless > network in the area == power savings. > > If the latter were not so, the MN could just use standard Router > Discovery on the interface and there would be no need for CAR discovery. I am not a layer 2 expert, but wouldn't that require that the interface first does a layer 2 handover from the old access point to the new one before anything can be done at the IP layer? And at that point all communications going through the old AP/AR would cease... At least I don't know any WLAN card or other L2 device that could attach to several access points simultaneously. I thought CAR protocol was to be useful also in cases where you have only one interface and you want to keep track of the CARs to make fast handovers? BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 11:12:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17339 for ; Mon, 25 Mar 2002 11:12:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05701; Mon, 25 Mar 2002 11:04:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05655 for ; Mon, 25 Mar 2002 11:04:55 -0500 (EST) Received: from ommo.com ([63.227.234.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16638 for ; Mon, 25 Mar 2002 11:04:40 -0500 (EST) Message-Id: <200203251604.LAA16638@ietf.org> From: "sameez1@dubaimail.com" To: seamoby@ietf.org Date: Mon, 25 Mar 2002 17:33:37 -0800 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6800 DM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA05656 Subject: [Seamoby] ASSISTANCE NEEDED. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit DR. SOLOMON AZEEZ. Director, Project Implementation, Nigerian National Petroleum Corporation, Falomo Office Complex, Ikoyi - Lagos. SIR, BUSINESS PROPOSAL It is my great pleasure in writing you this letter on behalf of myself and my colleagues. Your particulars were given to me by a member of the Nigerian Export Promotion Council (NEPC) who was at the Federal Government Delegation to your country during a trade exhibition. I have decided to seek a confidentialcooperation with you in the execution of the deal described hereunder for the benefit of all parties and hope you will keep it as top secret because of the nature of this business. Within the Ministry of Petroleum Resources where I work as a Director, Project Implementation and with the cooperation of four other top officials we have in our possession as overdue payment bills totalling Fourteen Million, Five Hundred Thousand U. S. Dollars (US$14,500,000.00) which we want to transfer abroad with assistance and cooperation of a foreign company/individual toreceive the said fund on our behalf or a reliable foreign non-company account to receive such funds. Moreso, we are handicapped in the circumstances as the Nigerian Civil Service Code of Conduct does not allow us to operate offshore account hence your importance in the whole transaction. The amount represents the balance of the total contract value executed on behalf of my Ministry by a foreign contracting firm which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractor, leaving the balance in the tune of the said amount which we have in principles gotten approval to remit byTelegraphic Transfer (T.T) to foreign bank account you will provide by filing in an application through the Federal Ministry of Justice for the transfer of rights and privileges of the formercontractor to you. Since the new civilian government of my country is determined to pay every foreign contractor all debts owed so as to maintain good relationship with foreign government and non-government financial agencies, thereforewe have decided to include our bills for approvals with the cooperation of some officials from the FederalMinistry of Finance and the Central Bank ofNigeria (CBN) We are seeking your assistance in providing a vital account or any virgin bank account into which we can remit this money by acting as our main partner and trustee. This we can do by swapping of account and changing of beneficiary and other forms of documentation upon application for claim to reflect the payment and approvals to be secured on behalf of you. This processes being pre-arranged with the principal trustee of the original contractor and with the consent of the original contractor. I have the authority of my partners involved to propose that should you be willing to assist us in the transaction your share of the sum will be 30% of the US$14.5 million, 60% for us and 10% for taxation and miscellaneous expenses. The business itself is 100% safe, on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Endeavor to e-mail ON;sameez1@dubaimail.com me toknow your position and include your confidential telephoneand fax numbers. Thanks for your cooperation. Yours faithfully, DR. SOLOMON AZEEZ. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 11:12:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17353 for ; Mon, 25 Mar 2002 11:12:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07684 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 11:12:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05701; Mon, 25 Mar 2002 11:04:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05655 for ; Mon, 25 Mar 2002 11:04:55 -0500 (EST) Received: from ommo.com ([63.227.234.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16638 for ; Mon, 25 Mar 2002 11:04:40 -0500 (EST) Message-Id: <200203251604.LAA16638@ietf.org> From: "sameez1@dubaimail.com" To: seamoby@ietf.org Date: Mon, 25 Mar 2002 17:33:37 -0800 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6800 DM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA05656 Subject: [Seamoby] ASSISTANCE NEEDED. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit DR. SOLOMON AZEEZ. Director, Project Implementation, Nigerian National Petroleum Corporation, Falomo Office Complex, Ikoyi - Lagos. SIR, BUSINESS PROPOSAL It is my great pleasure in writing you this letter on behalf of myself and my colleagues. Your particulars were given to me by a member of the Nigerian Export Promotion Council (NEPC) who was at the Federal Government Delegation to your country during a trade exhibition. I have decided to seek a confidentialcooperation with you in the execution of the deal described hereunder for the benefit of all parties and hope you will keep it as top secret because of the nature of this business. Within the Ministry of Petroleum Resources where I work as a Director, Project Implementation and with the cooperation of four other top officials we have in our possession as overdue payment bills totalling Fourteen Million, Five Hundred Thousand U. S. Dollars (US$14,500,000.00) which we want to transfer abroad with assistance and cooperation of a foreign company/individual toreceive the said fund on our behalf or a reliable foreign non-company account to receive such funds. Moreso, we are handicapped in the circumstances as the Nigerian Civil Service Code of Conduct does not allow us to operate offshore account hence your importance in the whole transaction. The amount represents the balance of the total contract value executed on behalf of my Ministry by a foreign contracting firm which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractor, leaving the balance in the tune of the said amount which we have in principles gotten approval to remit byTelegraphic Transfer (T.T) to foreign bank account you will provide by filing in an application through the Federal Ministry of Justice for the transfer of rights and privileges of the formercontractor to you. Since the new civilian government of my country is determined to pay every foreign contractor all debts owed so as to maintain good relationship with foreign government and non-government financial agencies, thereforewe have decided to include our bills for approvals with the cooperation of some officials from the FederalMinistry of Finance and the Central Bank ofNigeria (CBN) We are seeking your assistance in providing a vital account or any virgin bank account into which we can remit this money by acting as our main partner and trustee. This we can do by swapping of account and changing of beneficiary and other forms of documentation upon application for claim to reflect the payment and approvals to be secured on behalf of you. This processes being pre-arranged with the principal trustee of the original contractor and with the consent of the original contractor. I have the authority of my partners involved to propose that should you be willing to assist us in the transaction your share of the sum will be 30% of the US$14.5 million, 60% for us and 10% for taxation and miscellaneous expenses. The business itself is 100% safe, on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Endeavor to e-mail ON;sameez1@dubaimail.com me toknow your position and include your confidential telephoneand fax numbers. Thanks for your cooperation. Yours faithfully, DR. SOLOMON AZEEZ. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 11:35:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18788 for ; Mon, 25 Mar 2002 11:35:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12940; Mon, 25 Mar 2002 11:33:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12898 for ; Mon, 25 Mar 2002 11:33:01 -0500 (EST) Received: from hotmail.com (f47.law9.hotmail.com [64.4.9.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18464 for ; Mon, 25 Mar 2002 11:32:53 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 08:32:26 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 16:32:25 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 11:32:25 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 16:32:26.0143 (UTC) FILETIME=[A5F21AF0:01C1D41A] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, [snip] > >This statement sounds like some other entity beside the MN is doing the >choosing (TAR selection). I can't see the relevance of CAR discovery >other than in the following cases: > >1) There are multiple wireless media options (e.g. cellular and WLAN) >and one medium has wider coverage than the other (e.g. cellular is >typically a WAN while WLAN is typically only for hotspots). >2) The MN has two interfaces. >3) The MN wants to keep one interface off while using the other. >4) The MN wants to be informed when it enters or leaves the coverage >area of the less dense coverage option. [Govind] What about WLAN -> WLAN? the MN has one WLAN interface and it is connected to an AP. Suppose it needs to be handed over to another AP. It can only perceive the other L2 beacon, but cannot establish connectivity with the other one without leaving the current interface(ok theoretically this can be done without letting go of the previous L2 but I don't think the specs allow this but I'm not sure. Anyways it is quite expensive in terms of bandwidth, power and time). I think CAR discovery is very relevant in this scenario too. I don't think that only inter-technology handovers alone are in CAR discovery's scope. Clearly FMIPv6 and context transfer protocols are dependent on this. Or am I missing something? I thought this was one of the main intentions to start CAR discovery. I therefore think it is totally incorrect to presume that CAR discovery is only for inter-technology handovers. > >Only the MN is in a position to make a choice, that's what Steve's talk >was all about. So I would rephrase this: > > CAR discovery provides the MN with information on CARs for the MN to >choose which TAR it wants to > hand over to. [Govind] I am not sure why network controlled handovers must be completely be rejected without proper review. I think the point to note is that network controlled handovers does not imply that the MN requirements are neglected. However, I agree that CAR discovery is not involved here. [snip] >Can you give me an example of when the network would want to select? In >every case where I can think of needing CAR discovery, intertechnology >handover is required and the MN must be involved in order to bring up >and connect the new interface. For single technology handover, you don't >need CAR discovery. In that case, either the network or the MN can do >it, but the choice of next AR is predetermined by the Layer 2 power >characteristics. [Govind] The network is made aware of the MN's requirements as part of its Home AAA infrastructure (some kind of static profile for the MN) and this is transferred to the AR. In this case the MN's requirements are completely known to the MN. So the AR sends the ID of the AR as best as it can judge to the MN and then the MN makes the final decision anyways. Essentially give the MN a "veto" power for the networks decision. Why wouldn't this work? Again, I don't agree with your notion that CAR discovery is suitable only for inter-technology handovers , as I have described earlier (WLAN -> WLAN case) in this mail. Also, clearly when we consider heterogeneous (in capability and not in technology) ARs, the SIR information alone may not be enough. > > > - CAR discovery does not force any handoffs and it does not advocate >any > > network-based handoff decision making. > > > >OK, but like I said, I don't see the relevence to network handover to >CAR discovery. [Govind] Well CAR discovery helps in the handover decision, it does not matter whether the handover is network controlled or mobile controlled. [snip] > >If MN can hear the beacon, why doesn't it simply solicit a router >advert? There's no need for the current AR to get involved. [Govind] Listening to the beacon, and connected to the L2 device is two different things. You can't solicit unless you are connected. Of course, if you have 20 such APs you have to connect to every one first (and be authenticated and made sure it is authorized to roam in the AR's net) before soliciting an RAdv. [snip] >This is too complicated. After solcitiing the new RA, the MN can decide >whether to connect or not. >What's the point of all this communication with the old AR when the MN >can already hear the >new one? [Govind] Of course it can blindly connect to the first AP it hears. But are we proposing that? We are giving the MN an option to make the best choice it can under the circumstances. Yes what you propose is true but there are bandwidth, time and power issues to take into consideration. [snip] > > > >Why is this any different than Example 1? If the MN can get a beacon, >why can't it solicit an RA? And if it can't solicit an RA, then what is >the point of the MN even bringing up the interface to get a beacon? It >should just leave the interface down and use CAR discovery with the >current AR to find out if there are any routers on the other medium >around. [Govind] Example 2 can refer to the case when there are two interfaces in the MN and in Example 1 there is just one. Example 1 could mean that the MN has to disconnect from the previous L2 device before attaching to the new one. Another difference is that Example 2 implies higher bandwidth, time and power requirements. Example 1 can use FMIPv6. [snip] > > Example 3: > > ---------- > > > > Here MN is connected to cellular network over one interface and its >other > > interface (WLAN) is sleeping for power saving purposes. > > > >This is the only example I think makes sense. [Govind] I disagree, as explained before. [snip] > >The current AR doesn't have to be involved if the MN periodically polls. >That's an implementation assumption. [Govind] Yes I agree, it is an optimization when using the network to help the MN to turn on the interface only when there is a possibility of finding a particular technology, as well as it can fine tuned to wake up only when the particular AR can support its requirements and it is authorized to roam. In other words periodic waking up is more power consuming than selective waking up. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 11:35:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18802 for ; Mon, 25 Mar 2002 11:35:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13473 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 11:35:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12940; Mon, 25 Mar 2002 11:33:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12898 for ; Mon, 25 Mar 2002 11:33:01 -0500 (EST) Received: from hotmail.com (f47.law9.hotmail.com [64.4.9.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18464 for ; Mon, 25 Mar 2002 11:32:53 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 08:32:26 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 16:32:25 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 11:32:25 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 16:32:26.0143 (UTC) FILETIME=[A5F21AF0:01C1D41A] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, [snip] > >This statement sounds like some other entity beside the MN is doing the >choosing (TAR selection). I can't see the relevance of CAR discovery >other than in the following cases: > >1) There are multiple wireless media options (e.g. cellular and WLAN) >and one medium has wider coverage than the other (e.g. cellular is >typically a WAN while WLAN is typically only for hotspots). >2) The MN has two interfaces. >3) The MN wants to keep one interface off while using the other. >4) The MN wants to be informed when it enters or leaves the coverage >area of the less dense coverage option. [Govind] What about WLAN -> WLAN? the MN has one WLAN interface and it is connected to an AP. Suppose it needs to be handed over to another AP. It can only perceive the other L2 beacon, but cannot establish connectivity with the other one without leaving the current interface(ok theoretically this can be done without letting go of the previous L2 but I don't think the specs allow this but I'm not sure. Anyways it is quite expensive in terms of bandwidth, power and time). I think CAR discovery is very relevant in this scenario too. I don't think that only inter-technology handovers alone are in CAR discovery's scope. Clearly FMIPv6 and context transfer protocols are dependent on this. Or am I missing something? I thought this was one of the main intentions to start CAR discovery. I therefore think it is totally incorrect to presume that CAR discovery is only for inter-technology handovers. > >Only the MN is in a position to make a choice, that's what Steve's talk >was all about. So I would rephrase this: > > CAR discovery provides the MN with information on CARs for the MN to >choose which TAR it wants to > hand over to. [Govind] I am not sure why network controlled handovers must be completely be rejected without proper review. I think the point to note is that network controlled handovers does not imply that the MN requirements are neglected. However, I agree that CAR discovery is not involved here. [snip] >Can you give me an example of when the network would want to select? In >every case where I can think of needing CAR discovery, intertechnology >handover is required and the MN must be involved in order to bring up >and connect the new interface. For single technology handover, you don't >need CAR discovery. In that case, either the network or the MN can do >it, but the choice of next AR is predetermined by the Layer 2 power >characteristics. [Govind] The network is made aware of the MN's requirements as part of its Home AAA infrastructure (some kind of static profile for the MN) and this is transferred to the AR. In this case the MN's requirements are completely known to the MN. So the AR sends the ID of the AR as best as it can judge to the MN and then the MN makes the final decision anyways. Essentially give the MN a "veto" power for the networks decision. Why wouldn't this work? Again, I don't agree with your notion that CAR discovery is suitable only for inter-technology handovers , as I have described earlier (WLAN -> WLAN case) in this mail. Also, clearly when we consider heterogeneous (in capability and not in technology) ARs, the SIR information alone may not be enough. > > > - CAR discovery does not force any handoffs and it does not advocate >any > > network-based handoff decision making. > > > >OK, but like I said, I don't see the relevence to network handover to >CAR discovery. [Govind] Well CAR discovery helps in the handover decision, it does not matter whether the handover is network controlled or mobile controlled. [snip] > >If MN can hear the beacon, why doesn't it simply solicit a router >advert? There's no need for the current AR to get involved. [Govind] Listening to the beacon, and connected to the L2 device is two different things. You can't solicit unless you are connected. Of course, if you have 20 such APs you have to connect to every one first (and be authenticated and made sure it is authorized to roam in the AR's net) before soliciting an RAdv. [snip] >This is too complicated. After solcitiing the new RA, the MN can decide >whether to connect or not. >What's the point of all this communication with the old AR when the MN >can already hear the >new one? [Govind] Of course it can blindly connect to the first AP it hears. But are we proposing that? We are giving the MN an option to make the best choice it can under the circumstances. Yes what you propose is true but there are bandwidth, time and power issues to take into consideration. [snip] > > > >Why is this any different than Example 1? If the MN can get a beacon, >why can't it solicit an RA? And if it can't solicit an RA, then what is >the point of the MN even bringing up the interface to get a beacon? It >should just leave the interface down and use CAR discovery with the >current AR to find out if there are any routers on the other medium >around. [Govind] Example 2 can refer to the case when there are two interfaces in the MN and in Example 1 there is just one. Example 1 could mean that the MN has to disconnect from the previous L2 device before attaching to the new one. Another difference is that Example 2 implies higher bandwidth, time and power requirements. Example 1 can use FMIPv6. [snip] > > Example 3: > > ---------- > > > > Here MN is connected to cellular network over one interface and its >other > > interface (WLAN) is sleeping for power saving purposes. > > > >This is the only example I think makes sense. [Govind] I disagree, as explained before. [snip] > >The current AR doesn't have to be involved if the MN periodically polls. >That's an implementation assumption. [Govind] Yes I agree, it is an optimization when using the network to help the MN to turn on the interface only when there is a possibility of finding a particular technology, as well as it can fine tuned to wake up only when the particular AR can support its requirements and it is authorized to roam. In other words periodic waking up is more power consuming than selective waking up. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 11:38:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18935 for ; Mon, 25 Mar 2002 11:38:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12156; Mon, 25 Mar 2002 11:30:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12113 for ; Mon, 25 Mar 2002 11:30:21 -0500 (EST) Received: from ommo.com ([63.227.234.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18176 for ; Mon, 25 Mar 2002 11:30:06 -0500 (EST) Message-Id: <200203251630.LAA18176@ietf.org> From: "sameez1@dubaimail.com" To: seamoby@ietf.org Date: Mon, 25 Mar 2002 17:58:59 -0800 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6800 DM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA12117 Subject: [Seamoby] ASSISTANCE NEEDED. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit DR. SOLOMON AZEEZ. Director, Project Implementation, Nigerian National Petroleum Corporation, Falomo Office Complex, Ikoyi - Lagos. SIR, BUSINESS PROPOSAL It is my great pleasure in writing you this letter on behalf of myself and my colleagues. Your particulars were given to me by a member of the Nigerian Export Promotion Council (NEPC) who was at the Federal Government Delegation to your country during a trade exhibition. I have decided to seek a confidentialcooperation with you in the execution of the deal described hereunder for the benefit of all parties and hope you will keep it as top secret because of the nature of this business. Within the Ministry of Petroleum Resources where I work as a Director, Project Implementation and with the cooperation of four other top officials we have in our possession as overdue payment bills totalling Fourteen Million, Five Hundred Thousand U. S. Dollars (US$14,500,000.00) which we want to transfer abroad with assistance and cooperation of a foreign company/individual toreceive the said fund on our behalf or a reliable foreign non-company account to receive such funds. Moreso, we are handicapped in the circumstances as the Nigerian Civil Service Code of Conduct does not allow us to operate offshore account hence your importance in the whole transaction. The amount represents the balance of the total contract value executed on behalf of my Ministry by a foreign contracting firm which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractor, leaving the balance in the tune of the said amount which we have in principles gotten approval to remit byTelegraphic Transfer (T.T) to foreign bank account you will provide by filing in an application through the Federal Ministry of Justice for the transfer of rights and privileges of the formercontractor to you. Since the new civilian government of my country is determined to pay every foreign contractor all debts owed so as to maintain good relationship with foreign government and non-government financial agencies, thereforewe have decided to include our bills for approvals with the cooperation of some officials from the FederalMinistry of Finance and the Central Bank ofNigeria (CBN) We are seeking your assistance in providing a vital account or any virgin bank account into which we can remit this money by acting as our main partner and trustee. This we can do by swapping of account and changing of beneficiary and other forms of documentation upon application for claim to reflect the payment and approvals to be secured on behalf of you. This processes being pre-arranged with the principal trustee of the original contractor and with the consent of the original contractor. I have the authority of my partners involved to propose that should you be willing to assist us in the transaction your share of the sum will be 30% of the US$14.5 million, 60% for us and 10% for taxation and miscellaneous expenses. The business itself is 100% safe, on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Endeavor to e-mail ON;sameez1@dubaimail.com me toknow your position and include your confidential telephoneand fax numbers. Thanks for your cooperation. Yours faithfully, DR. SOLOMON AZEEZ. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 11:38:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18946 for ; Mon, 25 Mar 2002 11:38:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14198 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 11:38:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12156; Mon, 25 Mar 2002 11:30:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12113 for ; Mon, 25 Mar 2002 11:30:21 -0500 (EST) Received: from ommo.com ([63.227.234.237]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18176 for ; Mon, 25 Mar 2002 11:30:06 -0500 (EST) Message-Id: <200203251630.LAA18176@ietf.org> From: "sameez1@dubaimail.com" To: seamoby@ietf.org Date: Mon, 25 Mar 2002 17:58:59 -0800 X-Priority: 1 X-Mailer: Microsoft Outlook Express 5.00.2919.6800 DM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA12117 Subject: [Seamoby] ASSISTANCE NEEDED. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit DR. SOLOMON AZEEZ. Director, Project Implementation, Nigerian National Petroleum Corporation, Falomo Office Complex, Ikoyi - Lagos. SIR, BUSINESS PROPOSAL It is my great pleasure in writing you this letter on behalf of myself and my colleagues. Your particulars were given to me by a member of the Nigerian Export Promotion Council (NEPC) who was at the Federal Government Delegation to your country during a trade exhibition. I have decided to seek a confidentialcooperation with you in the execution of the deal described hereunder for the benefit of all parties and hope you will keep it as top secret because of the nature of this business. Within the Ministry of Petroleum Resources where I work as a Director, Project Implementation and with the cooperation of four other top officials we have in our possession as overdue payment bills totalling Fourteen Million, Five Hundred Thousand U. S. Dollars (US$14,500,000.00) which we want to transfer abroad with assistance and cooperation of a foreign company/individual toreceive the said fund on our behalf or a reliable foreign non-company account to receive such funds. Moreso, we are handicapped in the circumstances as the Nigerian Civil Service Code of Conduct does not allow us to operate offshore account hence your importance in the whole transaction. The amount represents the balance of the total contract value executed on behalf of my Ministry by a foreign contracting firm which we the officials over-invoiced deliberately. Though the actual contract cost have been paid to the original contractor, leaving the balance in the tune of the said amount which we have in principles gotten approval to remit byTelegraphic Transfer (T.T) to foreign bank account you will provide by filing in an application through the Federal Ministry of Justice for the transfer of rights and privileges of the formercontractor to you. Since the new civilian government of my country is determined to pay every foreign contractor all debts owed so as to maintain good relationship with foreign government and non-government financial agencies, thereforewe have decided to include our bills for approvals with the cooperation of some officials from the FederalMinistry of Finance and the Central Bank ofNigeria (CBN) We are seeking your assistance in providing a vital account or any virgin bank account into which we can remit this money by acting as our main partner and trustee. This we can do by swapping of account and changing of beneficiary and other forms of documentation upon application for claim to reflect the payment and approvals to be secured on behalf of you. This processes being pre-arranged with the principal trustee of the original contractor and with the consent of the original contractor. I have the authority of my partners involved to propose that should you be willing to assist us in the transaction your share of the sum will be 30% of the US$14.5 million, 60% for us and 10% for taxation and miscellaneous expenses. The business itself is 100% safe, on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not a hindrance to the successful execution of this transaction. I have reposed my confidence in you and hope that you will not disappoint me. Endeavor to e-mail ON;sameez1@dubaimail.com me toknow your position and include your confidential telephoneand fax numbers. Thanks for your cooperation. Yours faithfully, DR. SOLOMON AZEEZ. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 11:51:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19485 for ; Mon, 25 Mar 2002 11:51:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16097; Mon, 25 Mar 2002 11:45:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16060 for ; Mon, 25 Mar 2002 11:45:21 -0500 (EST) Received: from hotmail.com (f132.law9.hotmail.com [64.4.9.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19207 for ; Mon, 25 Mar 2002 11:45:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 08:44:50 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 16:44:49 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 11:44:49 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 16:44:50.0080 (UTC) FILETIME=[615DE200:01C1D41C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Teemu, My comments inline. Thanks for your comments. Regards, Govind. > > > >I agree with your comment. I should have written my comment: > >"Interoperability MUST exist with ARs not implementing the >CAR discovery protocol". > >What I don't know is whether interoperability is an implicit >general requirement for all protocols or should it >be explicitly written in the requirements draft? I guess >that even if it's not in the draft nobody will probably >make a solution where an MN can only handover to ARs >which support the CAR discovery protocol... [Govind] I agree with your point. But I don't understand what interaction are you thinking about in your statement. As an example if an AR gets a message from another AR that it is the former's GAAR. What should the former AR do if it does not understand CAR discovery. The point that you raise though important deals with handover decisions and is out of scope of CAR discovery right? _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 11:51:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19495 for ; Mon, 25 Mar 2002 11:51:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17589 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 11:51:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16097; Mon, 25 Mar 2002 11:45:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16060 for ; Mon, 25 Mar 2002 11:45:21 -0500 (EST) Received: from hotmail.com (f132.law9.hotmail.com [64.4.9.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19207 for ; Mon, 25 Mar 2002 11:45:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 08:44:50 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 16:44:49 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 11:44:49 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 16:44:50.0080 (UTC) FILETIME=[615DE200:01C1D41C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Teemu, My comments inline. Thanks for your comments. Regards, Govind. > > > >I agree with your comment. I should have written my comment: > >"Interoperability MUST exist with ARs not implementing the >CAR discovery protocol". > >What I don't know is whether interoperability is an implicit >general requirement for all protocols or should it >be explicitly written in the requirements draft? I guess >that even if it's not in the draft nobody will probably >make a solution where an MN can only handover to ARs >which support the CAR discovery protocol... [Govind] I agree with your point. But I don't understand what interaction are you thinking about in your statement. As an example if an AR gets a message from another AR that it is the former's GAAR. What should the former AR do if it does not understand CAR discovery. The point that you raise though important deals with handover decisions and is out of scope of CAR discovery right? _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 11:52:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19533 for ; Mon, 25 Mar 2002 11:52:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16247; Mon, 25 Mar 2002 11:45:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16210 for ; Mon, 25 Mar 2002 11:45:40 -0500 (EST) Received: from hotmail.com (f88.law7.hotmail.com [216.33.237.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19234 for ; Mon, 25 Mar 2002 11:45:36 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 08:45:06 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 16:45:05 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 16:45:05 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 16:45:06.0023 (UTC) FILETIME=[6ADE9770:01C1D41C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some comments in line: >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Sun, 24 Mar 2002 16:40:51 -0800 > > > After the CAR discovery discussion in IETF53, it seems that we need to > > emphasize certain points about CAR discovery. They are as follows: > > > > - CAR discovery always considers MN requirements while choosing CARs >from > > GAARs. > > > >This statement sounds like some other entity beside the MN is doing the >choosing (TAR selection). [HC] The statement is about "CAR discovery" (as seen from the first two words of the sentence), which is different from TAR selection, as stated in problem statement. Then, why would a statement made for CAR discovery imply anything for TAR selection? I can't see the relevance of CAR discovery >other than in the following cases: > >1) There are multiple wireless media options (e.g. cellular and WLAN) >and one medium has wider coverage than the other (e.g. cellular is >typically a WAN while WLAN is typically only for hotspots). >2) The MN has two interfaces. >3) The MN wants to keep one interface off while using the other. >4) The MN wants to be informed when it enters or leaves the coverage >area of the less dense coverage option. > >Only the MN is in a position to make a choice, that's what Steve's talk >was all about. [HC] Nobody is denying that MN should be given choice. But that does not mean that processor instructions for comparing MN requirements with AR capabilities need to be executed in MN. They could as well be executed in AR. Not executing processor instructions in MN does not mean that MN does not have choice. What matters is input to execution of instructions. So I would rephrase this: > > CAR discovery provides the MN with information on CARs for the MN to >choose which TAR it wants to > hand over to. [HC] That is good. But it is not a "rephrase", it is a "different" statement. What I was talking about is "providing MN requirements to CAR discovery module", what you are saying in above statement is "providing CAR output to MN". Both are different, but I think both need to be there. > > > - CAR discovery _does not_ make any handoff decisions. It merely >chooses > > CARs (by matching MN's requirements with GAARs' capabilities) and >makes this > > information available to TAR selection algorithms. TAR selection >algorithms > > (whether they reside in MN or network or both) make decision about TAR >for > > handoff. > > > >Can you give me an example of when the network would want to select? In >every case where I can think of needing CAR discovery, intertechnology >handover is required and the MN must be involved in order to bring up >and connect the new interface. For single technology handover, you don't >need CAR discovery. In that case, either the network or the MN can do >it, but the choice of next AR is predetermined by the Layer 2 power >characteristics. > > > - CAR discovery does not force any handoffs and it does not advocate >any > > network-based handoff decision making. > > > >OK, but like I said, I don't see the relevence to network handover to >CAR discovery. > > > Example 1: > > ---------- > > > > Here, an MN connected to AR_current hears a beacon from a nearby >access > > point (AP_new). Note that this beacon may not contain the IP address >of > > AR_new that governs this AP_new. MN passes on this beacon information >to > > AR_current, and AR_current has to map it to the IP address of AR_new. > >If MN can hear the beacon, why doesn't it simply solicit a router >advert? There's no need for the current AR to get involved. > > > AR_current then compares the capabilities of AR_new with the > > requirements expressed by MN. These requirements are expressed by MN > > prior to handoff and are made available to AR_current for CAR >discovery. > > If good match is found, AR_current deems AR_new as a CAR. A similar > > process could occur for every AP beacon heard by MN and other CARs >could > > be discovered as well. CAR discovery ends here. > > > >This is too complicated. After solcitiing the new RA, the MN can decide >whether to connect or not. [HC] I disagree that this is complicated. It is fairly simple: Listen to beacon - grab AP id - send to AR_current - wait for CAR ID. This is very time and power efficient, and also, can feed into fast/seamless handoff protocols. >What's the point of all this communication with the old AR when the MN >can already hear the >new one? [HC] It hears the new AP (e.g. an RF broadcast channel), not the new AR yet. Various things need to happen including many message exchanges over wireless before MN can be deemed to be listening to new AR. > > > CAR discovery output, i.e., this set of CARs, is one parameter used by > > the target AR (TAR) selection algorithm. The output of TAR selection > > decides where the MN actually hands off to. It could even be to an AR > > different than CARs discovered as above. This TAR selection algorithm > > may reside in the MN and/or the AR. Depending upon implementation of >TAR > > selection process, the CAR IDs (possibly along with their >capabilities) > > may have to be sent to the MN for selection. > > > > Example 2: > > ---------- > > > > In this example, an MN can actually connect to the AP_new and then by > > using, say, router solicitation, get the IP address of AR_new. It can > > then solicit the capabilities of AR_new over the new IP layer >connection > > it has established and compare them with its requirements to identify > > whether AR_new is a CAR. This process can be repeated for every beacon > > heard by MN. Again CAR discovery ends here. > > > >Why is this any different than Example 1? If the MN can get a beacon, >why can't it solicit an RA? [HC] As I said earlier, AP beacon and AR beacon are different things. In example 1, MN hears AP beacon, in example 2, it hears AR beacon. >And if it can't solicit an RA, then what is >the point of the MN even bringing up the interface to get a beacon? It >should just leave the interface down and use CAR discovery with the >current AR to find out if there are any routers on the other medium >around. > > > The output of CAR discovery is fed as one input to the TAR selection > > algorithm, wherever it resides, and the TAR selection algorithm then > > decides the AR that the MN will be handing off to. > > > > There are performance differences between examples 1 and 2 with >respect > > to wireless bandwidth efficiency, speed of CAR discovery, utility > > towards fast/smooth handoff protocols, MN power saving etc. > > > > > > Example 3: > > ---------- > > > > Here MN is connected to cellular network over one interface and its >other > > interface (WLAN) is sleeping for power saving purposes. > > > >This is the only example I think makes sense. > > > MN is attached to AR_current of cellular and "MN has expressed the > > requirement with AR_current" to let it know whenever hot-spot access > > opportunity exists. Note that, MN may not be able to detect hot-spot >access > > by itself as WLAN interface is sleeping for power saving. Since >AR_current > > knows the capabilities of GAARs (thanks to AR <-> GAAR capability >exchange > > part of CAR discovery), it knows that WLAN access exists in >neighborhood and > > it can intimate so to MN. It is then "upto the MN to decide" if it >wants to > > fire up the WLAN interface and start scanning. > > > >The current AR doesn't have to be involved if the MN periodically polls. [HC] Periodic polling is power inefficient compared to selecting awakeing. Also, waking up for WLAN beacons that are not willing to provide you service is not efficient. >That's an implementation assumption. > > > During scanning, MN can do further capability discovery either as in >example > > 1 (AR_current assisted) or example 2 (AR_current non-assisted) >mentioned > > above. Note that, MN may detect more than one WLAN beacons during >scanning > > as well. Also, it is worth noting that it is not the only option that >CAR > > discovery information be available through WLAN interface. It could be > > obtained over cellular interface from AR_current (example 1) or over >WLAN > > interface from GAAR (example 2). Performance/implementation tradeoffs >will > > determine the best option. In fact, if AR_current's assistance is >sought for > > CAR discovery (example 1), there may not be need to unnecessarily fire >up > > WLAN interface if the capabilities of WLAN access do not match MN > > requirements. Even more power saving! > > > > Please provide your feedback on these. > > > > BR, > > Hemant > > > > BR, Hemant > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 11:52:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19543 for ; Mon, 25 Mar 2002 11:52:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17764 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 11:52:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16247; Mon, 25 Mar 2002 11:45:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16210 for ; Mon, 25 Mar 2002 11:45:40 -0500 (EST) Received: from hotmail.com (f88.law7.hotmail.com [216.33.237.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19234 for ; Mon, 25 Mar 2002 11:45:36 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 08:45:06 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 16:45:05 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 16:45:05 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 16:45:06.0023 (UTC) FILETIME=[6ADE9770:01C1D41C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some comments in line: >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Sun, 24 Mar 2002 16:40:51 -0800 > > > After the CAR discovery discussion in IETF53, it seems that we need to > > emphasize certain points about CAR discovery. They are as follows: > > > > - CAR discovery always considers MN requirements while choosing CARs >from > > GAARs. > > > >This statement sounds like some other entity beside the MN is doing the >choosing (TAR selection). [HC] The statement is about "CAR discovery" (as seen from the first two words of the sentence), which is different from TAR selection, as stated in problem statement. Then, why would a statement made for CAR discovery imply anything for TAR selection? I can't see the relevance of CAR discovery >other than in the following cases: > >1) There are multiple wireless media options (e.g. cellular and WLAN) >and one medium has wider coverage than the other (e.g. cellular is >typically a WAN while WLAN is typically only for hotspots). >2) The MN has two interfaces. >3) The MN wants to keep one interface off while using the other. >4) The MN wants to be informed when it enters or leaves the coverage >area of the less dense coverage option. > >Only the MN is in a position to make a choice, that's what Steve's talk >was all about. [HC] Nobody is denying that MN should be given choice. But that does not mean that processor instructions for comparing MN requirements with AR capabilities need to be executed in MN. They could as well be executed in AR. Not executing processor instructions in MN does not mean that MN does not have choice. What matters is input to execution of instructions. So I would rephrase this: > > CAR discovery provides the MN with information on CARs for the MN to >choose which TAR it wants to > hand over to. [HC] That is good. But it is not a "rephrase", it is a "different" statement. What I was talking about is "providing MN requirements to CAR discovery module", what you are saying in above statement is "providing CAR output to MN". Both are different, but I think both need to be there. > > > - CAR discovery _does not_ make any handoff decisions. It merely >chooses > > CARs (by matching MN's requirements with GAARs' capabilities) and >makes this > > information available to TAR selection algorithms. TAR selection >algorithms > > (whether they reside in MN or network or both) make decision about TAR >for > > handoff. > > > >Can you give me an example of when the network would want to select? In >every case where I can think of needing CAR discovery, intertechnology >handover is required and the MN must be involved in order to bring up >and connect the new interface. For single technology handover, you don't >need CAR discovery. In that case, either the network or the MN can do >it, but the choice of next AR is predetermined by the Layer 2 power >characteristics. > > > - CAR discovery does not force any handoffs and it does not advocate >any > > network-based handoff decision making. > > > >OK, but like I said, I don't see the relevence to network handover to >CAR discovery. > > > Example 1: > > ---------- > > > > Here, an MN connected to AR_current hears a beacon from a nearby >access > > point (AP_new). Note that this beacon may not contain the IP address >of > > AR_new that governs this AP_new. MN passes on this beacon information >to > > AR_current, and AR_current has to map it to the IP address of AR_new. > >If MN can hear the beacon, why doesn't it simply solicit a router >advert? There's no need for the current AR to get involved. > > > AR_current then compares the capabilities of AR_new with the > > requirements expressed by MN. These requirements are expressed by MN > > prior to handoff and are made available to AR_current for CAR >discovery. > > If good match is found, AR_current deems AR_new as a CAR. A similar > > process could occur for every AP beacon heard by MN and other CARs >could > > be discovered as well. CAR discovery ends here. > > > >This is too complicated. After solcitiing the new RA, the MN can decide >whether to connect or not. [HC] I disagree that this is complicated. It is fairly simple: Listen to beacon - grab AP id - send to AR_current - wait for CAR ID. This is very time and power efficient, and also, can feed into fast/seamless handoff protocols. >What's the point of all this communication with the old AR when the MN >can already hear the >new one? [HC] It hears the new AP (e.g. an RF broadcast channel), not the new AR yet. Various things need to happen including many message exchanges over wireless before MN can be deemed to be listening to new AR. > > > CAR discovery output, i.e., this set of CARs, is one parameter used by > > the target AR (TAR) selection algorithm. The output of TAR selection > > decides where the MN actually hands off to. It could even be to an AR > > different than CARs discovered as above. This TAR selection algorithm > > may reside in the MN and/or the AR. Depending upon implementation of >TAR > > selection process, the CAR IDs (possibly along with their >capabilities) > > may have to be sent to the MN for selection. > > > > Example 2: > > ---------- > > > > In this example, an MN can actually connect to the AP_new and then by > > using, say, router solicitation, get the IP address of AR_new. It can > > then solicit the capabilities of AR_new over the new IP layer >connection > > it has established and compare them with its requirements to identify > > whether AR_new is a CAR. This process can be repeated for every beacon > > heard by MN. Again CAR discovery ends here. > > > >Why is this any different than Example 1? If the MN can get a beacon, >why can't it solicit an RA? [HC] As I said earlier, AP beacon and AR beacon are different things. In example 1, MN hears AP beacon, in example 2, it hears AR beacon. >And if it can't solicit an RA, then what is >the point of the MN even bringing up the interface to get a beacon? It >should just leave the interface down and use CAR discovery with the >current AR to find out if there are any routers on the other medium >around. > > > The output of CAR discovery is fed as one input to the TAR selection > > algorithm, wherever it resides, and the TAR selection algorithm then > > decides the AR that the MN will be handing off to. > > > > There are performance differences between examples 1 and 2 with >respect > > to wireless bandwidth efficiency, speed of CAR discovery, utility > > towards fast/smooth handoff protocols, MN power saving etc. > > > > > > Example 3: > > ---------- > > > > Here MN is connected to cellular network over one interface and its >other > > interface (WLAN) is sleeping for power saving purposes. > > > >This is the only example I think makes sense. > > > MN is attached to AR_current of cellular and "MN has expressed the > > requirement with AR_current" to let it know whenever hot-spot access > > opportunity exists. Note that, MN may not be able to detect hot-spot >access > > by itself as WLAN interface is sleeping for power saving. Since >AR_current > > knows the capabilities of GAARs (thanks to AR <-> GAAR capability >exchange > > part of CAR discovery), it knows that WLAN access exists in >neighborhood and > > it can intimate so to MN. It is then "upto the MN to decide" if it >wants to > > fire up the WLAN interface and start scanning. > > > >The current AR doesn't have to be involved if the MN periodically polls. [HC] Periodic polling is power inefficient compared to selecting awakeing. Also, waking up for WLAN beacons that are not willing to provide you service is not efficient. >That's an implementation assumption. > > > During scanning, MN can do further capability discovery either as in >example > > 1 (AR_current assisted) or example 2 (AR_current non-assisted) >mentioned > > above. Note that, MN may detect more than one WLAN beacons during >scanning > > as well. Also, it is worth noting that it is not the only option that >CAR > > discovery information be available through WLAN interface. It could be > > obtained over cellular interface from AR_current (example 1) or over >WLAN > > interface from GAAR (example 2). Performance/implementation tradeoffs >will > > determine the best option. In fact, if AR_current's assistance is >sought for > > CAR discovery (example 1), there may not be need to unnecessarily fire >up > > WLAN interface if the capabilities of WLAN access do not match MN > > requirements. Even more power saving! > > > > Please provide your feedback on these. > > > > BR, > > Hemant > > > > BR, Hemant > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 12:09:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20391 for ; Mon, 25 Mar 2002 12:09:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18996; Mon, 25 Mar 2002 11:57:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18954 for ; Mon, 25 Mar 2002 11:57:00 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19752 for ; Mon, 25 Mar 2002 11:56:51 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PGuLI28256; Mon, 25 Mar 2002 08:56:21 -0800 (PST) Message-ID: <007e01c1d41d$c491bcb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Teemu Rinta-aho" Cc: References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 08:54:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I am not a layer 2 expert, but wouldn't that require that the interface > first does a layer 2 handover from the old access point to the new one > before anything can be done at the IP layer? And at that point all > communications going through the old AP/AR would cease... At least I don't > know any WLAN card or other L2 device that could attach to several access > points simultaneously. > > I thought CAR protocol was to be useful also in cases where you have only > one interface and you want to keep track of the CARs to make fast > handovers? > No, the assumption in this case is that the MN has *two* interfaces, for example, a cellular interface and a Bluetooth or WLAN interface. It could solicit the RA on one interface while the other had a full up connection. In the single interface case, you are right. jak PS: there is a company in Japan that has announced a WLAN card allowing the interface to be on two channels at once. But that is not relevent to the current discussion. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 12:09:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20399 for ; Mon, 25 Mar 2002 12:09:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22064 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 12:09:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18996; Mon, 25 Mar 2002 11:57:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18954 for ; Mon, 25 Mar 2002 11:57:00 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19752 for ; Mon, 25 Mar 2002 11:56:51 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PGuLI28256; Mon, 25 Mar 2002 08:56:21 -0800 (PST) Message-ID: <007e01c1d41d$c491bcb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Teemu Rinta-aho" Cc: References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 08:54:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I am not a layer 2 expert, but wouldn't that require that the interface > first does a layer 2 handover from the old access point to the new one > before anything can be done at the IP layer? And at that point all > communications going through the old AP/AR would cease... At least I don't > know any WLAN card or other L2 device that could attach to several access > points simultaneously. > > I thought CAR protocol was to be useful also in cases where you have only > one interface and you want to keep track of the CARs to make fast > handovers? > No, the assumption in this case is that the MN has *two* interfaces, for example, a cellular interface and a Bluetooth or WLAN interface. It could solicit the RA on one interface while the other had a full up connection. In the single interface case, you are right. jak PS: there is a company in Japan that has announced a WLAN card allowing the interface to be on two channels at once. But that is not relevent to the current discussion. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 12:39:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21761 for ; Mon, 25 Mar 2002 12:39:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26829; Mon, 25 Mar 2002 12:28:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26751 for ; Mon, 25 Mar 2002 12:28:13 -0500 (EST) Received: from hotmail.com (f106.law9.hotmail.com [64.4.9.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21206 for ; Mon, 25 Mar 2002 12:28:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:27:40 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:27:40 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Mon, 25 Mar 2002 12:27:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:27:40.0715 (UTC) FILETIME=[5D95A7B0:01C1D422] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, [snip] > >So the key is "expressed the requirement." What does this mean? Does the >MN periodically poll the AR for this information, or does it send a >subscription to receive a notification that then gets passed along as >part of the MN's context transfer when the MN moves? > [Govind] I agree this is an optimization that the network can help the MN to wake up the interface only when necessary. Clearly power control is an obvious case and if the AR knows that the MN has two interfaces it should be enough... Unless the MN indicates that such a help is not needed (as the case when it is using both interfaces) the network can generally assume that only one will be turned on. Also, it needn't wake the MN up for every AR representing the sleeping interface, it can do so only for those which the MN is authorized to roam in, together with AR being able to satisfy the MN's requirements. Also, there is more power saving in waking up selectively than in waking up periodically. [snip] > >I had in mind primarily the latter. If the MN brings up the WLAN >interface, there is no need for CAR discovery because it just needs to >Neighbor Discovery (in IPv6). CAR discovery is only of interest if the >MN wants to find out about other media options prior to bringing up the >interface. [Govind] What if it wants to move from one WLAN network to another... essentially to save cost for eg?, and it has just one interface. Clearly, CAR discovery is needed for FMIPv6 and context transfer and they do talk about WLAN -> WLAN handovers. [snip] > >Sure, but the issue is whether the MN periodically polls or there is >some kind of subscription/notification protocol that gets passed along >with context transfer. The former is simpler, the latter more bandwidth >efficient. [Govind] I don't see any great loss of simplicity in the latter. I do see the bandwidth/power/time efficiency in the latter though. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 12:39:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21771 for ; Mon, 25 Mar 2002 12:39:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29523 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 12:39:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26829; Mon, 25 Mar 2002 12:28:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26751 for ; Mon, 25 Mar 2002 12:28:13 -0500 (EST) Received: from hotmail.com (f106.law9.hotmail.com [64.4.9.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21206 for ; Mon, 25 Mar 2002 12:28:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:27:40 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:27:40 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Mon, 25 Mar 2002 12:27:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:27:40.0715 (UTC) FILETIME=[5D95A7B0:01C1D422] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, [snip] > >So the key is "expressed the requirement." What does this mean? Does the >MN periodically poll the AR for this information, or does it send a >subscription to receive a notification that then gets passed along as >part of the MN's context transfer when the MN moves? > [Govind] I agree this is an optimization that the network can help the MN to wake up the interface only when necessary. Clearly power control is an obvious case and if the AR knows that the MN has two interfaces it should be enough... Unless the MN indicates that such a help is not needed (as the case when it is using both interfaces) the network can generally assume that only one will be turned on. Also, it needn't wake the MN up for every AR representing the sleeping interface, it can do so only for those which the MN is authorized to roam in, together with AR being able to satisfy the MN's requirements. Also, there is more power saving in waking up selectively than in waking up periodically. [snip] > >I had in mind primarily the latter. If the MN brings up the WLAN >interface, there is no need for CAR discovery because it just needs to >Neighbor Discovery (in IPv6). CAR discovery is only of interest if the >MN wants to find out about other media options prior to bringing up the >interface. [Govind] What if it wants to move from one WLAN network to another... essentially to save cost for eg?, and it has just one interface. Clearly, CAR discovery is needed for FMIPv6 and context transfer and they do talk about WLAN -> WLAN handovers. [snip] > >Sure, but the issue is whether the MN periodically polls or there is >some kind of subscription/notification protocol that gets passed along >with context transfer. The former is simpler, the latter more bandwidth >efficient. [Govind] I don't see any great loss of simplicity in the latter. I do see the bandwidth/power/time efficiency in the latter though. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 12:43:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22067 for ; Mon, 25 Mar 2002 12:43:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27902; Mon, 25 Mar 2002 12:32:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27874 for ; Mon, 25 Mar 2002 12:32:42 -0500 (EST) Received: from hotmail.com (f44.law9.hotmail.com [64.4.9.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21481 for ; Mon, 25 Mar 2002 12:32:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:32:10 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:32:10 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 12:32:10 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:32:10.0615 (UTC) FILETIME=[FE752070:01C1D422] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >It doesn't get info over a down interface, it gets it over the up >interface. The protocol tells the MN what's available, including if the >MN brought up the down interface. It avoids having to bring up the >interface if there is nothing there. [Govind] Agreed. > >If the interface is always up, then the MN can just do standard IPv6 >Neighbor Discovery and there is no need for CAR discovery. > > > > > > >If the latter were not so, the MN could just use standard Router > > >Discovery on the interface and there would be no need for CAR >discovery. [Govind] Again, this is possible, essentially what you are saying here is explained in Example 2. But the fact is that if there are many such APs then the process in Example 2 is expensive both in time as well as bandwidth efficiency as well as power as pointed in my earlier mail. [snip] >CAR discovery is completely irrelevent if the MN brings up the >interface. Neighbor Discovery is fine for discovering routers - the MN >solicits router adverts, the routers send them. What's the problem? > >The only reason for CAR discovery is so that the MN doesn't need to >bring up the interface to discover what's available. The sooner we can >agree on that, the sooner we can get to the hard questions, like how to >do it. [Govind] I disagree. Again please see my previous answers. I agree completely that we need to get to the actual protocol designing process soon. But I don't agree with your premise in the previous paragraph at all. Regards, Govind. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 12:43:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22082 for ; Mon, 25 Mar 2002 12:43:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00526 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 12:43:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27902; Mon, 25 Mar 2002 12:32:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27874 for ; Mon, 25 Mar 2002 12:32:42 -0500 (EST) Received: from hotmail.com (f44.law9.hotmail.com [64.4.9.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21481 for ; Mon, 25 Mar 2002 12:32:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:32:10 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:32:10 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 12:32:10 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:32:10.0615 (UTC) FILETIME=[FE752070:01C1D422] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >It doesn't get info over a down interface, it gets it over the up >interface. The protocol tells the MN what's available, including if the >MN brought up the down interface. It avoids having to bring up the >interface if there is nothing there. [Govind] Agreed. > >If the interface is always up, then the MN can just do standard IPv6 >Neighbor Discovery and there is no need for CAR discovery. > > > > > > >If the latter were not so, the MN could just use standard Router > > >Discovery on the interface and there would be no need for CAR >discovery. [Govind] Again, this is possible, essentially what you are saying here is explained in Example 2. But the fact is that if there are many such APs then the process in Example 2 is expensive both in time as well as bandwidth efficiency as well as power as pointed in my earlier mail. [snip] >CAR discovery is completely irrelevent if the MN brings up the >interface. Neighbor Discovery is fine for discovering routers - the MN >solicits router adverts, the routers send them. What's the problem? > >The only reason for CAR discovery is so that the MN doesn't need to >bring up the interface to discover what's available. The sooner we can >agree on that, the sooner we can get to the hard questions, like how to >do it. [Govind] I disagree. Again please see my previous answers. I agree completely that we need to get to the actual protocol designing process soon. But I don't agree with your premise in the previous paragraph at all. Regards, Govind. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 12:47:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22268 for ; Mon, 25 Mar 2002 12:47:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28408; Mon, 25 Mar 2002 12:34:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28366 for ; Mon, 25 Mar 2002 12:34:51 -0500 (EST) Received: from hotmail.com (f229.law7.hotmail.com [216.33.237.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21579 for ; Mon, 25 Mar 2002 12:34:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:34:19 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:34:19 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 17:34:19 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:34:19.0482 (UTC) FILETIME=[4B44ABA0:01C1D423] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Teemu and James: Just to be ultra clear - Luxury of two interfaces is not a generic assumption for CAR discovery problem formulation. Two-connection WLAN card is good for 2 APs, but what if there are 3 or 4 or 5 APs. - Hemant >From: "James Kempf" >To: "Teemu Rinta-aho" >CC: >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Mon, 25 Mar 2002 08:54:45 -0800 > > > > I am not a layer 2 expert, but wouldn't that require that the >interface > > first does a layer 2 handover from the old access point to the new one > > before anything can be done at the IP layer? And at that point all > > communications going through the old AP/AR would cease... At least I >don't > > know any WLAN card or other L2 device that could attach to several >access > > points simultaneously. > > > > I thought CAR protocol was to be useful also in cases where you have >only > > one interface and you want to keep track of the CARs to make fast > > handovers? > > > >No, the assumption in this case is that the MN has *two* interfaces, for >example, a cellular interface and a Bluetooth or WLAN interface. It >could solicit the RA on one interface while the other had a full up >connection. > >In the single interface case, you are right. > > jak > > >PS: there is a company in Japan that has announced a WLAN card allowing >the interface to be on two channels at once. But that is not relevent to >the current discussion. > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 12:47:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22277 for ; Mon, 25 Mar 2002 12:47:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01614 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 12:47:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28408; Mon, 25 Mar 2002 12:34:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28366 for ; Mon, 25 Mar 2002 12:34:51 -0500 (EST) Received: from hotmail.com (f229.law7.hotmail.com [216.33.237.229]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21579 for ; Mon, 25 Mar 2002 12:34:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:34:19 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:34:19 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 17:34:19 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:34:19.0482 (UTC) FILETIME=[4B44ABA0:01C1D423] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Teemu and James: Just to be ultra clear - Luxury of two interfaces is not a generic assumption for CAR discovery problem formulation. Two-connection WLAN card is good for 2 APs, but what if there are 3 or 4 or 5 APs. - Hemant >From: "James Kempf" >To: "Teemu Rinta-aho" >CC: >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Mon, 25 Mar 2002 08:54:45 -0800 > > > > I am not a layer 2 expert, but wouldn't that require that the >interface > > first does a layer 2 handover from the old access point to the new one > > before anything can be done at the IP layer? And at that point all > > communications going through the old AP/AR would cease... At least I >don't > > know any WLAN card or other L2 device that could attach to several >access > > points simultaneously. > > > > I thought CAR protocol was to be useful also in cases where you have >only > > one interface and you want to keep track of the CARs to make fast > > handovers? > > > >No, the assumption in this case is that the MN has *two* interfaces, for >example, a cellular interface and a Bluetooth or WLAN interface. It >could solicit the RA on one interface while the other had a full up >connection. > >In the single interface case, you are right. > > jak > > >PS: there is a company in Japan that has announced a WLAN card allowing >the interface to be on two channels at once. But that is not relevent to >the current discussion. > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 12:56:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22748 for ; Mon, 25 Mar 2002 12:56:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01244; Mon, 25 Mar 2002 12:45:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01205 for ; Mon, 25 Mar 2002 12:45:52 -0500 (EST) Received: from hotmail.com (f90.law9.hotmail.com [64.4.9.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22236 for ; Mon, 25 Mar 2002 12:45:49 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:45:20 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:45:20 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 12:45:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:45:20.0487 (UTC) FILETIME=[D5420770:01C1D424] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Just to add to Hemant's comment. Having a twin connection WLAN card does not imply that none of the problems described earlier, namely power issues, bandwidth issues and time issues, cease to exist. Regards, Govind. >Hi Teemu and James: > >Just to be ultra clear - Luxury of two interfaces is not a generic >assumption for CAR discovery problem formulation. Two-connection WLAN card >is good for 2 APs, but what if there are 3 or 4 or 5 APs. > >- Hemant > > >>From: "James Kempf" >>To: "Teemu Rinta-aho" >>CC: >>Subject: Re: [Seamoby] Comments on the requirements draft >>Date: Mon, 25 Mar 2002 08:54:45 -0800 >> >> >> > I am not a layer 2 expert, but wouldn't that require that the >>interface >> > first does a layer 2 handover from the old access point to the new one >> > before anything can be done at the IP layer? And at that point all >> > communications going through the old AP/AR would cease... At least I >>don't >> > know any WLAN card or other L2 device that could attach to several >>access >> > points simultaneously. >> > >> > I thought CAR protocol was to be useful also in cases where you have >>only >> > one interface and you want to keep track of the CARs to make fast >> > handovers? >> > >> >>No, the assumption in this case is that the MN has *two* interfaces, for >>example, a cellular interface and a Bluetooth or WLAN interface. It >>could solicit the RA on one interface while the other had a full up >>connection. >> >>In the single interface case, you are right. >> >> jak >> >> >>PS: there is a company in Japan that has announced a WLAN card allowing >>the interface to be on two channels at once. But that is not relevent to >>the current discussion. >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 12:56:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22757 for ; Mon, 25 Mar 2002 12:56:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04109 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 12:56:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01244; Mon, 25 Mar 2002 12:45:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01205 for ; Mon, 25 Mar 2002 12:45:52 -0500 (EST) Received: from hotmail.com (f90.law9.hotmail.com [64.4.9.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22236 for ; Mon, 25 Mar 2002 12:45:49 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 09:45:20 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 17:45:20 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 12:45:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 17:45:20.0487 (UTC) FILETIME=[D5420770:01C1D424] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Just to add to Hemant's comment. Having a twin connection WLAN card does not imply that none of the problems described earlier, namely power issues, bandwidth issues and time issues, cease to exist. Regards, Govind. >Hi Teemu and James: > >Just to be ultra clear - Luxury of two interfaces is not a generic >assumption for CAR discovery problem formulation. Two-connection WLAN card >is good for 2 APs, but what if there are 3 or 4 or 5 APs. > >- Hemant > > >>From: "James Kempf" >>To: "Teemu Rinta-aho" >>CC: >>Subject: Re: [Seamoby] Comments on the requirements draft >>Date: Mon, 25 Mar 2002 08:54:45 -0800 >> >> >> > I am not a layer 2 expert, but wouldn't that require that the >>interface >> > first does a layer 2 handover from the old access point to the new one >> > before anything can be done at the IP layer? And at that point all >> > communications going through the old AP/AR would cease... At least I >>don't >> > know any WLAN card or other L2 device that could attach to several >>access >> > points simultaneously. >> > >> > I thought CAR protocol was to be useful also in cases where you have >>only >> > one interface and you want to keep track of the CARs to make fast >> > handovers? >> > >> >>No, the assumption in this case is that the MN has *two* interfaces, for >>example, a cellular interface and a Bluetooth or WLAN interface. It >>could solicit the RA on one interface while the other had a full up >>connection. >> >>In the single interface case, you are right. >> >> jak >> >> >>PS: there is a company in Japan that has announced a WLAN card allowing >>the interface to be on two channels at once. But that is not relevent to >>the current discussion. >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >MSN Photos is the easiest way to share and print your photos: >http://photos.msn.com/support/worldwide.aspx > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 14:13:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27259 for ; Mon, 25 Mar 2002 14:13:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20781; Mon, 25 Mar 2002 14:05:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20734 for ; Mon, 25 Mar 2002 14:05:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26793 for ; Mon, 25 Mar 2002 14:05:13 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PJ4jI02223; Mon, 25 Mar 2002 11:04:45 -0800 (PST) Message-ID: <017e01c1d42f$b3ecda40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 11:03:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Please just let me remind you that the CAR discovery protocol also provides > mapping of L2 ID to IP address of the new AR which is necessary for the > low-latency handoff mechanism proposed in the MobileIP WG. So there is a > case CAR discovery is helpful for single technology handovers. > OK, so what you are saying is that there are two cases: 1) Provding the MN with CAR information on what choices are available or, possibly, when the MN moves into an area where a new choice is possible, like moving into a hot spot area, for MNs that have multiple interfaces. 2) Providing the AR with reverse address translation for CARs for MNs that have single interfaces and want fast handover support. I agree. I don't get the feeling that these two cases are clearly delineated in the requirements. In fact, they seem to me like they are really two separate protocols. > I understand the IETF is pro-end-point-control. Anyway, regarding your > question, couldn't we imagine a case when a network provider wants do a kind > of load-balancing between different access networks in the wireless overlay > network? > Sure, but I think that's a very special case. The more general case (and in fact, the case that is showing up *today*) is that one network provider owns one medium and the other another. Example: at the airport, the cellular provider owns the CDMA network and some WLAN provider owns the WLAN network. And even if both media are owned by one provider, there are probably cost considerations that will involve asking the user whether they want to switch. > I think the beacon in this example is L2 beacon. Isn't there a case the MN > needs to go several steps before it can send a router solicitation message? > I think it depends on the involved L2 technology. Anyway the MN can get the > information it needs without soliciting the new AR by using CAR discovery. > The point of this example seems to me that the MN does not go through such > steps to save power. > But if the MN already has the interface up to the point where it can see an L2 beacon, then presumably it can also bring up IP and solicit the RA, right? The only case where I can see this argument working is in the single interface case, and there I think the L2 protocol will move the MN (either from the MN side or the network side) regardless of what happens at the IP layer. At least, if you want any kind of performance on the handover. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 14:13:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27268 for ; Mon, 25 Mar 2002 14:13:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22868 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 14:13:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20781; Mon, 25 Mar 2002 14:05:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20734 for ; Mon, 25 Mar 2002 14:05:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26793 for ; Mon, 25 Mar 2002 14:05:13 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PJ4jI02223; Mon, 25 Mar 2002 11:04:45 -0800 (PST) Message-ID: <017e01c1d42f$b3ecda40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 11:03:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Please just let me remind you that the CAR discovery protocol also provides > mapping of L2 ID to IP address of the new AR which is necessary for the > low-latency handoff mechanism proposed in the MobileIP WG. So there is a > case CAR discovery is helpful for single technology handovers. > OK, so what you are saying is that there are two cases: 1) Provding the MN with CAR information on what choices are available or, possibly, when the MN moves into an area where a new choice is possible, like moving into a hot spot area, for MNs that have multiple interfaces. 2) Providing the AR with reverse address translation for CARs for MNs that have single interfaces and want fast handover support. I agree. I don't get the feeling that these two cases are clearly delineated in the requirements. In fact, they seem to me like they are really two separate protocols. > I understand the IETF is pro-end-point-control. Anyway, regarding your > question, couldn't we imagine a case when a network provider wants do a kind > of load-balancing between different access networks in the wireless overlay > network? > Sure, but I think that's a very special case. The more general case (and in fact, the case that is showing up *today*) is that one network provider owns one medium and the other another. Example: at the airport, the cellular provider owns the CDMA network and some WLAN provider owns the WLAN network. And even if both media are owned by one provider, there are probably cost considerations that will involve asking the user whether they want to switch. > I think the beacon in this example is L2 beacon. Isn't there a case the MN > needs to go several steps before it can send a router solicitation message? > I think it depends on the involved L2 technology. Anyway the MN can get the > information it needs without soliciting the new AR by using CAR discovery. > The point of this example seems to me that the MN does not go through such > steps to save power. > But if the MN already has the interface up to the point where it can see an L2 beacon, then presumably it can also bring up IP and solicit the RA, right? The only case where I can see this argument working is in the single interface case, and there I think the L2 protocol will move the MN (either from the MN side or the network side) regardless of what happens at the IP layer. At least, if you want any kind of performance on the handover. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 14:34:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28468 for ; Mon, 25 Mar 2002 14:34:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24399; Mon, 25 Mar 2002 14:19:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24369 for ; Mon, 25 Mar 2002 14:19:26 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27474 for ; Mon, 25 Mar 2002 14:19:24 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PJIqI02942; Mon, 25 Mar 2002 11:18:52 -0800 (PST) Message-ID: <018401c1d431$acf5cb00$7e6015ac@T23KEMPF> From: "James Kempf" To: "Satish Jamadagni" , "Eunsoo Shim" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 11:17:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > We all agree that the CAR discovery protocol should assist in identifying > GAARs, arrive at CARs from GAARs and finally a TAR from the CARs. Throughout Selecting a TAR is out of scope. > this process one can see that there will be varied level of information > exchange (context information basically). When identifying the GAARs either > the MN or the AR or a edge device needs to know the geographic coverage of > that AR (one can argue that more can be added at this stage itself). Now Are you talking about GPS co-ordinates or something? I don't see how the MN could make use of this information. All it really needs to know is what options are available at this point in time for bringing up the interfaces it has. > from GAARs to CARs one would expect that the CAR discovery protocol would > provide more than just the geographic coverage. An exchange of a very high > level view of QoS or context support information between ARs (QoS and > context types will have to be agreed upon for this) is what is expected to > arrive at a set of CARs - now till this stage the MN need not come into play > at all. The use of a MNs personal settings and preferences will come into > play at the stage of CARs to TAR. Usually (I dont know if in the future > classes of MNs can be identified and TARs selected for them as a class) the > TAR selection will be biased by the MN considerations - but then again the > MN might have prevelages with the AR so that the AR itself can achieve this > for a (or a class of) MNs. > The requirments already have a statement about capabilities. Is this what you mean? > Also there should be provision for an AR to do a TAR selection given the > fact that the service provider can have policies that can force a mobiles to > handover due to load conditions, inorder to provide better QoS when the load > on other ARs or the underlying L2 becomes available (One of the most > critical understanding of a 4G network is that there are a host of L2s with > a common IP layer and above) in the present understanding and spectrum > sharing in future SDR scenarios (Please note that inter-technology handover > is where much in the understanding of future 4G and SDR networks - we dont > want our CAR protocol to undergo a lot of changes when the notion of > seamless ness as required by a 4G or an SDR network hits the scene) . > I disagree about allowing the AR to "force" a handover in intertechnology situations. For intratechnology handover, I think there is a case to be made for the AR to be involved in handover, for performance reasons. For intertechnology, I think that a common situation is that both networks are owned by different providers, and even when they are owned by the same provider, the provider is more likely to have tariff differences between them, for business purposes. So the owner of the MN is likely to want to be involved in making the decision. > The idea of a CAR discovery protocol SHOULD be to make available the right > amount of information at the right time for the GAARs to CARs to TAR > process. The rest i.e. the exact selection of a subset of GAARs as CARs and > the selection of a TAR should be left open for people like us to make a > living by fitting algorithms in place. > Right, that's why it is out of scope. > > Also there were Qs like CAR being relavent in some scenarios - I think we > should not restrict ourselves to just the MN option - you never know when > the service providers would start offering that extra bit of processing at > the network level as a service differentiator - > The MN is the only entity in a position to know if it has an interface supporting a particular medium or not. How can the AR make the decision? > The MN is of course the king in the TAR selection, but he can have a better > understanding with his home network when the AR can do a TAR selection for > the MN considering the MNs very private settings too. The AR if bound by a > QoS policy might want a user to go to another specific AR with or without an > underlying L2 change at his bidding. > > With all the paging and solication protocols evolving there should also be a > provision for any AR to "entice" a MN into his domain - so to say there > should be provision for an AR to declare to an MN that he is the best AR for > the MN (target triggered case) - Of course how does the AR come to know of > the MN and his QoS settings - at some high level this is possible - going > lower and being sensitive to privacy issues - one will have to work out the > issues. > ???? I don't understand this at all. "entice"? You mean like a coupon in the newspaper giving you half off if you use this network on Monday or something? My impression of current wireless service provider business models (and what I can reasonably imagine them evolving to in the future) is that this not realistic. But, really, we're not here to solve this kind of problem. We just need to figure out how to provide the MN what it needs to achieve an intertechnolgy handover, that is what "seamless" means. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 14:34:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28477 for ; Mon, 25 Mar 2002 14:34:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28170 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 14:34:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24399; Mon, 25 Mar 2002 14:19:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24369 for ; Mon, 25 Mar 2002 14:19:26 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27474 for ; Mon, 25 Mar 2002 14:19:24 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PJIqI02942; Mon, 25 Mar 2002 11:18:52 -0800 (PST) Message-ID: <018401c1d431$acf5cb00$7e6015ac@T23KEMPF> From: "James Kempf" To: "Satish Jamadagni" , "Eunsoo Shim" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 11:17:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > We all agree that the CAR discovery protocol should assist in identifying > GAARs, arrive at CARs from GAARs and finally a TAR from the CARs. Throughout Selecting a TAR is out of scope. > this process one can see that there will be varied level of information > exchange (context information basically). When identifying the GAARs either > the MN or the AR or a edge device needs to know the geographic coverage of > that AR (one can argue that more can be added at this stage itself). Now Are you talking about GPS co-ordinates or something? I don't see how the MN could make use of this information. All it really needs to know is what options are available at this point in time for bringing up the interfaces it has. > from GAARs to CARs one would expect that the CAR discovery protocol would > provide more than just the geographic coverage. An exchange of a very high > level view of QoS or context support information between ARs (QoS and > context types will have to be agreed upon for this) is what is expected to > arrive at a set of CARs - now till this stage the MN need not come into play > at all. The use of a MNs personal settings and preferences will come into > play at the stage of CARs to TAR. Usually (I dont know if in the future > classes of MNs can be identified and TARs selected for them as a class) the > TAR selection will be biased by the MN considerations - but then again the > MN might have prevelages with the AR so that the AR itself can achieve this > for a (or a class of) MNs. > The requirments already have a statement about capabilities. Is this what you mean? > Also there should be provision for an AR to do a TAR selection given the > fact that the service provider can have policies that can force a mobiles to > handover due to load conditions, inorder to provide better QoS when the load > on other ARs or the underlying L2 becomes available (One of the most > critical understanding of a 4G network is that there are a host of L2s with > a common IP layer and above) in the present understanding and spectrum > sharing in future SDR scenarios (Please note that inter-technology handover > is where much in the understanding of future 4G and SDR networks - we dont > want our CAR protocol to undergo a lot of changes when the notion of > seamless ness as required by a 4G or an SDR network hits the scene) . > I disagree about allowing the AR to "force" a handover in intertechnology situations. For intratechnology handover, I think there is a case to be made for the AR to be involved in handover, for performance reasons. For intertechnology, I think that a common situation is that both networks are owned by different providers, and even when they are owned by the same provider, the provider is more likely to have tariff differences between them, for business purposes. So the owner of the MN is likely to want to be involved in making the decision. > The idea of a CAR discovery protocol SHOULD be to make available the right > amount of information at the right time for the GAARs to CARs to TAR > process. The rest i.e. the exact selection of a subset of GAARs as CARs and > the selection of a TAR should be left open for people like us to make a > living by fitting algorithms in place. > Right, that's why it is out of scope. > > Also there were Qs like CAR being relavent in some scenarios - I think we > should not restrict ourselves to just the MN option - you never know when > the service providers would start offering that extra bit of processing at > the network level as a service differentiator - > The MN is the only entity in a position to know if it has an interface supporting a particular medium or not. How can the AR make the decision? > The MN is of course the king in the TAR selection, but he can have a better > understanding with his home network when the AR can do a TAR selection for > the MN considering the MNs very private settings too. The AR if bound by a > QoS policy might want a user to go to another specific AR with or without an > underlying L2 change at his bidding. > > With all the paging and solication protocols evolving there should also be a > provision for any AR to "entice" a MN into his domain - so to say there > should be provision for an AR to declare to an MN that he is the best AR for > the MN (target triggered case) - Of course how does the AR come to know of > the MN and his QoS settings - at some high level this is possible - going > lower and being sensitive to privacy issues - one will have to work out the > issues. > ???? I don't understand this at all. "entice"? You mean like a coupon in the newspaper giving you half off if you use this network on Monday or something? My impression of current wireless service provider business models (and what I can reasonably imagine them evolving to in the future) is that this not realistic. But, really, we're not here to solve this kind of problem. We just need to figure out how to provide the MN what it needs to achieve an intertechnolgy handover, that is what "seamless" means. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 14:46:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29242 for ; Mon, 25 Mar 2002 14:46:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29791; Mon, 25 Mar 2002 14:40:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29755 for ; Mon, 25 Mar 2002 14:40:55 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28945 for ; Mon, 25 Mar 2002 14:40:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PJeLI03752; Mon, 25 Mar 2002 11:40:21 -0800 (PST) Message-ID: <01a601c1d434$ad258630$7e6015ac@T23KEMPF> From: "James Kempf" To: "Teemu Rinta-aho" , Cc: References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 11:38:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > > [DOT] I certainly agree with scalability, just some comments to > > the number of several hundreds of overlapping access points. Even > > when I consider PANs, I can hardly think of scenarios where actually > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > large enough, and I doubt that we had so many WLAN APs. But even then, > > what counts is the number of ARs that have overlapping APs with APs of > > other ARs. I don't quite see that this number would reach several hundreds. > > Maybe you could elaborate a bit on the scenarios you have in mind. > > Maybe "hundreds" is too much for near future, but I > wanted to give a what-if scenario where the protocol must > also survive if there ever is such...? > Well, I'm skeptical of the realism of picocellular scenarios in the intermediate term future. In our lab, we have 5 802.11b access points that costed $800 a piece when they were originally installed (now, they would be somewhat cheaper but not by a factor of 10). These cover the lab. Consider a picocellular scenario in which we increase the number of access points by a factor of 10. In order to keep the total system cost the same, the per access point would cost would have to drop to $80. If the number of access points is increased by a factor of 100 (nanocellular?) then it's $8. Bluetooth originally had the intention of coming in at a cost point of pennies for the chip set, which, when combined with the rest of what's needed to make an access point would conceivably add up to $80 per access point, but the last time I looked, their chip set costs were running about the same as 802.11. We therefore have at least one data point of an attempt to do a cost-effictive picocellular network that failed. So, I don't see picocellular networks being cost effective in the near to intermediate term future, even given Moore's law. The infrastructure cost would make it prohibitive. Most cellular operators are going in the opposite direction, toward larger cells, to avoid having to pay the infrastructure cost. > "Interoperability MUST exist with ARs not implementing the > CAR discovery protocol". > I don't see this as being an issue. Why would an AR not implementing the CAR discovery protocol even care? > What I don't know is whether interoperability is an implicit > general requirement for all protocols or should it > be explicitly written in the requirements draft? I guess > that even if it's not in the draft nobody will probably > make a solution where an MN can only handover to ARs > which support the CAR discovery protocol... > If there are any areas where interoperability is necessary, it should be in the requirements. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 15:27:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01651 for ; Mon, 25 Mar 2002 15:27:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10383; Mon, 25 Mar 2002 15:20:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10345 for ; Mon, 25 Mar 2002 15:19:59 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01172 for ; Mon, 25 Mar 2002 15:19:56 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PKJPI05148; Mon, 25 Mar 2002 12:19:25 -0800 (PST) Message-ID: <01d801c1d43a$22431d60$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 12:17:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > [Govind] What about WLAN -> WLAN? > the MN has one WLAN interface and it is connected to an AP. > Suppose it needs to be handed over to another AP. It can only > perceive the other L2 beacon, but cannot establish connectivity with > the other one without leaving the current interface(ok theoretically > this can be done without letting go of the previous L2 but I don't think > the specs allow this but I'm not sure. Anyways it is quite expensive in > terms of bandwidth, power and time). > I think CAR discovery > is very relevant in this scenario too. I don't think > that only inter-technology handovers alone are in CAR discovery's scope. > Clearly FMIPv6 and context transfer protocols are dependent on this. > Or am I missing something? I thought this was one of the main > intentions to start CAR discovery. I therefore > think it is totally incorrect to presume that CAR discovery is only for > inter-technology handovers. > The WLAN interface hands over the MN at Layer 2 if only WLAN is involved, even if the MN is doing the controlling. Why should CAR discovery be involved? The only place where I can see CAR discovery involved for a single technology handover is for reverse address translation, as in Eunsoo's note. > [Govind] I am not sure > why network controlled handovers must be completely be rejected without > proper review. I think the point to note is that network controlled > handovers does not imply that the MN requirements are neglected. > However, I agree that CAR discovery is not involved here. > Because the MN *must* be involved if the handover is intertechnology. I don't see how it could be otherwise. Only the MN is in a position to know what interfaces it has if they are not powered on. Please let me know why we are having so much difficulty getting this point across. > [Govind] The network is made aware of the MN's requirements as part of its > Home AAA infrastructure (some kind of static profile for the MN) > and this is transferred to the AR. In this case the MN's requirements > are completely known to the MN. So the AR sends the ID of the AR > as best as it can judge to the MN and then the MN makes the final decision > anyways. Essentially give the MN a "veto" power for > the networks decision. Why wouldn't this work? Why not just give the MN a list of what's available and let it decide? What's the point of going through a convoluted AAA exchange? The AAA exchange also might not be accurate. Suppose the MN is a laptop and the user forgot that day to put in their WLAN card. The AAA record might say that the MN's got WLAN, but, in fact, it doesn't. So the AR could hand the MN over to a medium which the MN can't access. >Again, I don't agree with > your notion that CAR discovery is suitable only for inter-technology > handovers , as I have described earlier (WLAN -> WLAN case) > in this mail. Also, clearly when we consider heterogeneous (in capability > and not in technology) ARs, the SIR information alone may not be enough. > Right, so I am willing to concede that there is a place for reverse address translation to support fast handovers, but I don't see this fairly limited use in the requirements. I don't think this involves any capabilities, mobile node preferences, or any other complications of that sort. It is fairly simple. The Layer 2 trigger on the AR says that the MN is about to move to a new AP or AR and all that the Layer 2 trigger gives is a Layer 2 ID. The AR needs to map that into a Layer 3 ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > [Govind] Listening to the beacon, and connected to the L2 device is > two different things. You can't solicit unless you are connected. > Of course, if you have 20 such APs you have to connect to every one first > (and be authenticated and made sure it is authorized to roam > in the AR's net) before soliciting an RAdv. > We are considering the case where this activity is going on with a second interface, not with the same interface on which the MN already has IP service. Thus, what's the problem with it getting connected? If it is looking at a beacon, then presumably there's no power constraint. It doesn't have to give up IP service on the interface where IP service is already available to look at the new interface. > [Govind] Of course it can blindly connect to the first AP it hears. > But are we proposing that? We are giving the MN an option to make the best > choice it can under the circumstances. Yes what you propose is true > but there are bandwidth, time and power issues to take into consideration. > [snip] Like I said, if it can hear a beacon, then presumably there is no problem with power. Otherwise, it would not bother bringing up the interface to the point where it could hear the beacon. If the MN's got the interface card in, then presumably the user knows what kind of bandwidth to expect. Perhaps the link is congested, but I don't see CAR discovery as providing that kind of real time data to the MN. As for time, I don't see what that has to do with it. Maybe you could explain? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 15:27:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01659 for ; Mon, 25 Mar 2002 15:27:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12205 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 15:27:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10383; Mon, 25 Mar 2002 15:20:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10345 for ; Mon, 25 Mar 2002 15:19:59 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01172 for ; Mon, 25 Mar 2002 15:19:56 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PKJPI05148; Mon, 25 Mar 2002 12:19:25 -0800 (PST) Message-ID: <01d801c1d43a$22431d60$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 12:17:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > [Govind] What about WLAN -> WLAN? > the MN has one WLAN interface and it is connected to an AP. > Suppose it needs to be handed over to another AP. It can only > perceive the other L2 beacon, but cannot establish connectivity with > the other one without leaving the current interface(ok theoretically > this can be done without letting go of the previous L2 but I don't think > the specs allow this but I'm not sure. Anyways it is quite expensive in > terms of bandwidth, power and time). > I think CAR discovery > is very relevant in this scenario too. I don't think > that only inter-technology handovers alone are in CAR discovery's scope. > Clearly FMIPv6 and context transfer protocols are dependent on this. > Or am I missing something? I thought this was one of the main > intentions to start CAR discovery. I therefore > think it is totally incorrect to presume that CAR discovery is only for > inter-technology handovers. > The WLAN interface hands over the MN at Layer 2 if only WLAN is involved, even if the MN is doing the controlling. Why should CAR discovery be involved? The only place where I can see CAR discovery involved for a single technology handover is for reverse address translation, as in Eunsoo's note. > [Govind] I am not sure > why network controlled handovers must be completely be rejected without > proper review. I think the point to note is that network controlled > handovers does not imply that the MN requirements are neglected. > However, I agree that CAR discovery is not involved here. > Because the MN *must* be involved if the handover is intertechnology. I don't see how it could be otherwise. Only the MN is in a position to know what interfaces it has if they are not powered on. Please let me know why we are having so much difficulty getting this point across. > [Govind] The network is made aware of the MN's requirements as part of its > Home AAA infrastructure (some kind of static profile for the MN) > and this is transferred to the AR. In this case the MN's requirements > are completely known to the MN. So the AR sends the ID of the AR > as best as it can judge to the MN and then the MN makes the final decision > anyways. Essentially give the MN a "veto" power for > the networks decision. Why wouldn't this work? Why not just give the MN a list of what's available and let it decide? What's the point of going through a convoluted AAA exchange? The AAA exchange also might not be accurate. Suppose the MN is a laptop and the user forgot that day to put in their WLAN card. The AAA record might say that the MN's got WLAN, but, in fact, it doesn't. So the AR could hand the MN over to a medium which the MN can't access. >Again, I don't agree with > your notion that CAR discovery is suitable only for inter-technology > handovers , as I have described earlier (WLAN -> WLAN case) > in this mail. Also, clearly when we consider heterogeneous (in capability > and not in technology) ARs, the SIR information alone may not be enough. > Right, so I am willing to concede that there is a place for reverse address translation to support fast handovers, but I don't see this fairly limited use in the requirements. I don't think this involves any capabilities, mobile node preferences, or any other complications of that sort. It is fairly simple. The Layer 2 trigger on the AR says that the MN is about to move to a new AP or AR and all that the Layer 2 trigger gives is a Layer 2 ID. The AR needs to map that into a Layer 3 ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > [Govind] Listening to the beacon, and connected to the L2 device is > two different things. You can't solicit unless you are connected. > Of course, if you have 20 such APs you have to connect to every one first > (and be authenticated and made sure it is authorized to roam > in the AR's net) before soliciting an RAdv. > We are considering the case where this activity is going on with a second interface, not with the same interface on which the MN already has IP service. Thus, what's the problem with it getting connected? If it is looking at a beacon, then presumably there's no power constraint. It doesn't have to give up IP service on the interface where IP service is already available to look at the new interface. > [Govind] Of course it can blindly connect to the first AP it hears. > But are we proposing that? We are giving the MN an option to make the best > choice it can under the circumstances. Yes what you propose is true > but there are bandwidth, time and power issues to take into consideration. > [snip] Like I said, if it can hear a beacon, then presumably there is no problem with power. Otherwise, it would not bother bringing up the interface to the point where it could hear the beacon. If the MN's got the interface card in, then presumably the user knows what kind of bandwidth to expect. Perhaps the link is congested, but I don't see CAR discovery as providing that kind of real time data to the MN. As for time, I don't see what that has to do with it. Maybe you could explain? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 15:37:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29250 for ; Mon, 25 Mar 2002 14:46:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01331 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 14:46:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29791; Mon, 25 Mar 2002 14:40:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29755 for ; Mon, 25 Mar 2002 14:40:55 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28945 for ; Mon, 25 Mar 2002 14:40:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PJeLI03752; Mon, 25 Mar 2002 11:40:21 -0800 (PST) Message-ID: <01a601c1d434$ad258630$7e6015ac@T23KEMPF> From: "James Kempf" To: "Teemu Rinta-aho" , Cc: References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 11:38:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > > [DOT] I certainly agree with scalability, just some comments to > > the number of several hundreds of overlapping access points. Even > > when I consider PANs, I can hardly think of scenarios where actually > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > large enough, and I doubt that we had so many WLAN APs. But even then, > > what counts is the number of ARs that have overlapping APs with APs of > > other ARs. I don't quite see that this number would reach several hundreds. > > Maybe you could elaborate a bit on the scenarios you have in mind. > > Maybe "hundreds" is too much for near future, but I > wanted to give a what-if scenario where the protocol must > also survive if there ever is such...? > Well, I'm skeptical of the realism of picocellular scenarios in the intermediate term future. In our lab, we have 5 802.11b access points that costed $800 a piece when they were originally installed (now, they would be somewhat cheaper but not by a factor of 10). These cover the lab. Consider a picocellular scenario in which we increase the number of access points by a factor of 10. In order to keep the total system cost the same, the per access point would cost would have to drop to $80. If the number of access points is increased by a factor of 100 (nanocellular?) then it's $8. Bluetooth originally had the intention of coming in at a cost point of pennies for the chip set, which, when combined with the rest of what's needed to make an access point would conceivably add up to $80 per access point, but the last time I looked, their chip set costs were running about the same as 802.11. We therefore have at least one data point of an attempt to do a cost-effictive picocellular network that failed. So, I don't see picocellular networks being cost effective in the near to intermediate term future, even given Moore's law. The infrastructure cost would make it prohibitive. Most cellular operators are going in the opposite direction, toward larger cells, to avoid having to pay the infrastructure cost. > "Interoperability MUST exist with ARs not implementing the > CAR discovery protocol". > I don't see this as being an issue. Why would an AR not implementing the CAR discovery protocol even care? > What I don't know is whether interoperability is an implicit > general requirement for all protocols or should it > be explicitly written in the requirements draft? I guess > that even if it's not in the draft nobody will probably > make a solution where an MN can only handover to ARs > which support the CAR discovery protocol... > If there are any areas where interoperability is necessary, it should be in the requirements. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 16:39:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04676 for ; Mon, 25 Mar 2002 16:39:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28119; Mon, 25 Mar 2002 16:33:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28077 for ; Mon, 25 Mar 2002 16:33:04 -0500 (EST) Received: from hotmail.com (f221.law7.hotmail.com [216.33.237.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04386 for ; Mon, 25 Mar 2002 16:33:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 13:32:33 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 21:32:33 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 21:32:33 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 21:32:33.0667 (UTC) FILETIME=[93443530:01C1D444] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: Some comments below: >From: "James Kempf" >To: "Eunsoo Shim" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > Please just let me remind you that the CAR discovery protocol also >provides > > mapping of L2 ID to IP address of the new AR which is necessary for >the > > low-latency handoff mechanism proposed in the MobileIP WG. So there is >a > > case CAR discovery is helpful for single technology handovers. > > > >OK, so what you are saying is that there are two cases: > >1) Provding the MN with CAR information on what choices are available >or, possibly, when the MN moves into an area where a new choice is >possible, like moving into a hot spot area, for MNs that have multiple >interfaces. > >2) Providing the AR with reverse address translation for CARs for MNs >that have single interfaces and want fast handover support. > >I agree. > >I don't get the feeling that these two cases are clearly delineated in >the requirements. In fact, they seem to me like they are really two >separate protocols. [HC] From the requirements perspective, what all the recent discussion is about is probably the following requirement text (with supporting line that CAR discovery is about comparing MN's requirements with GAAR capabilities and slecting CARs from GAARs): "CAR discovery output MUST be retrievable, possibly selectively, by MN". Also, I assume that there will the the following requirement as well (I think that this was posted before IETF53 and I also saw some WG members endorse it in IETF53 meeting): "MN requirements MUST be made available for CAR discovery". This would mandate a CAR discovery functionality as follows: MN Requirements --(parameters)--> CAR Discovery Module --(output)--> MN ^ | | Capability information about GAARs Again, "CAR discovery module" can reside completely in MN, completely in AR or combination depending upon environment, availability of multiplicity of interfaces with MN etc. Further, the nature of MN requirements input and corresponding output depends upon the environement in which CAR discovery is being used. Also, whether the solution is organized into seperate protocols or single protocol is a solution-specific aspect. (Note: The first requirement in requiremnet spec already says the address translation part. We can keep it so given its importance for fast/seamless handoffs, though it can be subsumed into above generic model (with "one parameter = L2 id", "one capability information about GAARs = L2 to IP addr. maps" and "output=IP address of CAR").) > > > I understand the IETF is pro-end-point-control. Anyway, regarding your > > question, couldn't we imagine a case when a network provider wants do >a kind > > of load-balancing between different access networks in the wireless >overlay > > network? > > > >Sure, but I think that's a very special case. The more general case (and >in fact, the case that is showing up *today*) is that one network >provider owns one medium and the other another. Example: at the airport, >the cellular provider owns the CDMA network and some WLAN provider owns >the WLAN network. [HC]There is a concept of operator owned WLAN that is actually catching up. Some systems are already rolled out in Europe if I am not mistaken. So, both cases are very important - two media owned by two operators and two media owned by single operator. BR, Hemant _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 16:39:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04686 for ; Mon, 25 Mar 2002 16:39:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29819 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 16:39:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28119; Mon, 25 Mar 2002 16:33:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28077 for ; Mon, 25 Mar 2002 16:33:04 -0500 (EST) Received: from hotmail.com (f221.law7.hotmail.com [216.33.237.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04386 for ; Mon, 25 Mar 2002 16:33:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 13:32:33 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 21:32:33 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 21:32:33 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 21:32:33.0667 (UTC) FILETIME=[93443530:01C1D444] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: Some comments below: >From: "James Kempf" >To: "Eunsoo Shim" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > Please just let me remind you that the CAR discovery protocol also >provides > > mapping of L2 ID to IP address of the new AR which is necessary for >the > > low-latency handoff mechanism proposed in the MobileIP WG. So there is >a > > case CAR discovery is helpful for single technology handovers. > > > >OK, so what you are saying is that there are two cases: > >1) Provding the MN with CAR information on what choices are available >or, possibly, when the MN moves into an area where a new choice is >possible, like moving into a hot spot area, for MNs that have multiple >interfaces. > >2) Providing the AR with reverse address translation for CARs for MNs >that have single interfaces and want fast handover support. > >I agree. > >I don't get the feeling that these two cases are clearly delineated in >the requirements. In fact, they seem to me like they are really two >separate protocols. [HC] From the requirements perspective, what all the recent discussion is about is probably the following requirement text (with supporting line that CAR discovery is about comparing MN's requirements with GAAR capabilities and slecting CARs from GAARs): "CAR discovery output MUST be retrievable, possibly selectively, by MN". Also, I assume that there will the the following requirement as well (I think that this was posted before IETF53 and I also saw some WG members endorse it in IETF53 meeting): "MN requirements MUST be made available for CAR discovery". This would mandate a CAR discovery functionality as follows: MN Requirements --(parameters)--> CAR Discovery Module --(output)--> MN ^ | | Capability information about GAARs Again, "CAR discovery module" can reside completely in MN, completely in AR or combination depending upon environment, availability of multiplicity of interfaces with MN etc. Further, the nature of MN requirements input and corresponding output depends upon the environement in which CAR discovery is being used. Also, whether the solution is organized into seperate protocols or single protocol is a solution-specific aspect. (Note: The first requirement in requiremnet spec already says the address translation part. We can keep it so given its importance for fast/seamless handoffs, though it can be subsumed into above generic model (with "one parameter = L2 id", "one capability information about GAARs = L2 to IP addr. maps" and "output=IP address of CAR").) > > > I understand the IETF is pro-end-point-control. Anyway, regarding your > > question, couldn't we imagine a case when a network provider wants do >a kind > > of load-balancing between different access networks in the wireless >overlay > > network? > > > >Sure, but I think that's a very special case. The more general case (and >in fact, the case that is showing up *today*) is that one network >provider owns one medium and the other another. Example: at the airport, >the cellular provider owns the CDMA network and some WLAN provider owns >the WLAN network. [HC]There is a concept of operator owned WLAN that is actually catching up. Some systems are already rolled out in Europe if I am not mistaken. So, both cases are very important - two media owned by two operators and two media owned by single operator. BR, Hemant _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 17:03:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05424 for ; Mon, 25 Mar 2002 17:03:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04312; Mon, 25 Mar 2002 16:57:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04280 for ; Mon, 25 Mar 2002 16:57:55 -0500 (EST) Received: from hotmail.com (f168.law9.hotmail.com [64.4.9.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05204 for ; Mon, 25 Mar 2002 16:57:51 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 13:57:24 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 21:57:24 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 16:57:24 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 21:57:24.0469 (UTC) FILETIME=[0BDA8A50:01C1D448] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, > > [Govind] What about WLAN -> WLAN? > > the MN has one WLAN interface and it is connected to an AP. > > Suppose it needs to be handed over to another AP. It can only > > perceive the other L2 beacon, but cannot establish connectivity with > > the other one without leaving the current interface(ok theoretically > > this can be done without letting go of the previous L2 but I don't >think > > the specs allow this but I'm not sure. Anyways it is quite expensive >in > > terms of bandwidth, power and time). > > I think CAR discovery > > is very relevant in this scenario too. I don't think > > that only inter-technology handovers alone are in CAR discovery's >scope. > > Clearly FMIPv6 and context transfer protocols are dependent on this. > > Or am I missing something? I thought this was one of the main > > intentions to start CAR discovery. I therefore > > think it is totally incorrect to presume that CAR discovery is only >for > > inter-technology handovers. > > > >The WLAN interface hands over the MN at Layer 2 if only WLAN is >involved, even if the MN is doing the controlling. Why should CAR >discovery be involved? [Govind] I don't think my point came across clearly. In your mail you had not mentioned the WLAN -> WLAN case at all which is considered in FMIPv6 like L2 -> IP address translation. CAR discovery needs to be involved if the MN has multiple options... esentially if the MN has to choose the AR to handover to. I thought that was pretty clear. > >The only place where I can see CAR discovery involved for a single >technology handover is for reverse address translation, as in Eunsoo's >note. > [Govind] That CAR discovery is needed for reverse translation is quite obvious from requirement 1 of the current requirement draft. I thought that was the main idea behind the requirement. Anyways, my previous mail was saying this too. > > [Govind] I am not sure > > why network controlled handovers must be completely be rejected >without > > proper review. I think the point to note is that network controlled > > handovers does not imply that the MN requirements are neglected. > > However, I agree that CAR discovery is not involved here. > > > >Because the MN *must* be involved if the handover is intertechnology. I >don't see how it could be otherwise. Only the MN is in a position to >know what interfaces it has if they are not powered on. Please let me >know why we are having so much difficulty getting this point across. [Govind] I agree that the MN *must* be involved too. The main disconnect between us is that you assume that the MN has no role whatsoever if the handover is network controlled. Clearly, the handover can be controlled by the network, i.e., tell the MN when to disconnect etc but still take into account all of the MN's preferences. I don't understand why we are having to get this point across too! Regarding the MN only knowing which interfaces are powered on. What big difference does this make? If the network knows what interfaces the MN has then it can advise it to power on at the appropriate time. If it is already powered on the MN just discards this. If not it acts on it. If the card is not inserted then it just discards the message too. What is the difficulty that you see here. Maybe you can explain it. > > > [Govind] The network is made aware of the MN's requirements as part of >its > > Home AAA infrastructure (some kind of static profile for the MN) > > and this is transferred to the AR. In this case the MN's requirements > > are completely known to the MN. So the AR sends the ID of the AR > > as best as it can judge to the MN and then the MN makes the final >decision > > anyways. Essentially give the MN a "veto" power for > > the networks decision. Why wouldn't this work? > >Why not just give the MN a list of what's available and let it decide? >What's the point of going through a convoluted AAA exchange? [Govind] Of course, this is an option, thats what Example 2 gives. There are performance tradeoffs for each case that thats my main point. Your contention is that any other approach is is infeasible which is not agreeable to me. >The AAA exchange also might not be accurate. Suppose the MN is a laptop >and the user forgot that day to put in their WLAN card. The AAA record >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR >could hand the MN over to a medium which the MN can't access. [Govind] I thought reachability information *from the MN *is part of TAR selection process. If the MN's WLAN card is not inserted, how do you suppose reachability for WLAN APs are got from the MN. So why do you think the network will blindly just handover the MN to a WLAN network? > > >Again, I don't agree with > > your notion that CAR discovery is suitable only for inter-technology > > handovers , as I have described earlier (WLAN -> WLAN case) > > in this mail. Also, clearly when we consider heterogeneous (in >capability > > and not in technology) ARs, the SIR information alone may not be >enough. > > > >Right, so I am willing to concede that there is a place for reverse >address translation to support fast handovers, but I don't see this >fairly limited use in the requirements. I don't think this involves any >capabilities, mobile node preferences, or any other complications of >that sort. It is fairly simple. The Layer 2 trigger on the AR says that >the MN is about to move to a new AP or AR and all that the Layer 2 >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer 3 >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. [Govind] I don't understand your point. As I explained earlier, Requirement 1 essentially deals with L2 to L3 mapping. Why doesn't MN's preferences come into picture, if there are 10 APs connected to different ARs with different capabilities, ofcourse the MN's preferences come into picture. > > > [Govind] Listening to the beacon, and connected to the L2 device is > > two different things. You can't solicit unless you are connected. > > Of course, if you have 20 such APs you have to connect to every one >first > > (and be authenticated and made sure it is authorized to roam > > in the AR's net) before soliciting an RAdv. > > > >We are considering the case where this activity is going on with a >second interface, not with the same interface on which the MN already >has IP service. Thus, what's the problem with it getting connected? If >it is looking at a beacon, then presumably there's no power constraint. >It doesn't have to give up IP service on the interface where IP service >is already available to look at the new interface. [Govind] First, I don't think there is any restriction on the applicability of CAR discovery based on whether there is one interface or two interfaces. Are you saying listening passively to beacons vs attempting to connect to the AP device and futher get a router solicitation have the same power requirements? The main point I'm making is that if there are multiple APs available and the MN has to choose among them, then clearly this has more power implications than just listening to the beacon and passively forward it to a AR. [snip] >Like I said, if it can hear a beacon, then presumably there is no >problem with power. Otherwise, it would not bother bringing up the >interface to the point where it could hear the beacon. If the MN's got >the interface card in, then presumably the user knows what kind of >bandwidth to expect. Perhaps the link is congested, but I don't see CAR >discovery as providing that kind of real time data to the MN. As for >time, I don't see what that has to do with it. Maybe you could explain? [Govind] Please see previous paragraph. My main point is listening to the APs beacons imposes less power constraints than attaching to each one of the APs and get RtAdvs, capabilities, processing them and selecting. I am not going into a MN vs AR CAR discovery here.. but I am pointing out that to say that there is no power constraints for the MN involved in the process above vs. just listening to the beacon is incorrect IMHO. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 17:03:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05433 for ; Mon, 25 Mar 2002 17:03:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05721 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 17:03:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04312; Mon, 25 Mar 2002 16:57:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04280 for ; Mon, 25 Mar 2002 16:57:55 -0500 (EST) Received: from hotmail.com (f168.law9.hotmail.com [64.4.9.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05204 for ; Mon, 25 Mar 2002 16:57:51 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 13:57:24 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 21:57:24 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 16:57:24 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 21:57:24.0469 (UTC) FILETIME=[0BDA8A50:01C1D448] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, > > [Govind] What about WLAN -> WLAN? > > the MN has one WLAN interface and it is connected to an AP. > > Suppose it needs to be handed over to another AP. It can only > > perceive the other L2 beacon, but cannot establish connectivity with > > the other one without leaving the current interface(ok theoretically > > this can be done without letting go of the previous L2 but I don't >think > > the specs allow this but I'm not sure. Anyways it is quite expensive >in > > terms of bandwidth, power and time). > > I think CAR discovery > > is very relevant in this scenario too. I don't think > > that only inter-technology handovers alone are in CAR discovery's >scope. > > Clearly FMIPv6 and context transfer protocols are dependent on this. > > Or am I missing something? I thought this was one of the main > > intentions to start CAR discovery. I therefore > > think it is totally incorrect to presume that CAR discovery is only >for > > inter-technology handovers. > > > >The WLAN interface hands over the MN at Layer 2 if only WLAN is >involved, even if the MN is doing the controlling. Why should CAR >discovery be involved? [Govind] I don't think my point came across clearly. In your mail you had not mentioned the WLAN -> WLAN case at all which is considered in FMIPv6 like L2 -> IP address translation. CAR discovery needs to be involved if the MN has multiple options... esentially if the MN has to choose the AR to handover to. I thought that was pretty clear. > >The only place where I can see CAR discovery involved for a single >technology handover is for reverse address translation, as in Eunsoo's >note. > [Govind] That CAR discovery is needed for reverse translation is quite obvious from requirement 1 of the current requirement draft. I thought that was the main idea behind the requirement. Anyways, my previous mail was saying this too. > > [Govind] I am not sure > > why network controlled handovers must be completely be rejected >without > > proper review. I think the point to note is that network controlled > > handovers does not imply that the MN requirements are neglected. > > However, I agree that CAR discovery is not involved here. > > > >Because the MN *must* be involved if the handover is intertechnology. I >don't see how it could be otherwise. Only the MN is in a position to >know what interfaces it has if they are not powered on. Please let me >know why we are having so much difficulty getting this point across. [Govind] I agree that the MN *must* be involved too. The main disconnect between us is that you assume that the MN has no role whatsoever if the handover is network controlled. Clearly, the handover can be controlled by the network, i.e., tell the MN when to disconnect etc but still take into account all of the MN's preferences. I don't understand why we are having to get this point across too! Regarding the MN only knowing which interfaces are powered on. What big difference does this make? If the network knows what interfaces the MN has then it can advise it to power on at the appropriate time. If it is already powered on the MN just discards this. If not it acts on it. If the card is not inserted then it just discards the message too. What is the difficulty that you see here. Maybe you can explain it. > > > [Govind] The network is made aware of the MN's requirements as part of >its > > Home AAA infrastructure (some kind of static profile for the MN) > > and this is transferred to the AR. In this case the MN's requirements > > are completely known to the MN. So the AR sends the ID of the AR > > as best as it can judge to the MN and then the MN makes the final >decision > > anyways. Essentially give the MN a "veto" power for > > the networks decision. Why wouldn't this work? > >Why not just give the MN a list of what's available and let it decide? >What's the point of going through a convoluted AAA exchange? [Govind] Of course, this is an option, thats what Example 2 gives. There are performance tradeoffs for each case that thats my main point. Your contention is that any other approach is is infeasible which is not agreeable to me. >The AAA exchange also might not be accurate. Suppose the MN is a laptop >and the user forgot that day to put in their WLAN card. The AAA record >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR >could hand the MN over to a medium which the MN can't access. [Govind] I thought reachability information *from the MN *is part of TAR selection process. If the MN's WLAN card is not inserted, how do you suppose reachability for WLAN APs are got from the MN. So why do you think the network will blindly just handover the MN to a WLAN network? > > >Again, I don't agree with > > your notion that CAR discovery is suitable only for inter-technology > > handovers , as I have described earlier (WLAN -> WLAN case) > > in this mail. Also, clearly when we consider heterogeneous (in >capability > > and not in technology) ARs, the SIR information alone may not be >enough. > > > >Right, so I am willing to concede that there is a place for reverse >address translation to support fast handovers, but I don't see this >fairly limited use in the requirements. I don't think this involves any >capabilities, mobile node preferences, or any other complications of >that sort. It is fairly simple. The Layer 2 trigger on the AR says that >the MN is about to move to a new AP or AR and all that the Layer 2 >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer 3 >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. [Govind] I don't understand your point. As I explained earlier, Requirement 1 essentially deals with L2 to L3 mapping. Why doesn't MN's preferences come into picture, if there are 10 APs connected to different ARs with different capabilities, ofcourse the MN's preferences come into picture. > > > [Govind] Listening to the beacon, and connected to the L2 device is > > two different things. You can't solicit unless you are connected. > > Of course, if you have 20 such APs you have to connect to every one >first > > (and be authenticated and made sure it is authorized to roam > > in the AR's net) before soliciting an RAdv. > > > >We are considering the case where this activity is going on with a >second interface, not with the same interface on which the MN already >has IP service. Thus, what's the problem with it getting connected? If >it is looking at a beacon, then presumably there's no power constraint. >It doesn't have to give up IP service on the interface where IP service >is already available to look at the new interface. [Govind] First, I don't think there is any restriction on the applicability of CAR discovery based on whether there is one interface or two interfaces. Are you saying listening passively to beacons vs attempting to connect to the AP device and futher get a router solicitation have the same power requirements? The main point I'm making is that if there are multiple APs available and the MN has to choose among them, then clearly this has more power implications than just listening to the beacon and passively forward it to a AR. [snip] >Like I said, if it can hear a beacon, then presumably there is no >problem with power. Otherwise, it would not bother bringing up the >interface to the point where it could hear the beacon. If the MN's got >the interface card in, then presumably the user knows what kind of >bandwidth to expect. Perhaps the link is congested, but I don't see CAR >discovery as providing that kind of real time data to the MN. As for >time, I don't see what that has to do with it. Maybe you could explain? [Govind] Please see previous paragraph. My main point is listening to the APs beacons imposes less power constraints than attaching to each one of the APs and get RtAdvs, capabilities, processing them and selecting. I am not going into a MN vs AR CAR discovery here.. but I am pointing out that to say that there is no power constraints for the MN involved in the process above vs. just listening to the beacon is incorrect IMHO. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 17:03:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05473 for ; Mon, 25 Mar 2002 17:03:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04006; Mon, 25 Mar 2002 16:56:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03930 for ; Mon, 25 Mar 2002 16:56:42 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05163 for ; Mon, 25 Mar 2002 16:56:38 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PLuAI09064; Mon, 25 Mar 2002 13:56:10 -0800 (PST) Message-ID: <027801c1d447$a690f990$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Mon, 25 Mar 2002 13:53:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > [Govind] I agree this is an optimization that the network can help > the MN to wake up the interface only when necessary. Clearly power control > is an obvious case and if the AR knows that the MN has two interfaces it > should be enough... Unless the MN indicates that such > a help is not needed (as the case when it is using both interfaces) > the network can generally assume that only one will be turned on. I can't see how the AR can know how many interfaces the MN has. On any particular day, there may be two or only one, or maybe even none if the user forgot all her interface cards. > Also, it needn't wake the MN up for every AR representing the sleeping > interface, it can do so only for those which the MN is authorized to roam > in, together with AR being able to satisfy the MN's requirements. > Also, there is more power saving in waking up selectively than in > waking up periodically. > The AR won't do the waking, the MN will. That is, if the MN is getting traffic on one interface, it will get the CAR information on that interface, then the MN will make the decision about whether to power up the other interface. How can the AR wake the MN on an interface that doesn't have any power, much less IP service? More specifically, the software on the MN will probably ask the user about whether they want to switch it on, or perhaps some kind of user agent. > [Govind] What if it wants to move from one WLAN network to another... > essentially to save cost for eg?, and it has just one interface. > Clearly, CAR discovery is needed for FMIPv6 and context transfer and > they do talk about WLAN -> WLAN handovers. > [snip] To my knowledge, it is not possible to deploy two different 802.11b networks in the same area. It would be possible to deploy an 802.11a and 802.11b network because they operate in different frequency ranges, but I view that as essentially two different media. Not sure about 802.11g. > > > >Sure, but the issue is whether the MN periodically polls or there is > >some kind of subscription/notification protocol that gets passed along > >with context transfer. The former is simpler, the latter more bandwidth > >efficient. > > [Govind] I don't see any great loss of simplicity in the latter. I do see > the bandwidth/power/time efficiency in the latter though. > > Well, the other alternative is that the AR could simply pass the CAR information along when the MN arrives. No need for the AR to know anything more than that the MN arrives, i.e. keep it reeeaaal simple. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 17:03:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05481 for ; Mon, 25 Mar 2002 17:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05822 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 17:03:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04006; Mon, 25 Mar 2002 16:56:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03930 for ; Mon, 25 Mar 2002 16:56:42 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05163 for ; Mon, 25 Mar 2002 16:56:38 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PLuAI09064; Mon, 25 Mar 2002 13:56:10 -0800 (PST) Message-ID: <027801c1d447$a690f990$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Mon, 25 Mar 2002 13:53:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > [Govind] I agree this is an optimization that the network can help > the MN to wake up the interface only when necessary. Clearly power control > is an obvious case and if the AR knows that the MN has two interfaces it > should be enough... Unless the MN indicates that such > a help is not needed (as the case when it is using both interfaces) > the network can generally assume that only one will be turned on. I can't see how the AR can know how many interfaces the MN has. On any particular day, there may be two or only one, or maybe even none if the user forgot all her interface cards. > Also, it needn't wake the MN up for every AR representing the sleeping > interface, it can do so only for those which the MN is authorized to roam > in, together with AR being able to satisfy the MN's requirements. > Also, there is more power saving in waking up selectively than in > waking up periodically. > The AR won't do the waking, the MN will. That is, if the MN is getting traffic on one interface, it will get the CAR information on that interface, then the MN will make the decision about whether to power up the other interface. How can the AR wake the MN on an interface that doesn't have any power, much less IP service? More specifically, the software on the MN will probably ask the user about whether they want to switch it on, or perhaps some kind of user agent. > [Govind] What if it wants to move from one WLAN network to another... > essentially to save cost for eg?, and it has just one interface. > Clearly, CAR discovery is needed for FMIPv6 and context transfer and > they do talk about WLAN -> WLAN handovers. > [snip] To my knowledge, it is not possible to deploy two different 802.11b networks in the same area. It would be possible to deploy an 802.11a and 802.11b network because they operate in different frequency ranges, but I view that as essentially two different media. Not sure about 802.11g. > > > >Sure, but the issue is whether the MN periodically polls or there is > >some kind of subscription/notification protocol that gets passed along > >with context transfer. The former is simpler, the latter more bandwidth > >efficient. > > [Govind] I don't see any great loss of simplicity in the latter. I do see > the bandwidth/power/time efficiency in the latter though. > > Well, the other alternative is that the AR could simply pass the CAR information along when the MN arrives. No need for the AR to know anything more than that the MN arrives, i.e. keep it reeeaaal simple. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 17:05:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05516 for ; Mon, 25 Mar 2002 17:05:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05322; Mon, 25 Mar 2002 17:01:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05283 for ; Mon, 25 Mar 2002 17:01:53 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05336 for ; Mon, 25 Mar 2002 17:01:50 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PM1LI09284; Mon, 25 Mar 2002 14:01:21 -0800 (PST) Message-ID: <028201c1d448$5fb250e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 13:59:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Just to be ultra clear - Luxury of two interfaces is not a generic > assumption for CAR discovery problem formulation. Two-connection WLAN card > is good for 2 APs, but what if there are 3 or 4 or 5 APs. > Does the MN have different interface cards for each or are they the same? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 17:05:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05525 for ; Mon, 25 Mar 2002 17:05:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06188 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 17:05:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05322; Mon, 25 Mar 2002 17:01:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05283 for ; Mon, 25 Mar 2002 17:01:53 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05336 for ; Mon, 25 Mar 2002 17:01:50 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PM1LI09284; Mon, 25 Mar 2002 14:01:21 -0800 (PST) Message-ID: <028201c1d448$5fb250e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 13:59:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Just to be ultra clear - Luxury of two interfaces is not a generic > assumption for CAR discovery problem formulation. Two-connection WLAN card > is good for 2 APs, but what if there are 3 or 4 or 5 APs. > Does the MN have different interface cards for each or are they the same? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 17:07:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05638 for ; Mon, 25 Mar 2002 17:07:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05080; Mon, 25 Mar 2002 17:00:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05049 for ; Mon, 25 Mar 2002 17:00:57 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05297 for ; Mon, 25 Mar 2002 17:00:54 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PM0QI09256; Mon, 25 Mar 2002 14:00:26 -0800 (PST) Message-ID: <027c01c1d448$3ee28150$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 13:58:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > > > >If the latter were not so, the MN could just use standard Router > > > >Discovery on the interface and there would be no need for CAR > >discovery. > > [Govind] Again, this is possible, essentially what you are saying here > is explained in Example 2. But the fact is that if there are many such > APs then the process in Example 2 is expensive both in time as well > as bandwidth efficiency as well as power as pointed in my earlier mail. > [snip] > I don't understand this. If the MN's power is up for it getting a beacon, it presumably brought the interface up that far because it wants to use it. What's the bandwidth and power consideration? The harder case is how the MN finds out that it should bring up the interface in the first place. > >CAR discovery is completely irrelevent if the MN brings up the > >interface. Neighbor Discovery is fine for discovering routers - the MN > >solicits router adverts, the routers send them. What's the problem? > > > >The only reason for CAR discovery is so that the MN doesn't need to > >bring up the interface to discover what's available. The sooner we can > >agree on that, the sooner we can get to the hard questions, like how to > >do it. > > [Govind] I disagree. Again please see my previous answers. > I agree completely that we need > to get to the actual protocol designing process soon. But I don't > agree with your premise in the previous paragraph at all. > Please explain. You seem to think the problem lies in finding an AR when the MN has already brought up an interface. I'm saying that that problem is already solved by IPv6 router discovery. I think the problem lies in the MN finding out that there is another wireless technology available, so that it can bring up the interface far enough to get the beacon. That and doing reverse address translation for router/access point L2 identifiers to IP addresses. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 17:07:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05647 for ; Mon, 25 Mar 2002 17:07:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06750 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 17:07:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05080; Mon, 25 Mar 2002 17:00:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05049 for ; Mon, 25 Mar 2002 17:00:57 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05297 for ; Mon, 25 Mar 2002 17:00:54 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2PM0QI09256; Mon, 25 Mar 2002 14:00:26 -0800 (PST) Message-ID: <027c01c1d448$3ee28150$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 13:58:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > > > >If the latter were not so, the MN could just use standard Router > > > >Discovery on the interface and there would be no need for CAR > >discovery. > > [Govind] Again, this is possible, essentially what you are saying here > is explained in Example 2. But the fact is that if there are many such > APs then the process in Example 2 is expensive both in time as well > as bandwidth efficiency as well as power as pointed in my earlier mail. > [snip] > I don't understand this. If the MN's power is up for it getting a beacon, it presumably brought the interface up that far because it wants to use it. What's the bandwidth and power consideration? The harder case is how the MN finds out that it should bring up the interface in the first place. > >CAR discovery is completely irrelevent if the MN brings up the > >interface. Neighbor Discovery is fine for discovering routers - the MN > >solicits router adverts, the routers send them. What's the problem? > > > >The only reason for CAR discovery is so that the MN doesn't need to > >bring up the interface to discover what's available. The sooner we can > >agree on that, the sooner we can get to the hard questions, like how to > >do it. > > [Govind] I disagree. Again please see my previous answers. > I agree completely that we need > to get to the actual protocol designing process soon. But I don't > agree with your premise in the previous paragraph at all. > Please explain. You seem to think the problem lies in finding an AR when the MN has already brought up an interface. I'm saying that that problem is already solved by IPv6 router discovery. I think the problem lies in the MN finding out that there is another wireless technology available, so that it can bring up the interface far enough to get the beacon. That and doing reverse address translation for router/access point L2 identifiers to IP addresses. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 17:14:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05917 for ; Mon, 25 Mar 2002 17:14:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07717; Mon, 25 Mar 2002 17:11:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07691 for ; Mon, 25 Mar 2002 17:11:44 -0500 (EST) Received: from hotmail.com (f272.law7.hotmail.com [216.33.236.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05772 for ; Mon, 25 Mar 2002 17:11:41 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 14:11:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 22:11:13 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 22:11:13 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 22:11:14.0238 (UTC) FILETIME=[FA6F3DE0:01C1D449] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some agreements and some disagreements below, marked as . >From: "James Kempf" >To: "Hemant Chaskar" >CC: "Kempf" >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 25 Mar 2002 13:23:33 -0800 > > > > > > After the CAR discovery discussion in IETF53, it seems that we >need to > > > > emphasize certain points about CAR discovery. They are as follows: > > > > > > > > - CAR discovery always considers MN requirements while choosing >CARs > > >from > > > > GAARs. > > > > > > > > > >This statement sounds like some other entity beside the MN is doing >the > > >choosing (TAR selection). > > > > [HC] The statement is about "CAR discovery" (as seen from the first >two > > words of the sentence), which is different from TAR selection, as >stated in > > problem statement. Then, why would a statement made for CAR discovery >imply > > anything for TAR selection? > > > > I can't see the relevance of CAR discovery > >The relevance is that I would like the requirement to read as follows: > > The CAR discovery protocol MUST provide the MN with enough >information about GAARs, including information concerning capabilities, >so that the MN can make a choice of which CAR to select. As I already said, this requirements has to be there. I completely agree with you. But then, it is also important to unambiguously state that "MN requirements MUST be made available for CAR discovery if needed". > >No ambiguity about what is doing the selecting. > > > [HC] Nobody is denying that MN should be given choice. But that does >not > > mean that processor instructions for comparing MN requirements with AR > > capabilities need to be executed in MN. They could as well be executed >in > > AR. Not executing processor instructions in MN does not mean that MN >does > > not have choice. What matters is input to execution of instructions. > > > >So explain to me how the AR is supposed to know what kinds of interfaces >the MN has? I don't know why this is so hard to understand, maybe I'm >not explaining it well. Is it too difficult for MN to tell so to AR? I do not think so. There is another possibility of having it in MN's service profile as well. I can't see how the AR can know what interfaces >the MN has on any particular day, so I can't possibly see a role for the >AR in selecting an interface for the MN. > > > > > So I would rephrase this: > > > > > > CAR discovery provides the MN with information on CARs for the >MN to > > >choose which TAR it wants to > > > hand over to. > > > > > > [HC] That is good. But it is not a "rephrase", it is a "different" > > statement. What I was talking about is "providing MN requirements to >CAR > > discovery module", what you are saying in above statement is >"providing CAR > > output to MN". Both are different, but I think both need to be there. > > > >"CAR discovery module" is too ambiguous. I'd like the requirements to >clearly state that the MN is the one in charge for intertechnology >handover. But then, "being in charge" is very ambiguous too. What does it precisely mean form an algorithmic perspective? If it precludes network-assisted CAR discovery, then I am not sure. I think network-assisted CAR discovery can be useful for certain intertechnology cases too. It does not immediately make sense to me to fix such a solution for inter-technology case. >Otherwise, people start proposing complicated AAA transactions >that are completely unnecessary and likely to fail anyway. See my above >rewording. The AR *should not* and *cannot* have any role in selecting >an interface for the MN in an intertechnology handover situation, >because it *cannot* know a priori what interfaces the MN has. [HC] That is like fixing a solution. In the requirements phase, we should give freedom to designers to design what is the best from performance perspective and specific environments. As long as requirements do not constrain above solution that you have in mind, what is the concern? Also, MN can easily tell AR what interfaces it has (send on ICMP message for example) or this information can be statically configured in MN's service profile. > >What I am saying is your proposal for requirement language is likely to >lead to unrealistic and complicated proposals for implementation, that >have a high likelihood of failing in many cases. > > > >This is too complicated. After solcitiing the new RA, the MN can >decide > > >whether to connect or not. > > > > [HC] I disagree that this is complicated. It is fairly simple: Listen >to > > beacon - grab AP id - send to AR_current - wait for CAR ID. This is >very > > time and power efficient, and also, can feed into fast/seamless >handoff > > protocols. > > > >Why go through the AR on the other interface when you can simply solicit >an RA on the new one? This is a standard IPv6 procedure. What's the >point of introducing an entirely new procedure? > >Furthermore, how does the MN know to power up the second interface in >the first place? The whole point of CAR discovery, IMHO, is to tell the >MN exactly that. Once it knows, it can simply use standard IPv6/MIPv6 >mechanisms (or IPv4 if the network is a IPv4 network). [HC] What your are saying here is one solution. I do not think that any of the requirements preclude it. But that does not mean that the requirements should be formulated around this solution. > > > [HC] It hears the new AP (e.g. an RF broadcast channel), not the new >AR yet. > > Various things need to happen including many message exchanges over >wireless > > before MN can be deemed to be listening to new AR. > > > >One of those things is that it solicits an RA on the new interface. This >is not "many message exchanges" it is exactly 1, at the IP level. Or wer >e you thinking of GPRS? [HC] Sure, just like MN can go from GPRS to WLAN, it can go from WLAN to GPRS as well. > > > >The current AR doesn't have to be involved if the MN periodically >polls. > > > > [HC] Periodic polling is power inefficient compared to selecting >awakeing. > > Also, waking up for WLAN beacons that are not willing to provide you >service > > is not efficient. > > > >Hemant, we are talking about sending traffic on which the MN already has >active IP service, not a dormant mode MN. [HC]MN already has IP traffic service on one interface. The second one is sleeping. Waking it up and sending IP level messages through it (when possibly not required) does consume power and takes processor MIPs. >If you don't like polling, and I agree that it is inefficient, there are >other ways to do it. We could have an update pushed to the MN when a new >network medium becomes available, like when it enters a hotspot. [HC] Yes, I think that is one example of the usefulness of network-assisted CAR discovery for inter-technology case. Polling is clearly very inefficient. > > jak > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 17:14:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05927 for ; Mon, 25 Mar 2002 17:14:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08511 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 17:14:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07717; Mon, 25 Mar 2002 17:11:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07691 for ; Mon, 25 Mar 2002 17:11:44 -0500 (EST) Received: from hotmail.com (f272.law7.hotmail.com [216.33.236.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05772 for ; Mon, 25 Mar 2002 17:11:41 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 14:11:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 22:11:13 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 25 Mar 2002 22:11:13 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 22:11:14.0238 (UTC) FILETIME=[FA6F3DE0:01C1D449] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Some agreements and some disagreements below, marked as . >From: "James Kempf" >To: "Hemant Chaskar" >CC: "Kempf" >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 25 Mar 2002 13:23:33 -0800 > > > > > > After the CAR discovery discussion in IETF53, it seems that we >need to > > > > emphasize certain points about CAR discovery. They are as follows: > > > > > > > > - CAR discovery always considers MN requirements while choosing >CARs > > >from > > > > GAARs. > > > > > > > > > >This statement sounds like some other entity beside the MN is doing >the > > >choosing (TAR selection). > > > > [HC] The statement is about "CAR discovery" (as seen from the first >two > > words of the sentence), which is different from TAR selection, as >stated in > > problem statement. Then, why would a statement made for CAR discovery >imply > > anything for TAR selection? > > > > I can't see the relevance of CAR discovery > >The relevance is that I would like the requirement to read as follows: > > The CAR discovery protocol MUST provide the MN with enough >information about GAARs, including information concerning capabilities, >so that the MN can make a choice of which CAR to select. As I already said, this requirements has to be there. I completely agree with you. But then, it is also important to unambiguously state that "MN requirements MUST be made available for CAR discovery if needed". > >No ambiguity about what is doing the selecting. > > > [HC] Nobody is denying that MN should be given choice. But that does >not > > mean that processor instructions for comparing MN requirements with AR > > capabilities need to be executed in MN. They could as well be executed >in > > AR. Not executing processor instructions in MN does not mean that MN >does > > not have choice. What matters is input to execution of instructions. > > > >So explain to me how the AR is supposed to know what kinds of interfaces >the MN has? I don't know why this is so hard to understand, maybe I'm >not explaining it well. Is it too difficult for MN to tell so to AR? I do not think so. There is another possibility of having it in MN's service profile as well. I can't see how the AR can know what interfaces >the MN has on any particular day, so I can't possibly see a role for the >AR in selecting an interface for the MN. > > > > > So I would rephrase this: > > > > > > CAR discovery provides the MN with information on CARs for the >MN to > > >choose which TAR it wants to > > > hand over to. > > > > > > [HC] That is good. But it is not a "rephrase", it is a "different" > > statement. What I was talking about is "providing MN requirements to >CAR > > discovery module", what you are saying in above statement is >"providing CAR > > output to MN". Both are different, but I think both need to be there. > > > >"CAR discovery module" is too ambiguous. I'd like the requirements to >clearly state that the MN is the one in charge for intertechnology >handover. But then, "being in charge" is very ambiguous too. What does it precisely mean form an algorithmic perspective? If it precludes network-assisted CAR discovery, then I am not sure. I think network-assisted CAR discovery can be useful for certain intertechnology cases too. It does not immediately make sense to me to fix such a solution for inter-technology case. >Otherwise, people start proposing complicated AAA transactions >that are completely unnecessary and likely to fail anyway. See my above >rewording. The AR *should not* and *cannot* have any role in selecting >an interface for the MN in an intertechnology handover situation, >because it *cannot* know a priori what interfaces the MN has. [HC] That is like fixing a solution. In the requirements phase, we should give freedom to designers to design what is the best from performance perspective and specific environments. As long as requirements do not constrain above solution that you have in mind, what is the concern? Also, MN can easily tell AR what interfaces it has (send on ICMP message for example) or this information can be statically configured in MN's service profile. > >What I am saying is your proposal for requirement language is likely to >lead to unrealistic and complicated proposals for implementation, that >have a high likelihood of failing in many cases. > > > >This is too complicated. After solcitiing the new RA, the MN can >decide > > >whether to connect or not. > > > > [HC] I disagree that this is complicated. It is fairly simple: Listen >to > > beacon - grab AP id - send to AR_current - wait for CAR ID. This is >very > > time and power efficient, and also, can feed into fast/seamless >handoff > > protocols. > > > >Why go through the AR on the other interface when you can simply solicit >an RA on the new one? This is a standard IPv6 procedure. What's the >point of introducing an entirely new procedure? > >Furthermore, how does the MN know to power up the second interface in >the first place? The whole point of CAR discovery, IMHO, is to tell the >MN exactly that. Once it knows, it can simply use standard IPv6/MIPv6 >mechanisms (or IPv4 if the network is a IPv4 network). [HC] What your are saying here is one solution. I do not think that any of the requirements preclude it. But that does not mean that the requirements should be formulated around this solution. > > > [HC] It hears the new AP (e.g. an RF broadcast channel), not the new >AR yet. > > Various things need to happen including many message exchanges over >wireless > > before MN can be deemed to be listening to new AR. > > > >One of those things is that it solicits an RA on the new interface. This >is not "many message exchanges" it is exactly 1, at the IP level. Or wer >e you thinking of GPRS? [HC] Sure, just like MN can go from GPRS to WLAN, it can go from WLAN to GPRS as well. > > > >The current AR doesn't have to be involved if the MN periodically >polls. > > > > [HC] Periodic polling is power inefficient compared to selecting >awakeing. > > Also, waking up for WLAN beacons that are not willing to provide you >service > > is not efficient. > > > >Hemant, we are talking about sending traffic on which the MN already has >active IP service, not a dormant mode MN. [HC]MN already has IP traffic service on one interface. The second one is sleeping. Waking it up and sending IP level messages through it (when possibly not required) does consume power and takes processor MIPs. >If you don't like polling, and I agree that it is inefficient, there are >other ways to do it. We could have an update pushed to the MN when a new >network medium becomes available, like when it enters a hotspot. [HC] Yes, I think that is one example of the usefulness of network-assisted CAR discovery for inter-technology case. Polling is clearly very inefficient. > > jak > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 17:17:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06044 for ; Mon, 25 Mar 2002 17:17:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07975; Mon, 25 Mar 2002 17:12:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07943 for ; Mon, 25 Mar 2002 17:12:29 -0500 (EST) Received: from hotmail.com (f169.law9.hotmail.com [64.4.9.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05817 for ; Mon, 25 Mar 2002 17:12:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 14:11:58 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 22:11:58 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Mon, 25 Mar 2002 17:11:58 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 22:11:58.0611 (UTC) FILETIME=[14E20630:01C1D44A] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >I can't see how the AR can know how many interfaces the MN has. On any >particular day, there may be two or only one, or maybe even none if the >user forgot all her interface cards. [Govind] Well this information can be kept as part of the MN's profile. But I am sure there are other ways to do it. As I explained in the previous mail, I don't see why the MN's forgetting to power on a interface card or forget inserting is such a big deal. Again, I am not advocating that this is the way to do it. All I am saying is that we shouldn't say that this isn't possible at this stage when we are just considering requirements. > >The AR won't do the waking, the MN will. That is, if the MN is getting >traffic on one interface, it will get the CAR information on that >interface, then the MN will make the decision about whether to power up >the other interface. >How can the AR wake the MN on an interface that doesn't have any power, >much less IP service? [Govind] Ofcourse, the MN will do the waking, but the AR can help it wake up selectively as opposed to the MN periodically waking up as you seem to suggest as the only way to go. > >More specifically, the software on the MN will probably ask the user >about whether they want to switch it on, or perhaps some kind of user >agent. [Govind] Maybe, but that is quite out of scope for the current discussion. The point is whether the network can help or not. I believe that it can. > > > [Govind] What if it wants to move from one WLAN network to another... > > essentially to save cost for eg?, and it has just one interface. > > Clearly, CAR discovery is needed for FMIPv6 and context transfer and > > they do talk about WLAN -> WLAN handovers. > > [snip] > >To my knowledge, it is not possible to deploy two different 802.11b >networks in the same area. It would be possible to deploy an 802.11a and >802.11b network because they operate in different frequency ranges, but >I view that as essentially two different media. Not sure about 802.11g. [Govind]Frankly, I don't know about this i.e., if it is a part of the spec.. But theoretically at least it should be possible to operate in the same frequency. Even if the spreading codes are the same. Yes, this will cause packet collisions but CSMA/CA can handle it is it not? All we have to make sure is we backoff properly and make sure that the MN receives beacons. My previous discussions however were under the assumptions that multiple APs of WLANs are found. > > > [Govind] I don't see any great loss of simplicity in the latter. I do >see > > the bandwidth/power/time efficiency in the latter though. > > > > > >Well, the other alternative is that the AR could simply pass the CAR >information along when the MN arrives. No need for the AR to know >anything more than that the MN arrives, i.e. keep it reeeaaal simple. [Govind] I agree that we should keep the actual solution simple. But in the process we shouldn't compromise on getting to the best solution. Regards, Govind. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 17:17:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06053 for ; Mon, 25 Mar 2002 17:17:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09419 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 17:17:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07975; Mon, 25 Mar 2002 17:12:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07943 for ; Mon, 25 Mar 2002 17:12:29 -0500 (EST) Received: from hotmail.com (f169.law9.hotmail.com [64.4.9.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05817 for ; Mon, 25 Mar 2002 17:12:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 14:11:58 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 22:11:58 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Mon, 25 Mar 2002 17:11:58 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 22:11:58.0611 (UTC) FILETIME=[14E20630:01C1D44A] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >I can't see how the AR can know how many interfaces the MN has. On any >particular day, there may be two or only one, or maybe even none if the >user forgot all her interface cards. [Govind] Well this information can be kept as part of the MN's profile. But I am sure there are other ways to do it. As I explained in the previous mail, I don't see why the MN's forgetting to power on a interface card or forget inserting is such a big deal. Again, I am not advocating that this is the way to do it. All I am saying is that we shouldn't say that this isn't possible at this stage when we are just considering requirements. > >The AR won't do the waking, the MN will. That is, if the MN is getting >traffic on one interface, it will get the CAR information on that >interface, then the MN will make the decision about whether to power up >the other interface. >How can the AR wake the MN on an interface that doesn't have any power, >much less IP service? [Govind] Ofcourse, the MN will do the waking, but the AR can help it wake up selectively as opposed to the MN periodically waking up as you seem to suggest as the only way to go. > >More specifically, the software on the MN will probably ask the user >about whether they want to switch it on, or perhaps some kind of user >agent. [Govind] Maybe, but that is quite out of scope for the current discussion. The point is whether the network can help or not. I believe that it can. > > > [Govind] What if it wants to move from one WLAN network to another... > > essentially to save cost for eg?, and it has just one interface. > > Clearly, CAR discovery is needed for FMIPv6 and context transfer and > > they do talk about WLAN -> WLAN handovers. > > [snip] > >To my knowledge, it is not possible to deploy two different 802.11b >networks in the same area. It would be possible to deploy an 802.11a and >802.11b network because they operate in different frequency ranges, but >I view that as essentially two different media. Not sure about 802.11g. [Govind]Frankly, I don't know about this i.e., if it is a part of the spec.. But theoretically at least it should be possible to operate in the same frequency. Even if the spreading codes are the same. Yes, this will cause packet collisions but CSMA/CA can handle it is it not? All we have to make sure is we backoff properly and make sure that the MN receives beacons. My previous discussions however were under the assumptions that multiple APs of WLANs are found. > > > [Govind] I don't see any great loss of simplicity in the latter. I do >see > > the bandwidth/power/time efficiency in the latter though. > > > > > >Well, the other alternative is that the AR could simply pass the CAR >information along when the MN arrives. No need for the AR to know >anything more than that the MN arrives, i.e. keep it reeeaaal simple. [Govind] I agree that we should keep the actual solution simple. But in the process we shouldn't compromise on getting to the best solution. Regards, Govind. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Mar 25 17:26:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06277 for ; Mon, 25 Mar 2002 17:26:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10854; Mon, 25 Mar 2002 17:24:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10818 for ; Mon, 25 Mar 2002 17:24:00 -0500 (EST) Received: from hotmail.com (f118.law9.hotmail.com [64.4.9.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06217 for ; Mon, 25 Mar 2002 17:23:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 14:23:30 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 22:23:29 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 17:23:29 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 22:23:30.0127 (UTC) FILETIME=[B10EFDF0:01C1D44B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > > >If the latter were not so, the MN could just use standard Router > > > > >Discovery on the interface and there would be no need for CAR > > >discovery. > > > > [Govind] Again, this is possible, essentially what you are saying here > > is explained in Example 2. But the fact is that if there are many such > > APs then the process in Example 2 is expensive both in time as well > > as bandwidth efficiency as well as power as pointed in my earlier >mail. > > [snip] > > > >I don't understand this. If the MN's power is up for it getting a >beacon, it presumably brought the interface up that far because it wants >to use it. What's the bandwidth and power consideration? > >The harder case is how the MN finds out that it should bring up the >interface in the first place. [Govind] Yes, it wants to use it. But it does not to waste power on CAR discovery and choosing among a plethora of beacons. Exactly my point. If the MN is going to use it to connect to a beacon, get RtAdv, get capabilities etc and then reject it because it does not fit its profile isn't there a wastage of bandwidth and power? > > > >CAR discovery is completely irrelevent if the MN brings up the > > >interface. Neighbor Discovery is fine for discovering routers - the >MN > > >solicits router adverts, the routers send them. What's the problem? > > > > > >The only reason for CAR discovery is so that the MN doesn't need to > > >bring up the interface to discover what's available. The sooner we >can > > >agree on that, the sooner we can get to the hard questions, like how >to > > >do it. > > > > [Govind] I disagree. Again please see my previous answers. > > I agree completely that we need > > to get to the actual protocol designing process soon. But I don't > > agree with your premise in the previous paragraph at all. > > > >Please explain. > >You seem to think the problem lies in finding an AR when the MN has >already brought up an interface. I'm saying that that problem is already >solved by IPv6 router discovery. > >I think the problem lies in the MN finding out that there is another >wireless technology available, so that it can bring up the interface far >enough to get the beacon. [Govind] I think the main miscommunication here is that you say when this interface is up it is connected to an AP and thats it. In my world, when the interface is up it is scanning for possible APs and trying to decide which one to connect to, but not actually connected to one. I agree that once L2 layer connectivity is established you can use standard router discovery. No argument there. But the only point I'm tryng to make rather unsuccessfully here so far is that the correct way to go MAY not be to accept the first L2 connection. However, if your earlier point is true that only one WLAN AP can be found then we don't have an argument as I agree CAR discovery is not of much use there, except probably to indicate to the MN that sticking with the other interface is better, in the event that the new AR does not have the requisite capabilities. > >That and doing reverse address translation for router/access point L2 >identifiers to IP addresses. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Mar 25 17:26:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06287 for ; Mon, 25 Mar 2002 17:26:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11385 for seamoby-archive@odin.ietf.org; Mon, 25 Mar 2002 17:26:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10854; Mon, 25 Mar 2002 17:24:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10818 for ; Mon, 25 Mar 2002 17:24:00 -0500 (EST) Received: from hotmail.com (f118.law9.hotmail.com [64.4.9.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06217 for ; Mon, 25 Mar 2002 17:23:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 14:23:30 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 25 Mar 2002 22:23:29 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Mon, 25 Mar 2002 17:23:29 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2002 22:23:30.0127 (UTC) FILETIME=[B10EFDF0:01C1D44B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > > >If the latter were not so, the MN could just use standard Router > > > > >Discovery on the interface and there would be no need for CAR > > >discovery. > > > > [Govind] Again, this is possible, essentially what you are saying here > > is explained in Example 2. But the fact is that if there are many such > > APs then the process in Example 2 is expensive both in time as well > > as bandwidth efficiency as well as power as pointed in my earlier >mail. > > [snip] > > > >I don't understand this. If the MN's power is up for it getting a >beacon, it presumably brought the interface up that far because it wants >to use it. What's the bandwidth and power consideration? > >The harder case is how the MN finds out that it should bring up the >interface in the first place. [Govind] Yes, it wants to use it. But it does not to waste power on CAR discovery and choosing among a plethora of beacons. Exactly my point. If the MN is going to use it to connect to a beacon, get RtAdv, get capabilities etc and then reject it because it does not fit its profile isn't there a wastage of bandwidth and power? > > > >CAR discovery is completely irrelevent if the MN brings up the > > >interface. Neighbor Discovery is fine for discovering routers - the >MN > > >solicits router adverts, the routers send them. What's the problem? > > > > > >The only reason for CAR discovery is so that the MN doesn't need to > > >bring up the interface to discover what's available. The sooner we >can > > >agree on that, the sooner we can get to the hard questions, like how >to > > >do it. > > > > [Govind] I disagree. Again please see my previous answers. > > I agree completely that we need > > to get to the actual protocol designing process soon. But I don't > > agree with your premise in the previous paragraph at all. > > > >Please explain. > >You seem to think the problem lies in finding an AR when the MN has >already brought up an interface. I'm saying that that problem is already >solved by IPv6 router discovery. > >I think the problem lies in the MN finding out that there is another >wireless technology available, so that it can bring up the interface far >enough to get the beacon. [Govind] I think the main miscommunication here is that you say when this interface is up it is connected to an AP and thats it. In my world, when the interface is up it is scanning for possible APs and trying to decide which one to connect to, but not actually connected to one. I agree that once L2 layer connectivity is established you can use standard router discovery. No argument there. But the only point I'm tryng to make rather unsuccessfully here so far is that the correct way to go MAY not be to accept the first L2 connection. However, if your earlier point is true that only one WLAN AP can be found then we don't have an argument as I agree CAR discovery is not of much use there, except probably to indicate to the MN that sticking with the other interface is better, in the event that the new AR does not have the requisite capabilities. > >That and doing reverse address translation for router/access point L2 >identifiers to IP addresses. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 02:57:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26852 for ; Tue, 26 Mar 2002 02:57:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25646; Tue, 26 Mar 2002 02:52:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25615 for ; Tue, 26 Mar 2002 02:52:53 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26821 for ; Tue, 26 Mar 2002 02:52:50 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id ED3D222E13; Tue, 26 Mar 2002 09:50:35 +0200 (EET) Date: Tue, 26 Mar 2002 09:50:32 +0200 (EET) From: Teemu Rinta-aho To: Hemant Chaskar Cc: Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Mon, 25 Mar 2002, Hemant Chaskar wrote: > Just to be ultra clear - Luxury of two interfaces is not a generic > assumption for CAR discovery problem formulation. Two-connection WLAN card > is good for 2 APs, but what if there are 3 or 4 or 5 APs. Yes, I agree on that! I agree that the CAR discovery should work in cases where there is only one interface in the MN which can only be connected to one AP at a time. BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 02:57:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26862 for ; Tue, 26 Mar 2002 02:57:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA26634 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 02:57:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25646; Tue, 26 Mar 2002 02:52:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25615 for ; Tue, 26 Mar 2002 02:52:53 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26821 for ; Tue, 26 Mar 2002 02:52:50 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id ED3D222E13; Tue, 26 Mar 2002 09:50:35 +0200 (EET) Date: Tue, 26 Mar 2002 09:50:32 +0200 (EET) From: Teemu Rinta-aho To: Hemant Chaskar Cc: Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Mon, 25 Mar 2002, Hemant Chaskar wrote: > Just to be ultra clear - Luxury of two interfaces is not a generic > assumption for CAR discovery problem formulation. Two-connection WLAN card > is good for 2 APs, but what if there are 3 or 4 or 5 APs. Yes, I agree on that! I agree that the CAR discovery should work in cases where there is only one interface in the MN which can only be connected to one AP at a time. BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 05:37:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28666 for ; Tue, 26 Mar 2002 05:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01253; Tue, 26 Mar 2002 05:24:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01218 for ; Tue, 26 Mar 2002 05:23:59 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28527 for ; Tue, 26 Mar 2002 05:23:55 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 7FA0522E13; Tue, 26 Mar 2002 12:21:38 +0200 (EET) Date: Tue, 26 Mar 2002 12:21:34 +0200 (EET) From: Teemu Rinta-aho To: James Kempf Cc: Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: <01a601c1d434$ad258630$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Mon, 25 Mar 2002, James Kempf wrote: > > Maybe "hundreds" is too much for near future, but I > > wanted to give a what-if scenario where the protocol must > > also survive if there ever is such...? > > Well, I'm skeptical of the realism of picocellular scenarios in the > intermediate > term future. I don't disagree with that. I just wanted to bring this issue into discussion. It all depends on whether or not the requirements should cover the current and intermediate future only or the possibly quite distant future also.. -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 05:37:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28677 for ; Tue, 26 Mar 2002 05:37:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04316 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 05:37:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01253; Tue, 26 Mar 2002 05:24:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01218 for ; Tue, 26 Mar 2002 05:23:59 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28527 for ; Tue, 26 Mar 2002 05:23:55 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 7FA0522E13; Tue, 26 Mar 2002 12:21:38 +0200 (EET) Date: Tue, 26 Mar 2002 12:21:34 +0200 (EET) From: Teemu Rinta-aho To: James Kempf Cc: Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: <01a601c1d434$ad258630$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Mon, 25 Mar 2002, James Kempf wrote: > > Maybe "hundreds" is too much for near future, but I > > wanted to give a what-if scenario where the protocol must > > also survive if there ever is such...? > > Well, I'm skeptical of the realism of picocellular scenarios in the > intermediate > term future. I don't disagree with that. I just wanted to bring this issue into discussion. It all depends on whether or not the requirements should cover the current and intermediate future only or the possibly quite distant future also.. -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 06:36:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29159 for ; Tue, 26 Mar 2002 06:36:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12534; Tue, 26 Mar 2002 06:13:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12489 for ; Tue, 26 Mar 2002 06:13:13 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28967 for ; Tue, 26 Mar 2002 06:13:08 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g2QBCfQ87289 for ; Tue, 26 Mar 2002 12:12:41 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (kauai.mobility.ccrle.nec.de [192.168.101.96]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA25619 for ; Tue, 26 Mar 2002 12:12:41 +0100 Message-ID: <3CA057A9.9781CBB4@ccrle.nec.de> Date: Tue, 26 Mar 2002 12:12:41 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] continuation on DMHA protocol specification Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi IP pagers, according to the notification during Seamoby WG session at IETF#53, DMHA specification will be taken out of Seamoby WG's activities. Since there has already been done very good work in this area, I propose to not throw away what's already there. So, let us continue working on technical issues of DMHA specification where respective Seamoby activities terminated. As a first step we set up a separate mailing list for DMHA protocol specification purposes. Everybody who is interested is invited to participate. Simply subscribe to the DMHA mailing list: send a 'subscribe dmha' to 'majordomo@ccrle.nec.de' and follow instructions sent to you by majordomo. The address of the list is 'dmha@ccrle.nec.de'. I am looking forward to have good technical continuation of work on DMHA protocol development. Marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 06:37:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29169 for ; Tue, 26 Mar 2002 06:37:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA17957 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 06:37:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12534; Tue, 26 Mar 2002 06:13:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12489 for ; Tue, 26 Mar 2002 06:13:13 -0500 (EST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28967 for ; Tue, 26 Mar 2002 06:13:08 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g2QBCfQ87289 for ; Tue, 26 Mar 2002 12:12:41 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (kauai.mobility.ccrle.nec.de [192.168.101.96]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA25619 for ; Tue, 26 Mar 2002 12:12:41 +0100 Message-ID: <3CA057A9.9781CBB4@ccrle.nec.de> Date: Tue, 26 Mar 2002 12:12:41 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Seamoby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] continuation on DMHA protocol specification Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi IP pagers, according to the notification during Seamoby WG session at IETF#53, DMHA specification will be taken out of Seamoby WG's activities. Since there has already been done very good work in this area, I propose to not throw away what's already there. So, let us continue working on technical issues of DMHA specification where respective Seamoby activities terminated. As a first step we set up a separate mailing list for DMHA protocol specification purposes. Everybody who is interested is invited to participate. Simply subscribe to the DMHA mailing list: send a 'subscribe dmha' to 'majordomo@ccrle.nec.de' and follow instructions sent to you by majordomo. The address of the list is 'dmha@ccrle.nec.de'. I am looking forward to have good technical continuation of work on DMHA protocol development. Marco _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 08:24:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01544 for ; Tue, 26 Mar 2002 08:23:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11809; Tue, 26 Mar 2002 08:19:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11729 for ; Tue, 26 Mar 2002 08:19:15 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01439 for ; Tue, 26 Mar 2002 08:19:13 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QDLd114940 for ; Tue, 26 Mar 2002 07:21:39 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Mar 2002 07:19:14 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 07:18:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Seamoby] Comments on the requirements draft Date: Tue, 26 Mar 2002 08:18:25 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on the requirements draft Thread-Index: AcHT8i5TurJ8hER0Sx6JhDeuu4MkEAA1IQUf To: Cc: X-OriginalArrivalTime: 26 Mar 2002 13:18:27.0027 (UTC) FILETIME=[B6E7B230:01C1D4C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA11731 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Teemu, some comments inline... > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But even then, > what counts is the number of ARs that have overlapping APs with APs of > other ARs. I don't quite see that this number would reach several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. Maybe "hundreds" is too much for near future, but I wanted to give a what-if scenario where the protocol must also survive if there ever is such...? [DOT] Yes, but it should be kept in mind that we don't have to design a protocol for picocells here since there might be better mechanisms. But again, as I said, what counts are overlapping APs of different ARs. In most of the cases of small picocells, I either assume many APs connected to one AR (hence the overlapping APs of different ARs is rather small) and/or APs with a small coverage area anyway (e.g., Bluetooth). It all comes to the point if tens or even hundreds of APs of different ARs, overlapping a dedicated physical area is very likely. That's what I doubt. But again, it has to scale to some extent, I agree. > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > and capability knowledge through CAR) not considered as a CAR, it should still > be possible to handover to this AR? This is indeed true but not within the scope > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > be identified for that), it should be ok that a CAR solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > did not reveal capabilities). However, if the MN (or the AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > selection, which is not within the scope of CAR discovery. CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > input to TAR selection (wherever latter is implemented). Another input might be > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > as well. I agree with your comment. I should have written my comment: "Interoperability MUST exist with ARs not implementing the CAR discovery protocol". What I don't know is whether interoperability is an implicit general requirement for all protocols or should it be explicitly written in the requirements draft? I guess that even if it's not in the draft nobody will probably make a solution where an MN can only handover to ARs which support the CAR discovery protocol... [DOT] Remember, CAR discovery only determines a set of CARs, it does not imply a certain handover decision. CAR discovery is only one of maybe several inputs in the final decision, which is BTW called TAR selection (and is defined out of scope for this work). If your TAR selection, and therefore the handover algorithm, only relies on this set of CARs and totally neglects ARs that are not provided through CAR (since they do not implement the protocol), then the responsibility for that lies in your TAR selectio, not in the CAR discovery. Hence, it is the TAR selection that needs attention when considering 'non-CAR-compliant' ARs. > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > If you have a TAR selection scheme that resides in the MN, it is fairly > easy to do so. If your signal strength fades for instance too fast, you just > skip CAR discovery and select one of the AR from which you receive a current > beacon. But again, this is TAR selection and not within the scope of the problem. > But if you choose to do CAR (wherever it is implemented), it will always add > to your handover time since you have to run certain mechanisms. How this tradeoff > can be determined is not clear to me and looks like an implementation issue in > the entity that runs the TAR selection (which again use CAR discovery as an input). I agree. [DOT] Does the agreement mean that we shouldn't consider this requirement for CAR discovery, since it is related to TAR selection? Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 08:24:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01554 for ; Tue, 26 Mar 2002 08:24:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13002 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 08:24:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11809; Tue, 26 Mar 2002 08:19:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11729 for ; Tue, 26 Mar 2002 08:19:15 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01439 for ; Tue, 26 Mar 2002 08:19:13 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QDLd114940 for ; Tue, 26 Mar 2002 07:21:39 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Mar 2002 07:19:14 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 07:18:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Seamoby] Comments on the requirements draft Date: Tue, 26 Mar 2002 08:18:25 -0500 Message-ID: Thread-Topic: [Seamoby] Comments on the requirements draft Thread-Index: AcHT8i5TurJ8hER0Sx6JhDeuu4MkEAA1IQUf To: Cc: X-OriginalArrivalTime: 26 Mar 2002 13:18:27.0027 (UTC) FILETIME=[B6E7B230:01C1D4C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA11731 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Teemu, some comments inline... > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But even then, > what counts is the number of ARs that have overlapping APs with APs of > other ARs. I don't quite see that this number would reach several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. Maybe "hundreds" is too much for near future, but I wanted to give a what-if scenario where the protocol must also survive if there ever is such...? [DOT] Yes, but it should be kept in mind that we don't have to design a protocol for picocells here since there might be better mechanisms. But again, as I said, what counts are overlapping APs of different ARs. In most of the cases of small picocells, I either assume many APs connected to one AR (hence the overlapping APs of different ARs is rather small) and/or APs with a small coverage area anyway (e.g., Bluetooth). It all comes to the point if tens or even hundreds of APs of different ARs, overlapping a dedicated physical area is very likely. That's what I doubt. But again, it has to scale to some extent, I agree. > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > and capability knowledge through CAR) not considered as a CAR, it should still > be possible to handover to this AR? This is indeed true but not within the scope > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > be identified for that), it should be ok that a CAR solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > did not reveal capabilities). However, if the MN (or the AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > selection, which is not within the scope of CAR discovery. CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > input to TAR selection (wherever latter is implemented). Another input might be > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > as well. I agree with your comment. I should have written my comment: "Interoperability MUST exist with ARs not implementing the CAR discovery protocol". What I don't know is whether interoperability is an implicit general requirement for all protocols or should it be explicitly written in the requirements draft? I guess that even if it's not in the draft nobody will probably make a solution where an MN can only handover to ARs which support the CAR discovery protocol... [DOT] Remember, CAR discovery only determines a set of CARs, it does not imply a certain handover decision. CAR discovery is only one of maybe several inputs in the final decision, which is BTW called TAR selection (and is defined out of scope for this work). If your TAR selection, and therefore the handover algorithm, only relies on this set of CARs and totally neglects ARs that are not provided through CAR (since they do not implement the protocol), then the responsibility for that lies in your TAR selectio, not in the CAR discovery. Hence, it is the TAR selection that needs attention when considering 'non-CAR-compliant' ARs. > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > If you have a TAR selection scheme that resides in the MN, it is fairly > easy to do so. If your signal strength fades for instance too fast, you just > skip CAR discovery and select one of the AR from which you receive a current > beacon. But again, this is TAR selection and not within the scope of the problem. > But if you choose to do CAR (wherever it is implemented), it will always add > to your handover time since you have to run certain mechanisms. How this tradeoff > can be determined is not clear to me and looks like an implementation issue in > the entity that runs the TAR selection (which again use CAR discovery as an input). I agree. [DOT] Does the agreement mean that we shouldn't consider this requirement for CAR discovery, since it is related to TAR selection? Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 08:56:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03004 for ; Tue, 26 Mar 2002 08:56:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16917; Tue, 26 Mar 2002 08:38:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16880 for ; Tue, 26 Mar 2002 08:38:05 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02133 for ; Tue, 26 Mar 2002 08:38:03 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 53F9A22FCF; Tue, 26 Mar 2002 15:37:35 +0200 (EET) Date: Tue, 26 Mar 2002 15:35:44 +0200 (EET) From: Teemu Rinta-aho To: Cc: Subject: RE: [Seamoby] Comments on the requirements draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Thanks for the comments, Dirk. My comments inline. On Tue, 26 Mar 2002 Dirk.Trossen@nokia.com wrote: > > [DOT] I certainly agree with scalability, just some comments to > > the number of several hundreds of overlapping access points. Even > > when I consider PANs, I can hardly think of scenarios where actually > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > large enough, and I doubt that we had so many WLAN APs. But even then, > > what counts is the number of ARs that have overlapping APs with APs of > > other ARs. I don't quite see that this number would reach several hundreds. > > Maybe you could elaborate a bit on the scenarios you have in mind. > > Maybe "hundreds" is too much for near future, but I > wanted to give a what-if scenario where the protocol must > also survive if there ever is such...? > > [DOT] Yes, but it should be kept in mind that we don't have to design a > protocol for picocells here since there might be better mechanisms. But again, > as I said, what counts are overlapping APs of different ARs. In most > of the cases of small picocells, I either assume many APs connected to > one AR (hence the overlapping APs of different ARs is rather small) > and/or APs with a small coverage area anyway (e.g., Bluetooth). It all > comes to the point if tens or even hundreds of APs of different ARs, overlapping a dedicated physical area is very likely. That's what I > doubt. But again, it has to scale to some extent, I agree. I agree with that (but also see my reply to James Kempf). Anyway, I think there should be something about scalability in the draft.. > > 3.X INTEROPERABILITY > > > > - Interoperability MUST exist with non-CAR ARs. > > > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > > and capability knowledge through CAR) not considered as a CAR, it should still > > be possible to handover to this AR? This is indeed true but not within the scope > > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > > be identified for that), it should be ok that a CAR solution does not include > > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > > did not reveal capabilities). However, if the MN (or the AR) would find any other > > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > > selection, which is not within the scope of CAR discovery. CAR discovery only > > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > > input to TAR selection (wherever latter is implemented). Another input might be > > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > > as well. > > I agree with your comment. I should have written my comment: > > "Interoperability MUST exist with ARs not implementing the > CAR discovery protocol". > > What I don't know is whether interoperability is an implicit > general requirement for all protocols or should it > be explicitly written in the requirements draft? I guess > that even if it's not in the draft nobody will probably > make a solution where an MN can only handover to ARs > which support the CAR discovery protocol... > > [DOT] Remember, CAR discovery only determines a set of CARs, > it does not imply a certain handover decision. CAR discovery is only one of > maybe several inputs in the final decision, which is BTW called > TAR selection (and is defined out of scope for this work). > If your TAR selection, and therefore the handover algorithm, only relies > on this set of CARs and totally neglects ARs that are not provided through > CAR (since they do not implement the protocol), then the responsibility for > that lies in your TAR selectio, not in the CAR discovery. Hence, > it is the TAR selection that needs attention when considering > 'non-CAR-compliant' ARs. With interoperability I meant that the implementation of the CAR discovery, whatever it will be like, should not mess up existing things and make the life of non-CAR-supporting ARs harder than necessary. I am not sure if this kind of things should usually be written in the draft or not, it just came to my mind when reading the draft that there is nothing about interoperability. > > 3.X PERFORMANCE > > > > - CAR/GAAR protocol MUST NOT add to handover times in > > cases when the connection to the old AR is lost and there > > are ongoing communication waiting for network access. In > > those cases the MN must get a new AR as fast as possible, > > not spending much time on the TAR algorithm. > > > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > > If you have a TAR selection scheme that resides in the MN, it is fairly > > easy to do so. If your signal strength fades for instance too fast, you just > > skip CAR discovery and select one of the AR from which you receive a current > > beacon. But again, this is TAR selection and not within the scope of the problem. > > But if you choose to do CAR (wherever it is implemented), it will always add > > to your handover time since you have to run certain mechanisms. How this tradeoff > > can be determined is not clear to me and looks like an implementation issue in > > the entity that runs the TAR selection (which again use CAR discovery as an input). > > I agree. > > [DOT] Does the agreement mean that we shouldn't consider this requirement > for CAR discovery, since it is related to TAR selection? Exactly! It should be in the TAR requirements draft, if there ever will be one.. BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 08:56:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03014 for ; Tue, 26 Mar 2002 08:56:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22044 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 08:56:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16917; Tue, 26 Mar 2002 08:38:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16880 for ; Tue, 26 Mar 2002 08:38:05 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02133 for ; Tue, 26 Mar 2002 08:38:03 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 53F9A22FCF; Tue, 26 Mar 2002 15:37:35 +0200 (EET) Date: Tue, 26 Mar 2002 15:35:44 +0200 (EET) From: Teemu Rinta-aho To: Cc: Subject: RE: [Seamoby] Comments on the requirements draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Thanks for the comments, Dirk. My comments inline. On Tue, 26 Mar 2002 Dirk.Trossen@nokia.com wrote: > > [DOT] I certainly agree with scalability, just some comments to > > the number of several hundreds of overlapping access points. Even > > when I consider PANs, I can hardly think of scenarios where actually > > hundreds of coverage areas overlap. Bluetooth coverage areas are not > > large enough, and I doubt that we had so many WLAN APs. But even then, > > what counts is the number of ARs that have overlapping APs with APs of > > other ARs. I don't quite see that this number would reach several hundreds. > > Maybe you could elaborate a bit on the scenarios you have in mind. > > Maybe "hundreds" is too much for near future, but I > wanted to give a what-if scenario where the protocol must > also survive if there ever is such...? > > [DOT] Yes, but it should be kept in mind that we don't have to design a > protocol for picocells here since there might be better mechanisms. But again, > as I said, what counts are overlapping APs of different ARs. In most > of the cases of small picocells, I either assume many APs connected to > one AR (hence the overlapping APs of different ARs is rather small) > and/or APs with a small coverage area anyway (e.g., Bluetooth). It all > comes to the point if tens or even hundreds of APs of different ARs, overlapping a dedicated physical area is very likely. That's what I > doubt. But again, it has to scale to some extent, I agree. I agree with that (but also see my reply to James Kempf). Anyway, I think there should be something about scalability in the draft.. > > 3.X INTEROPERABILITY > > > > - Interoperability MUST exist with non-CAR ARs. > > > > [DOT] How do you mean this? If a non-CAR is (due to the lack of identification > > and capability knowledge through CAR) not considered as a CAR, it should still > > be possible to handover to this AR? This is indeed true but not within the scope > > of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to > > be identified for that), it should be ok that a CAR solution does not include > > these non-CAR ARs (one reason might be that the non-CAR AR did not allow the > > CAR solution's GAAR identifitication - another reasons might be that the non-CAR > > did not reveal capabilities). However, if the MN (or the AR) would find any other > > means to identify this non-CAR AR, and the MN (or the AR) makes the decision to > > handoff to this non-CAR AR, that's fine and still possible. But this is TAR > > selection, which is not within the scope of CAR discovery. CAR discovery only > > gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE > > input to TAR selection (wherever latter is implemented). Another input might be > > the detection of non-CAR ARs which you might consider in your TAR selection algorithm > > as well. > > I agree with your comment. I should have written my comment: > > "Interoperability MUST exist with ARs not implementing the > CAR discovery protocol". > > What I don't know is whether interoperability is an implicit > general requirement for all protocols or should it > be explicitly written in the requirements draft? I guess > that even if it's not in the draft nobody will probably > make a solution where an MN can only handover to ARs > which support the CAR discovery protocol... > > [DOT] Remember, CAR discovery only determines a set of CARs, > it does not imply a certain handover decision. CAR discovery is only one of > maybe several inputs in the final decision, which is BTW called > TAR selection (and is defined out of scope for this work). > If your TAR selection, and therefore the handover algorithm, only relies > on this set of CARs and totally neglects ARs that are not provided through > CAR (since they do not implement the protocol), then the responsibility for > that lies in your TAR selectio, not in the CAR discovery. Hence, > it is the TAR selection that needs attention when considering > 'non-CAR-compliant' ARs. With interoperability I meant that the implementation of the CAR discovery, whatever it will be like, should not mess up existing things and make the life of non-CAR-supporting ARs harder than necessary. I am not sure if this kind of things should usually be written in the draft or not, it just came to my mind when reading the draft that there is nothing about interoperability. > > 3.X PERFORMANCE > > > > - CAR/GAAR protocol MUST NOT add to handover times in > > cases when the connection to the old AR is lost and there > > are ongoing communication waiting for network access. In > > those cases the MN must get a new AR as fast as possible, > > not spending much time on the TAR algorithm. > > > > [DOT] How do decide whether it is worthwhile to spend time on CAR or not? > > If you have a TAR selection scheme that resides in the MN, it is fairly > > easy to do so. If your signal strength fades for instance too fast, you just > > skip CAR discovery and select one of the AR from which you receive a current > > beacon. But again, this is TAR selection and not within the scope of the problem. > > But if you choose to do CAR (wherever it is implemented), it will always add > > to your handover time since you have to run certain mechanisms. How this tradeoff > > can be determined is not clear to me and looks like an implementation issue in > > the entity that runs the TAR selection (which again use CAR discovery as an input). > > I agree. > > [DOT] Does the agreement mean that we shouldn't consider this requirement > for CAR discovery, since it is related to TAR selection? Exactly! It should be in the TAR requirements draft, if there ever will be one.. BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 09:34:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04238 for ; Tue, 26 Mar 2002 09:34:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27962; Tue, 26 Mar 2002 09:18:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27929 for ; Tue, 26 Mar 2002 09:18:12 -0500 (EST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03868 for ; Tue, 26 Mar 2002 09:18:08 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g2QEI6K09814; Tue, 26 Mar 2002 19:48:06 +0530 (IST) Received: from SATISHJ (pcz-satishj.sasken.com [10.1.36.146]) by sunrnd2.sasken.com (8.11.6/8.11.6) with SMTP id g2QEI4L09271; Tue, 26 Mar 2002 19:48:04 +0530 (IST) Message-ID: <009901c1d4d1$258b15d0$9224010a@SATISHJ> From: "Satish Jamadagni" To: "James Kempf" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> <018401c1d431$acf5cb00$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:48:48 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, > > The requirments already have a statement about capabilities. Is this > what you > mean? > The only thing I wanted to convey was that in the CAR discovery process varied set of capabilities (also reflects the context supporting capability) are exchanges at various times - Should not CT and CAR discovery be combined ( I dont know if some such discussion has happened earlier - if so please forgive me for bringing this again). One can exchange a macro level context support information as in the CT drafts during the GAARs and CARs stage - finally let the MN solicit a near complete set of Context support capabilities of the CARs to decide on a TAR - for all practical purposes the CT would have been achieved by the time a TAR is decided.. So in the requirements spec we should have a mandate to classify the so called context support capabilities into a hierarchy if possible (Such a thing has been initiated in the CT drafts) so that a varied level of information exchange can be initiated during the GAARs and CAR identification. For TAR the MN can then solicit the remaining set. > Are you talking about GPS co-ordinates or something? I don't see how the > MN could make use > of this information. MNs may not use that but the ARs can identify overlap radio coverage regions (for both vertical and horizontal seamless handover support) All it really needs to know is what options are > available at this point > in time for bringing up the interfaces it has. The L2 tags achieve this dont they - provided that initially the geographic coverage continuity of such an L2 has been verified by the AR. Within the scope of 3G ( and other L2s) UE positioning is very much supported (estimating the AR range can also be achieved) - Basically the actual geographic location information handling capacity is available at most emerging L2s - i.e. ARs tied to L2s can use the actual geographic location information to decide on GAARs - I guess by the time we see 3G deployments such services will also would have become equally available. This has the advantage of supporting mobile routers or at least doesnt have to be based on some static IDs(Then again PLEASE ignore this if you feel this is not in the immediate scope) Example of geo coordinatees in GAARs is that even if one were to use SLP for GAARs - I think the "scope" will have to carry some geographic radio coverage information. Please correct me if I am wrong. Regards, Satish Jamadagni ----- Original Message ----- From: "James Kempf" To: "Satish Jamadagni" ; "Eunsoo Shim" ; Sent: Tuesday, March 26, 2002 12:47 AM Subject: Re: [Seamoby] Examples of CAR discovery > > > We all agree that the CAR discovery protocol should assist in > identifying > > GAARs, arrive at CARs from GAARs and finally a TAR from the CARs. > Throughout > > Selecting a TAR is out of scope. > > > this process one can see that there will be varied level of > information > > exchange (context information basically). When identifying the GAARs > either > > the MN or the AR or a edge device needs to know the geographic > coverage of > > that AR (one can argue that more can be added at this stage itself). > Now > > Are you talking about GPS co-ordinates or something? I don't see how the > MN could make use > of this information. All it really needs to know is what options are > available at this point > in time for bringing up the interfaces it has. > > > from GAARs to CARs one would expect that the CAR discovery protocol > would > > provide more than just the geographic coverage. An exchange of a very > high > > level view of QoS or context support information between ARs (QoS and > > context types will have to be agreed upon for this) is what is > expected to > > arrive at a set of CARs - now till this stage the MN need not come > into play > > at all. The use of a MNs personal settings and preferences will come > into > > play at the stage of CARs to TAR. Usually (I dont know if in the > future > > classes of MNs can be identified and TARs selected for them as a > class) the > > TAR selection will be biased by the MN considerations - but then again > the > > MN might have prevelages with the AR so that the AR itself can achieve > this > > for a (or a class of) MNs. > > > > The requirments already have a statement about capabilities. Is this > what you > mean? > > > Also there should be provision for an AR to do a TAR selection given > the > > fact that the service provider can have policies that can force a > mobiles to > > handover due to load conditions, inorder to provide better QoS when > the load > > on other ARs or the underlying L2 becomes available (One of the most > > critical understanding of a 4G network is that there are a host of L2s > with > > a common IP layer and above) in the present understanding and spectrum > > sharing in future SDR scenarios (Please note that inter-technology > handover > > is where much in the understanding of future 4G and SDR networks - we > dont > > want our CAR protocol to undergo a lot of changes when the notion of > > seamless ness as required by a 4G or an SDR network hits the scene) . > > > > I disagree about allowing the AR to "force" a handover in > intertechnology situations. For intratechnology handover, I think there > is a case to be made for the AR to be involved in handover, for > performance reasons. For intertechnology, I think that a common > situation is that both networks are owned by different providers, and > even when they are owned by the same provider, the provider is more > likely to have tariff differences between them, for business purposes. > So the owner of the MN is likely to want to be involved in making the > decision. > > > The idea of a CAR discovery protocol SHOULD be to make available the > right > > amount of information at the right time for the GAARs to CARs to TAR > > process. The rest i.e. the exact selection of a subset of GAARs as > CARs and > > the selection of a TAR should be left open for people like us to make > a > > living by fitting algorithms in place. > > > > Right, that's why it is out of scope. > > > > > Also there were Qs like CAR being relavent in some scenarios - I think > we > > should not restrict ourselves to just the MN option - you never know > when > > the service providers would start offering that extra bit of > processing at > > the network level as a service differentiator - > > > > The MN is the only entity in a position to know if it has an interface > supporting a particular medium or not. How can the AR make the decision? > > > The MN is of course the king in the TAR selection, but he can have a > better > > understanding with his home network when the AR can do a TAR selection > for > > the MN considering the MNs very private settings too. The AR if bound > by a > > QoS policy might want a user to go to another specific AR with or > without an > > underlying L2 change at his bidding. > > > > With all the paging and solication protocols evolving there should > also be a > > provision for any AR to "entice" a MN into his domain - so to say > there > > should be provision for an AR to declare to an MN that he is the best > AR for > > the MN (target triggered case) - Of course how does the AR come to > know of > > the MN and his QoS settings - at some high level this is possible - > going > > lower and being sensitive to privacy issues - one will have to work > out the > > issues. > > > > ???? I don't understand this at all. "entice"? You mean like a coupon in > the newspaper giving you half off if you use this network on Monday or > something? > > My impression of current wireless service provider business models (and > what I can reasonably imagine them evolving to in the future) is that > this not realistic. > > But, really, we're not here to solve this kind of problem. We just need > to figure out how to provide the MN what it needs to achieve an > intertechnolgy handover, that is what "seamless" means. > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 09:34:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04247 for ; Tue, 26 Mar 2002 09:34:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02140 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 09:34:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27962; Tue, 26 Mar 2002 09:18:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27929 for ; Tue, 26 Mar 2002 09:18:12 -0500 (EST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03868 for ; Tue, 26 Mar 2002 09:18:08 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g2QEI6K09814; Tue, 26 Mar 2002 19:48:06 +0530 (IST) Received: from SATISHJ (pcz-satishj.sasken.com [10.1.36.146]) by sunrnd2.sasken.com (8.11.6/8.11.6) with SMTP id g2QEI4L09271; Tue, 26 Mar 2002 19:48:04 +0530 (IST) Message-ID: <009901c1d4d1$258b15d0$9224010a@SATISHJ> From: "Satish Jamadagni" To: "James Kempf" , References: <009701c1d395$b84a7600$356015ac@T23KEMPF> <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> <018401c1d431$acf5cb00$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:48:48 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi James, > > The requirments already have a statement about capabilities. Is this > what you > mean? > The only thing I wanted to convey was that in the CAR discovery process varied set of capabilities (also reflects the context supporting capability) are exchanges at various times - Should not CT and CAR discovery be combined ( I dont know if some such discussion has happened earlier - if so please forgive me for bringing this again). One can exchange a macro level context support information as in the CT drafts during the GAARs and CARs stage - finally let the MN solicit a near complete set of Context support capabilities of the CARs to decide on a TAR - for all practical purposes the CT would have been achieved by the time a TAR is decided.. So in the requirements spec we should have a mandate to classify the so called context support capabilities into a hierarchy if possible (Such a thing has been initiated in the CT drafts) so that a varied level of information exchange can be initiated during the GAARs and CAR identification. For TAR the MN can then solicit the remaining set. > Are you talking about GPS co-ordinates or something? I don't see how the > MN could make use > of this information. MNs may not use that but the ARs can identify overlap radio coverage regions (for both vertical and horizontal seamless handover support) All it really needs to know is what options are > available at this point > in time for bringing up the interfaces it has. The L2 tags achieve this dont they - provided that initially the geographic coverage continuity of such an L2 has been verified by the AR. Within the scope of 3G ( and other L2s) UE positioning is very much supported (estimating the AR range can also be achieved) - Basically the actual geographic location information handling capacity is available at most emerging L2s - i.e. ARs tied to L2s can use the actual geographic location information to decide on GAARs - I guess by the time we see 3G deployments such services will also would have become equally available. This has the advantage of supporting mobile routers or at least doesnt have to be based on some static IDs(Then again PLEASE ignore this if you feel this is not in the immediate scope) Example of geo coordinatees in GAARs is that even if one were to use SLP for GAARs - I think the "scope" will have to carry some geographic radio coverage information. Please correct me if I am wrong. Regards, Satish Jamadagni ----- Original Message ----- From: "James Kempf" To: "Satish Jamadagni" ; "Eunsoo Shim" ; Sent: Tuesday, March 26, 2002 12:47 AM Subject: Re: [Seamoby] Examples of CAR discovery > > > We all agree that the CAR discovery protocol should assist in > identifying > > GAARs, arrive at CARs from GAARs and finally a TAR from the CARs. > Throughout > > Selecting a TAR is out of scope. > > > this process one can see that there will be varied level of > information > > exchange (context information basically). When identifying the GAARs > either > > the MN or the AR or a edge device needs to know the geographic > coverage of > > that AR (one can argue that more can be added at this stage itself). > Now > > Are you talking about GPS co-ordinates or something? I don't see how the > MN could make use > of this information. All it really needs to know is what options are > available at this point > in time for bringing up the interfaces it has. > > > from GAARs to CARs one would expect that the CAR discovery protocol > would > > provide more than just the geographic coverage. An exchange of a very > high > > level view of QoS or context support information between ARs (QoS and > > context types will have to be agreed upon for this) is what is > expected to > > arrive at a set of CARs - now till this stage the MN need not come > into play > > at all. The use of a MNs personal settings and preferences will come > into > > play at the stage of CARs to TAR. Usually (I dont know if in the > future > > classes of MNs can be identified and TARs selected for them as a > class) the > > TAR selection will be biased by the MN considerations - but then again > the > > MN might have prevelages with the AR so that the AR itself can achieve > this > > for a (or a class of) MNs. > > > > The requirments already have a statement about capabilities. Is this > what you > mean? > > > Also there should be provision for an AR to do a TAR selection given > the > > fact that the service provider can have policies that can force a > mobiles to > > handover due to load conditions, inorder to provide better QoS when > the load > > on other ARs or the underlying L2 becomes available (One of the most > > critical understanding of a 4G network is that there are a host of L2s > with > > a common IP layer and above) in the present understanding and spectrum > > sharing in future SDR scenarios (Please note that inter-technology > handover > > is where much in the understanding of future 4G and SDR networks - we > dont > > want our CAR protocol to undergo a lot of changes when the notion of > > seamless ness as required by a 4G or an SDR network hits the scene) . > > > > I disagree about allowing the AR to "force" a handover in > intertechnology situations. For intratechnology handover, I think there > is a case to be made for the AR to be involved in handover, for > performance reasons. For intertechnology, I think that a common > situation is that both networks are owned by different providers, and > even when they are owned by the same provider, the provider is more > likely to have tariff differences between them, for business purposes. > So the owner of the MN is likely to want to be involved in making the > decision. > > > The idea of a CAR discovery protocol SHOULD be to make available the > right > > amount of information at the right time for the GAARs to CARs to TAR > > process. The rest i.e. the exact selection of a subset of GAARs as > CARs and > > the selection of a TAR should be left open for people like us to make > a > > living by fitting algorithms in place. > > > > Right, that's why it is out of scope. > > > > > Also there were Qs like CAR being relavent in some scenarios - I think > we > > should not restrict ourselves to just the MN option - you never know > when > > the service providers would start offering that extra bit of > processing at > > the network level as a service differentiator - > > > > The MN is the only entity in a position to know if it has an interface > supporting a particular medium or not. How can the AR make the decision? > > > The MN is of course the king in the TAR selection, but he can have a > better > > understanding with his home network when the AR can do a TAR selection > for > > the MN considering the MNs very private settings too. The AR if bound > by a > > QoS policy might want a user to go to another specific AR with or > without an > > underlying L2 change at his bidding. > > > > With all the paging and solication protocols evolving there should > also be a > > provision for any AR to "entice" a MN into his domain - so to say > there > > should be provision for an AR to declare to an MN that he is the best > AR for > > the MN (target triggered case) - Of course how does the AR come to > know of > > the MN and his QoS settings - at some high level this is possible - > going > > lower and being sensitive to privacy issues - one will have to work > out the > > issues. > > > > ???? I don't understand this at all. "entice"? You mean like a coupon in > the newspaper giving you half off if you use this network on Monday or > something? > > My impression of current wireless service provider business models (and > what I can reasonably imagine them evolving to in the future) is that > this not realistic. > > But, really, we're not here to solve this kind of problem. We just need > to figure out how to provide the MN what it needs to achieve an > intertechnolgy handover, that is what "seamless" means. > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 10:31:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06806 for ; Tue, 26 Mar 2002 10:31:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14344; Tue, 26 Mar 2002 10:17:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14311 for ; Tue, 26 Mar 2002 10:17:42 -0500 (EST) Received: from hotmail.com (f236.law7.hotmail.com [216.33.237.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05993 for ; Tue, 26 Mar 2002 10:17:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 07:17:11 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 15:17:11 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 15:17:11 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 15:17:11.0897 (UTC) FILETIME=[4DA89490:01C1D4D9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Satish: Some comments inline, marked as [HC]. >From: "Satish Jamadagni" >To: "James Kempf" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 19:48:48 +0530 > >Hi James, > > > > The requirments already have a statement about capabilities. Is this > > what you > > mean? > > >The only thing I wanted to convey was that in the CAR discovery process >varied set of capabilities (also reflects the context supporting >capability) >are exchanges at various times - Should not CT and CAR discovery be >combined >( I dont know if some such discussion has happened earlier - if so please >forgive me for bringing this again). One can exchange a macro level context >support information as in the CT drafts during the GAARs and CARs stage - >finally let the MN solicit a near complete set of Context support >capabilities of the CARs to decide on a TAR - for all practical purposes >the >CT would have been achieved by the time a TAR is decided.. > >So in the requirements spec we should have a mandate to classify the so >called context support capabilities into a hierarchy if possible (Such a >thing has been initiated in the CT drafts) so that a varied level of >information exchange can be initiated during the GAARs and CAR >identification. For TAR the MN can then solicit the remaining set. [HC] The requirement on the nature and formats of capabilities is still to be filled. Could you condense your thoughts above into text that may be useful for formulating such a requirement. > > > Are you talking about GPS co-ordinates or something? I don't see how the > > MN could make use > > of this information. > >MNs may not use that but the ARs can identify overlap radio coverage >regions >(for both vertical and horizontal seamless handover support) [HC] GPS may not be the best way to go about for identifying overlapping coverages. GPS can give co-ordinates of entities, not their coverages. The coverage patterns may vary based on environment, total power output at base station and so on. Also, that will be like going into solution space. Nonetheless, there is a consensus pending on the related requirement posted earlier which says: "It MUST/SHOULD be possible for an AR or an MN (depending upon solution scenario) to verify that some other AR is indeed a GAAR." Do you have a vote for or against this requrirement when you raise the above issue? BR, Hemant _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 10:31:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06815 for ; Tue, 26 Mar 2002 10:31:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18606 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 10:31:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14344; Tue, 26 Mar 2002 10:17:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14311 for ; Tue, 26 Mar 2002 10:17:42 -0500 (EST) Received: from hotmail.com (f236.law7.hotmail.com [216.33.237.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05993 for ; Tue, 26 Mar 2002 10:17:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 07:17:11 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 15:17:11 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 15:17:11 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 15:17:11.0897 (UTC) FILETIME=[4DA89490:01C1D4D9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Satish: Some comments inline, marked as [HC]. >From: "Satish Jamadagni" >To: "James Kempf" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 19:48:48 +0530 > >Hi James, > > > > The requirments already have a statement about capabilities. Is this > > what you > > mean? > > >The only thing I wanted to convey was that in the CAR discovery process >varied set of capabilities (also reflects the context supporting >capability) >are exchanges at various times - Should not CT and CAR discovery be >combined >( I dont know if some such discussion has happened earlier - if so please >forgive me for bringing this again). One can exchange a macro level context >support information as in the CT drafts during the GAARs and CARs stage - >finally let the MN solicit a near complete set of Context support >capabilities of the CARs to decide on a TAR - for all practical purposes >the >CT would have been achieved by the time a TAR is decided.. > >So in the requirements spec we should have a mandate to classify the so >called context support capabilities into a hierarchy if possible (Such a >thing has been initiated in the CT drafts) so that a varied level of >information exchange can be initiated during the GAARs and CAR >identification. For TAR the MN can then solicit the remaining set. [HC] The requirement on the nature and formats of capabilities is still to be filled. Could you condense your thoughts above into text that may be useful for formulating such a requirement. > > > Are you talking about GPS co-ordinates or something? I don't see how the > > MN could make use > > of this information. > >MNs may not use that but the ARs can identify overlap radio coverage >regions >(for both vertical and horizontal seamless handover support) [HC] GPS may not be the best way to go about for identifying overlapping coverages. GPS can give co-ordinates of entities, not their coverages. The coverage patterns may vary based on environment, total power output at base station and so on. Also, that will be like going into solution space. Nonetheless, there is a consensus pending on the related requirement posted earlier which says: "It MUST/SHOULD be possible for an AR or an MN (depending upon solution scenario) to verify that some other AR is indeed a GAAR." Do you have a vote for or against this requrirement when you raise the above issue? BR, Hemant _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 11:20:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09211 for ; Tue, 26 Mar 2002 11:20:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01259; Tue, 26 Mar 2002 11:14:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01227 for ; Tue, 26 Mar 2002 11:14:48 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08936 for ; Tue, 26 Mar 2002 11:14:44 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2QGEFI6000802; Tue, 26 Mar 2002 08:14:16 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn2-609.cisco.com [10.21.114.97]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACK81676; Tue, 26 Mar 2002 08:14:26 -0800 (PST) Message-Id: <4.3.2.7.2.20020326105443.02ce7a78@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Mar 2002 11:14:13 -0500 To: "James Kempf" , "Hemant Chaskar" , From: "Michael A. Ramalho" Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: <028201c1d448$5fb250e0$7e6015ac@T23KEMPF> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org At 01:59 PM 3/25/2002 -0800, James Kempf wrote: > > Just to be ultra clear - Luxury of two interfaces is not a generic > > assumption for CAR discovery problem formulation. Two-connection WLAN >card > > is good for 2 APs, but what if there are 3 or 4 or 5 APs. > > This may sound like a stupid statement for some .... but even a single WLAN card can scan during periods of (relative) inactivity to search for beacons of other APs. Given this ability/possibility (depends on how the drivers were written), one would assume that two cards are more than enough to search for the (next) highest signal quality AP it can authenticate (or get required QoS) on. Thus while maintaining an existing session on one card - you try to authenticate on the next best AP (in some sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE WLAN card may be possible in the future with "fast-retunable" WLAN cards - but it is clearly doable today with two cards. You only need to define heuristics for your MNs (e.g., default routes, etc.) to send the packets to/from the preferred association. So ... why exactly doesn't the two WLAN card case handle an arbitrary number of potential APs? >Does the MN have different interface cards for each or are they the >same? > > jak > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.732.449.5762 Cell: +1.732.809.0188 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 11:20:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09221 for ; Tue, 26 Mar 2002 11:20:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02945 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 11:20:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01259; Tue, 26 Mar 2002 11:14:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01227 for ; Tue, 26 Mar 2002 11:14:48 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08936 for ; Tue, 26 Mar 2002 11:14:44 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2QGEFI6000802; Tue, 26 Mar 2002 08:14:16 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn2-609.cisco.com [10.21.114.97]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACK81676; Tue, 26 Mar 2002 08:14:26 -0800 (PST) Message-Id: <4.3.2.7.2.20020326105443.02ce7a78@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Mar 2002 11:14:13 -0500 To: "James Kempf" , "Hemant Chaskar" , From: "Michael A. Ramalho" Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: <028201c1d448$5fb250e0$7e6015ac@T23KEMPF> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org At 01:59 PM 3/25/2002 -0800, James Kempf wrote: > > Just to be ultra clear - Luxury of two interfaces is not a generic > > assumption for CAR discovery problem formulation. Two-connection WLAN >card > > is good for 2 APs, but what if there are 3 or 4 or 5 APs. > > This may sound like a stupid statement for some .... but even a single WLAN card can scan during periods of (relative) inactivity to search for beacons of other APs. Given this ability/possibility (depends on how the drivers were written), one would assume that two cards are more than enough to search for the (next) highest signal quality AP it can authenticate (or get required QoS) on. Thus while maintaining an existing session on one card - you try to authenticate on the next best AP (in some sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE WLAN card may be possible in the future with "fast-retunable" WLAN cards - but it is clearly doable today with two cards. You only need to define heuristics for your MNs (e.g., default routes, etc.) to send the packets to/from the preferred association. So ... why exactly doesn't the two WLAN card case handle an arbitrary number of potential APs? >Does the MN have different interface cards for each or are they the >same? > > jak > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.732.449.5762 Cell: +1.732.809.0188 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 11:46:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11045 for ; Tue, 26 Mar 2002 11:46:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07113; Tue, 26 Mar 2002 11:35:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07073 for ; Tue, 26 Mar 2002 11:35:26 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10184 for ; Tue, 26 Mar 2002 11:35:22 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QGYtI01595; Tue, 26 Mar 2002 08:34:55 -0800 (PST) Message-ID: <001f01c1d4e3$efc58ad0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 08:33:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I prefer wording that specifically requires the MN to be involved in getting the CAR information. Thus: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. This is clear and unambiguous about what network entity is in control during an intertechnology handover. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Monday, March 25, 2002 9:32 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi: > > Some comments below: > > > >From: "James Kempf" > >To: "Eunsoo Shim" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > Please just let me remind you that the CAR discovery protocol also > >provides > > > mapping of L2 ID to IP address of the new AR which is necessary for > >the > > > low-latency handoff mechanism proposed in the MobileIP WG. So there is > >a > > > case CAR discovery is helpful for single technology handovers. > > > > > > >OK, so what you are saying is that there are two cases: > > > >1) Provding the MN with CAR information on what choices are available > >or, possibly, when the MN moves into an area where a new choice is > >possible, like moving into a hot spot area, for MNs that have multiple > >interfaces. > > > >2) Providing the AR with reverse address translation for CARs for MNs > >that have single interfaces and want fast handover support. > > > > >I agree. > > > >I don't get the feeling that these two cases are clearly delineated in > >the requirements. In fact, they seem to me like they are really two > >separate protocols. > > [HC] From the requirements perspective, what all the recent discussion is > about is probably the following requirement text (with supporting line that > CAR discovery is about comparing MN's requirements with GAAR capabilities > and slecting CARs from GAARs): > > "CAR discovery output MUST be retrievable, possibly selectively, by MN". > Also, I assume that there will the the following requirement as well (I > think that this was posted before IETF53 and I also saw some WG members > endorse it in IETF53 meeting): "MN requirements MUST be made available for > CAR discovery". > > This would mandate a CAR discovery functionality as follows: > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> MN > ^ > | > | > Capability information about GAARs > > Again, "CAR discovery module" can reside completely in MN, completely in AR > or combination depending upon environment, availability of multiplicity of > interfaces with MN etc. Further, the nature of MN requirements input and > corresponding output depends upon the environement in which CAR discovery is > being used. Also, whether the solution is organized into seperate protocols > or single protocol is a solution-specific aspect. > > (Note: The first requirement in requiremnet spec already says the address > translation part. We can keep it so given its importance for fast/seamless > handoffs, though it can be subsumed into above generic model (with "one > parameter = L2 id", "one capability information about GAARs = L2 to IP addr. > maps" and "output=IP address of CAR").) > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding your > > > question, couldn't we imagine a case when a network provider wants do > >a kind > > > of load-balancing between different access networks in the wireless > >overlay > > > network? > > > > > > >Sure, but I think that's a very special case. The more general case (and > >in fact, the case that is showing up *today*) is that one network > >provider owns one medium and the other another. Example: at the airport, > >the cellular provider owns the CDMA network and some WLAN provider owns > >the WLAN network. > > [HC]There is a concept of operator owned WLAN that is actually catching up. > Some systems are already rolled out in Europe if I am not mistaken. So, both > cases are very important - two media owned by two operators and two media > owned by single operator. > > BR, > Hemant > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 11:46:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11080 for ; Tue, 26 Mar 2002 11:46:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10600 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 11:46:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07113; Tue, 26 Mar 2002 11:35:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07073 for ; Tue, 26 Mar 2002 11:35:26 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10184 for ; Tue, 26 Mar 2002 11:35:22 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QGYtI01595; Tue, 26 Mar 2002 08:34:55 -0800 (PST) Message-ID: <001f01c1d4e3$efc58ad0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 08:33:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, I prefer wording that specifically requires the MN to be involved in getting the CAR information. Thus: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. This is clear and unambiguous about what network entity is in control during an intertechnology handover. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Monday, March 25, 2002 9:32 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi: > > Some comments below: > > > >From: "James Kempf" > >To: "Eunsoo Shim" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > Please just let me remind you that the CAR discovery protocol also > >provides > > > mapping of L2 ID to IP address of the new AR which is necessary for > >the > > > low-latency handoff mechanism proposed in the MobileIP WG. So there is > >a > > > case CAR discovery is helpful for single technology handovers. > > > > > > >OK, so what you are saying is that there are two cases: > > > >1) Provding the MN with CAR information on what choices are available > >or, possibly, when the MN moves into an area where a new choice is > >possible, like moving into a hot spot area, for MNs that have multiple > >interfaces. > > > >2) Providing the AR with reverse address translation for CARs for MNs > >that have single interfaces and want fast handover support. > > > > >I agree. > > > >I don't get the feeling that these two cases are clearly delineated in > >the requirements. In fact, they seem to me like they are really two > >separate protocols. > > [HC] From the requirements perspective, what all the recent discussion is > about is probably the following requirement text (with supporting line that > CAR discovery is about comparing MN's requirements with GAAR capabilities > and slecting CARs from GAARs): > > "CAR discovery output MUST be retrievable, possibly selectively, by MN". > Also, I assume that there will the the following requirement as well (I > think that this was posted before IETF53 and I also saw some WG members > endorse it in IETF53 meeting): "MN requirements MUST be made available for > CAR discovery". > > This would mandate a CAR discovery functionality as follows: > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> MN > ^ > | > | > Capability information about GAARs > > Again, "CAR discovery module" can reside completely in MN, completely in AR > or combination depending upon environment, availability of multiplicity of > interfaces with MN etc. Further, the nature of MN requirements input and > corresponding output depends upon the environement in which CAR discovery is > being used. Also, whether the solution is organized into seperate protocols > or single protocol is a solution-specific aspect. > > (Note: The first requirement in requiremnet spec already says the address > translation part. We can keep it so given its importance for fast/seamless > handoffs, though it can be subsumed into above generic model (with "one > parameter = L2 id", "one capability information about GAARs = L2 to IP addr. > maps" and "output=IP address of CAR").) > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding your > > > question, couldn't we imagine a case when a network provider wants do > >a kind > > > of load-balancing between different access networks in the wireless > >overlay > > > network? > > > > > > >Sure, but I think that's a very special case. The more general case (and > >in fact, the case that is showing up *today*) is that one network > >provider owns one medium and the other another. Example: at the airport, > >the cellular provider owns the CDMA network and some WLAN provider owns > >the WLAN network. > > [HC]There is a concept of operator owned WLAN that is actually catching up. > Some systems are already rolled out in Europe if I am not mistaken. So, both > cases are very important - two media owned by two operators and two media > owned by single operator. > > BR, > Hemant > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:04:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12587 for ; Tue, 26 Mar 2002 12:04:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14445; Tue, 26 Mar 2002 11:57:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14405 for ; Tue, 26 Mar 2002 11:57:52 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12081 for ; Tue, 26 Mar 2002 11:57:43 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QGvxs24931 for ; Tue, 26 Mar 2002 10:58:00 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Mar 2002 10:57:40 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 10:56:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Date: Tue, 26 Mar 2002 11:56:52 -0500 Message-ID: Thread-Topic: CAR discovery Thread-Index: AcHU5znwsrs8HjKETHeC1P92TPtbbA== To: X-OriginalArrivalTime: 26 Mar 2002 16:56:53.0298 (UTC) FILETIME=[3AD9F120:01C1D4E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14406 Subject: [Seamoby] CAR discovery Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi all, the recent discussion on CAR discovery gave me the impression that there is some disconnection regarding the scope of CAR discovery. You should keep in mind that CAR discovery is not dealing with final handover decisions, it merely determines a set of geographically adjacent access routers that satifies MN's requirements at the time of requesting this information. Whether to use this set of ARs or not for the final decision, is up to the algorithm that does that decision. Said algorithm is called TAR selection and is out of scope of the CAR discovery work. However, for the openness of implementing any kind of TAR selection schemes, the current requirements take care of this by demanding the usability of CAR information by others (see exact wording in the document). With that requirement, CAR discovery solutions must enable to implement ANY kind of TAR selection, whether AR- or MN-based. Hence, it does really not matter whether the final authority of selection is the MN or any other network-related entity, since this question is simply out of scope. Regarding the requirements for CAR discovery, we therefore should allow any kind of CAR discovery solutions as well, as long as they fulfill the basic job requirements, namely providing said set of CARs (under several constraints, such as preserving existing security models). Hence, any solution, either MN-based, AR-based, network-assisted, or whatever, should be feasible with the requirements, even though some people might not believe that certain solutions are possible or sufficient. Keep in mind that the best proof is the assessment of a provided solution. Hence, I still hope that the final requirements won't preclude certain solutions by demanding certain functionality to be located in certain entities. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:04:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12597 for ; Tue, 26 Mar 2002 12:04:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16601 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:04:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14445; Tue, 26 Mar 2002 11:57:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14405 for ; Tue, 26 Mar 2002 11:57:52 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12081 for ; Tue, 26 Mar 2002 11:57:43 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QGvxs24931 for ; Tue, 26 Mar 2002 10:58:00 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Mar 2002 10:57:40 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 10:56:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Date: Tue, 26 Mar 2002 11:56:52 -0500 Message-ID: Thread-Topic: CAR discovery Thread-Index: AcHU5znwsrs8HjKETHeC1P92TPtbbA== To: X-OriginalArrivalTime: 26 Mar 2002 16:56:53.0298 (UTC) FILETIME=[3AD9F120:01C1D4E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14406 Subject: [Seamoby] CAR discovery Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi all, the recent discussion on CAR discovery gave me the impression that there is some disconnection regarding the scope of CAR discovery. You should keep in mind that CAR discovery is not dealing with final handover decisions, it merely determines a set of geographically adjacent access routers that satifies MN's requirements at the time of requesting this information. Whether to use this set of ARs or not for the final decision, is up to the algorithm that does that decision. Said algorithm is called TAR selection and is out of scope of the CAR discovery work. However, for the openness of implementing any kind of TAR selection schemes, the current requirements take care of this by demanding the usability of CAR information by others (see exact wording in the document). With that requirement, CAR discovery solutions must enable to implement ANY kind of TAR selection, whether AR- or MN-based. Hence, it does really not matter whether the final authority of selection is the MN or any other network-related entity, since this question is simply out of scope. Regarding the requirements for CAR discovery, we therefore should allow any kind of CAR discovery solutions as well, as long as they fulfill the basic job requirements, namely providing said set of CARs (under several constraints, such as preserving existing security models). Hence, any solution, either MN-based, AR-based, network-assisted, or whatever, should be feasible with the requirements, even though some people might not believe that certain solutions are possible or sufficient. Keep in mind that the best proof is the assessment of a provided solution. Hence, I still hope that the final requirements won't preclude certain solutions by demanding certain functionality to be located in certain entities. Thanks, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:13:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13147 for ; Tue, 26 Mar 2002 12:13:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17640; Tue, 26 Mar 2002 12:07:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17596 for ; Tue, 26 Mar 2002 12:07:33 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12799 for ; Tue, 26 Mar 2002 12:07:29 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QH7Voq004612 for ; Tue, 26 Mar 2002 18:07:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Mar 26 18:07:26 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 17:57:19 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 18:07:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > "It MUST/SHOULD be possible for an AR or an MN (depending > upon solution > scenario) to verify that some other AR is indeed a GAAR." > => I think this statement will only make sense if you narrow the scope for the AR-AR protocol to only work within a small group of routers within the same access tech and belonging to the same operator. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:13:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13157 for ; Tue, 26 Mar 2002 12:13:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19409 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:13:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17640; Tue, 26 Mar 2002 12:07:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17596 for ; Tue, 26 Mar 2002 12:07:33 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12799 for ; Tue, 26 Mar 2002 12:07:29 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QH7Voq004612 for ; Tue, 26 Mar 2002 18:07:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Mar 26 18:07:26 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 17:57:19 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 18:07:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > "It MUST/SHOULD be possible for an AR or an MN (depending > upon solution > scenario) to verify that some other AR is indeed a GAAR." > => I think this statement will only make sense if you narrow the scope for the AR-AR protocol to only work within a small group of routers within the same access tech and belonging to the same operator. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:17:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13285 for ; Tue, 26 Mar 2002 12:17:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16590; Tue, 26 Mar 2002 12:04:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16554 for ; Tue, 26 Mar 2002 12:04:34 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12580 for ; Tue, 26 Mar 2002 12:04:30 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QH4WkY013341 for ; Tue, 26 Mar 2002 18:04:32 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Mar 26 18:04:32 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 18:02:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB79@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 18:04:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > the recent discussion on CAR discovery gave me the impression that > there is some disconnection regarding the scope of CAR discovery. > > You should keep in mind that CAR discovery is not dealing > with final handover > decisions, it merely determines a set of geographically > adjacent access routers that satifies MN's requirements at > the time of requesting this > information. Whether to use this set of ARs or not for the > final decision, > is up to the algorithm that does that decision. Said > algorithm is called > TAR selection and is out of scope of the CAR discovery work. => Which entity runs the TAR ?? This MUST NOT be out of scope. This *is* the issue here, you can't leave the definition so loose. > > However, for the openness of implementing any kind of TAR selection > schemes, the current requirements take care of this by demanding > the usability of CAR information by others (see exact wording in > the document). With that requirement, CAR discovery solutions must > enable to implement ANY kind of TAR selection, whether AR- or > MN-based. => There are different requirements for each case. I don't think we should go through this _again_. Steve presentation was very clear I think and most people agreed. Hence, it does really not matter whether the final > authority of selection is the MN or any other network-related > entity, since this question is simply out of scope. => Of course it does, the algorithm might be out of scope but NOT the entity running it. Are you seriously saying that the solutions is exactly the same regardless of who is running TAR?? Are you saying that my Cellular AR can locate my Starbucks AR just as easily as my MN can do it???? I hope not. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:17:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13295 for ; Tue, 26 Mar 2002 12:17:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20226 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:17:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16590; Tue, 26 Mar 2002 12:04:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16554 for ; Tue, 26 Mar 2002 12:04:34 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12580 for ; Tue, 26 Mar 2002 12:04:30 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QH4WkY013341 for ; Tue, 26 Mar 2002 18:04:32 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Mar 26 18:04:32 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 18:02:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB79@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 18:04:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > the recent discussion on CAR discovery gave me the impression that > there is some disconnection regarding the scope of CAR discovery. > > You should keep in mind that CAR discovery is not dealing > with final handover > decisions, it merely determines a set of geographically > adjacent access routers that satifies MN's requirements at > the time of requesting this > information. Whether to use this set of ARs or not for the > final decision, > is up to the algorithm that does that decision. Said > algorithm is called > TAR selection and is out of scope of the CAR discovery work. => Which entity runs the TAR ?? This MUST NOT be out of scope. This *is* the issue here, you can't leave the definition so loose. > > However, for the openness of implementing any kind of TAR selection > schemes, the current requirements take care of this by demanding > the usability of CAR information by others (see exact wording in > the document). With that requirement, CAR discovery solutions must > enable to implement ANY kind of TAR selection, whether AR- or > MN-based. => There are different requirements for each case. I don't think we should go through this _again_. Steve presentation was very clear I think and most people agreed. Hence, it does really not matter whether the final > authority of selection is the MN or any other network-related > entity, since this question is simply out of scope. => Of course it does, the algorithm might be out of scope but NOT the entity running it. Are you seriously saying that the solutions is exactly the same regardless of who is running TAR?? Are you saying that my Cellular AR can locate my Starbucks AR just as easily as my MN can do it???? I hope not. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:32:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14280 for ; Tue, 26 Mar 2002 12:32:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24196; Tue, 26 Mar 2002 12:29:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24157 for ; Tue, 26 Mar 2002 12:28:59 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13983 for ; Tue, 26 Mar 2002 12:28:56 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHSSI03033; Tue, 26 Mar 2002 09:28:28 -0800 (PST) Message-ID: <003501c1d4eb$6ab20820$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 09:26:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >The WLAN interface hands over the MN at Layer 2 if only WLAN is > >involved, even if the MN is doing the controlling. Why should CAR > >discovery be involved? > [Govind] I don't think my point came across clearly. In your mail > you had not mentioned the WLAN -> WLAN case at all which is considered > in FMIPv6 like L2 -> IP address translation. CAR discovery needs to be > involved if the MN has multiple options... esentially if the MN has to > choose the AR to handover to. I thought that was pretty clear. > We seem not to be connecting. The way handover works in WLAN is that the WLAN NIC selects one of the currently visible BSSIDs and sends a Reassociation message (or an Association message, the standard is not very clear). All this is happening at Layer 2. This is essentially no different than cellular. Now, depending on the software driver for the NIC, it is possible with some NICs to force handover to a particular BSSID. However, this is not part of the standard and so it is not supported on all cards. So I don't see much point in IETF developing a protocol for it. The upshot of this is that the IP stack has essentially no say in the matter about what AR the MN gets next, just like cellular. Once the link is established, however, the IP stack can perform an IPv6 Router Discovery to find out what routers are available. Alternatively, if the NIC card provides the IP stack with a L2 trigger containing the L2 address of the next access point prior to handover, the MN can perform FMIPv6 SolPrxyRtAdv to the current AR, providing it with the address. The current AR can use the L2 ->IP address mapping support provided by CAR discovery, do the HI/HAck, and return the result to the MN as PrxyRtAdv. Now, one could imagine a link layer in which there was a standardized way for the IP layer to force handover to a particular access point. This would still not require the AR to do the choosing. The CAR information provided from the AR to the MN can be used by the MN to make the choice. Why the MN would prefer one access point rather than another in an intratechnology handover situation has always been a mystery to me, but I do believe it could be supported. Thus, I don't see the intraWLAN case as supporting the need for the AR to make the decision either, though I am willing to concede that there is a possible use for CAR discovery in intratechnology handover if the L2 allows the IP layer to force handover. > > > > >The only place where I can see CAR discovery involved for a single > >technology handover is for reverse address translation, as in Eunsoo's > >note. > > > > [Govind] That CAR discovery is needed for reverse translation is quite > obvious from requirement 1 of the current requirement draft. I thought > that was the main idea behind the requirement. Anyways, my previous > mail was saying this too. > OK. > [Govind] I agree that the MN *must* be involved too. The main disconnect > between us is that you assume that the MN has no role whatsoever > if the handover is network controlled. Clearly, the handover can be > controlled by the network, i.e., tell the MN when to disconnect etc but > still take into account all of the MN's preferences. I don't understand > why we are having to get this point across too! So here is the basic disagreement: I don't see the point in a complicated protocol for the MN to "express its preferences" to the AR, when the AR can just hand over the CAR information to the MN and let the MN choose. >Regarding the MN > only knowing which interfaces are powered on. What big difference does > this make? It makes a big difference! If the interface isn't powered on and the AR says to the MN "handover to that interface," the MN has just lost network connectivity. Don't you agree? >If the network knows what interfaces the MN has then it can > advise it to power on at the appropriate time. If it is already powered > on the MN just discards this. If not it acts on it. If the card is not > inserted then it just discards the message too. What is the difficulty > that you see here. Maybe you can explain it. > Please explain to me why you want to do all this complex signaling between the network and the MN, when all that is required is to simply send the MN the list of CARs and have it do the selecting? What does all this complexity buy us? If we accept your proposal, then we are not just doing a CAR discovery protocol but also a protocol for having the MN tell the network what interfaces it has and what their current state is. This is just too complicated. The MN knows this stuff, given the right information, it can act on it accordingly without having to get the network involved. I simply don't see what adding this level of complexity buys us. > [Govind] Of course, this is an option, thats what Example 2 gives. There > are performance tradeoffs for each case that thats my main point. Your > contention is that any other approach is is infeasible which is not > agreeable to me. > I'm not saying it is infeasible, I'm saying that a rational engineering tradeoff between a complex protocol involving signaling MN interface state and one letting the MN simply make the choice itself seems, to me at least, to go in the direction of the latter. Can you explain to me what, exactly, sending the MN's interface state around buys us that we don't get by simply sending the CAR information to the MN and letting it make the choice? > > >The AAA exchange also might not be accurate. Suppose the MN is a laptop > >and the user forgot that day to put in their WLAN card. The AAA record > >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR > >could hand the MN over to a medium which the MN can't access. > > [Govind] I thought reachability information *from the MN *is part of TAR > selection process. If the MN's WLAN card is not inserted, how do you > suppose reachability for WLAN APs are got from the MN. So why do you think > the network will blindly just handover the MN to a WLAN network? > I don't understand your comment. If the WLAN card isn't in, the MN isn't going to initiate a MIP handover to an interface that is not there. Thus, if the MN is in control of an intertechnology handover, it won't disconnect. However, if the AR is in control of an intertechnology handover, how is it supposed to know that the card isn't there? From your comments above, I surmise you would like to see CAR discovery include a protocol for communicating the MN's current interface state: whether the card is there, whether it is powered on, etc., to the AR. My contention is that this is unnecessarily complex and having the MN control the handover would provide exactly the same functionality at much less protocol complexity cost. Perhaps I am missing something and there is some large benefit to adding this complexity that I do not see. If so, what is it? > >Right, so I am willing to concede that there is a place for reverse > >address translation to support fast handovers, but I don't see this > >fairly limited use in the requirements. I don't think this involves any > >capabilities, mobile node preferences, or any other complications of > >that sort. It is fairly simple. The Layer 2 trigger on the AR says that > >the MN is about to move to a new AP or AR and all that the Layer 2 > >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer 3 > >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > > [Govind] I don't understand your point. As I explained earlier, Requirement > 1 essentially deals with L2 to L3 mapping. Why doesn't MN's > preferences come into picture, if there are 10 APs connected to different > ARs with different capabilities, ofcourse the MN's preferences > come into picture. > I think we agree on this, Govind. Let's move on to where we don't. >The main point I'm making is that if there are multiple > APs available and the MN has to choose among them, then clearly > this has more power implications than just listening to the beacon and > passively forward it to a AR. > Like I said, the MN, at the IP layer, does not today get to choose in a single technology situation. A future L2 might have this capability, but I do not see why that means the AR must get involved. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:32:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14288 for ; Tue, 26 Mar 2002 12:32:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25313 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:32:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24196; Tue, 26 Mar 2002 12:29:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24157 for ; Tue, 26 Mar 2002 12:28:59 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13983 for ; Tue, 26 Mar 2002 12:28:56 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHSSI03033; Tue, 26 Mar 2002 09:28:28 -0800 (PST) Message-ID: <003501c1d4eb$6ab20820$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 09:26:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > >The WLAN interface hands over the MN at Layer 2 if only WLAN is > >involved, even if the MN is doing the controlling. Why should CAR > >discovery be involved? > [Govind] I don't think my point came across clearly. In your mail > you had not mentioned the WLAN -> WLAN case at all which is considered > in FMIPv6 like L2 -> IP address translation. CAR discovery needs to be > involved if the MN has multiple options... esentially if the MN has to > choose the AR to handover to. I thought that was pretty clear. > We seem not to be connecting. The way handover works in WLAN is that the WLAN NIC selects one of the currently visible BSSIDs and sends a Reassociation message (or an Association message, the standard is not very clear). All this is happening at Layer 2. This is essentially no different than cellular. Now, depending on the software driver for the NIC, it is possible with some NICs to force handover to a particular BSSID. However, this is not part of the standard and so it is not supported on all cards. So I don't see much point in IETF developing a protocol for it. The upshot of this is that the IP stack has essentially no say in the matter about what AR the MN gets next, just like cellular. Once the link is established, however, the IP stack can perform an IPv6 Router Discovery to find out what routers are available. Alternatively, if the NIC card provides the IP stack with a L2 trigger containing the L2 address of the next access point prior to handover, the MN can perform FMIPv6 SolPrxyRtAdv to the current AR, providing it with the address. The current AR can use the L2 ->IP address mapping support provided by CAR discovery, do the HI/HAck, and return the result to the MN as PrxyRtAdv. Now, one could imagine a link layer in which there was a standardized way for the IP layer to force handover to a particular access point. This would still not require the AR to do the choosing. The CAR information provided from the AR to the MN can be used by the MN to make the choice. Why the MN would prefer one access point rather than another in an intratechnology handover situation has always been a mystery to me, but I do believe it could be supported. Thus, I don't see the intraWLAN case as supporting the need for the AR to make the decision either, though I am willing to concede that there is a possible use for CAR discovery in intratechnology handover if the L2 allows the IP layer to force handover. > > > > >The only place where I can see CAR discovery involved for a single > >technology handover is for reverse address translation, as in Eunsoo's > >note. > > > > [Govind] That CAR discovery is needed for reverse translation is quite > obvious from requirement 1 of the current requirement draft. I thought > that was the main idea behind the requirement. Anyways, my previous > mail was saying this too. > OK. > [Govind] I agree that the MN *must* be involved too. The main disconnect > between us is that you assume that the MN has no role whatsoever > if the handover is network controlled. Clearly, the handover can be > controlled by the network, i.e., tell the MN when to disconnect etc but > still take into account all of the MN's preferences. I don't understand > why we are having to get this point across too! So here is the basic disagreement: I don't see the point in a complicated protocol for the MN to "express its preferences" to the AR, when the AR can just hand over the CAR information to the MN and let the MN choose. >Regarding the MN > only knowing which interfaces are powered on. What big difference does > this make? It makes a big difference! If the interface isn't powered on and the AR says to the MN "handover to that interface," the MN has just lost network connectivity. Don't you agree? >If the network knows what interfaces the MN has then it can > advise it to power on at the appropriate time. If it is already powered > on the MN just discards this. If not it acts on it. If the card is not > inserted then it just discards the message too. What is the difficulty > that you see here. Maybe you can explain it. > Please explain to me why you want to do all this complex signaling between the network and the MN, when all that is required is to simply send the MN the list of CARs and have it do the selecting? What does all this complexity buy us? If we accept your proposal, then we are not just doing a CAR discovery protocol but also a protocol for having the MN tell the network what interfaces it has and what their current state is. This is just too complicated. The MN knows this stuff, given the right information, it can act on it accordingly without having to get the network involved. I simply don't see what adding this level of complexity buys us. > [Govind] Of course, this is an option, thats what Example 2 gives. There > are performance tradeoffs for each case that thats my main point. Your > contention is that any other approach is is infeasible which is not > agreeable to me. > I'm not saying it is infeasible, I'm saying that a rational engineering tradeoff between a complex protocol involving signaling MN interface state and one letting the MN simply make the choice itself seems, to me at least, to go in the direction of the latter. Can you explain to me what, exactly, sending the MN's interface state around buys us that we don't get by simply sending the CAR information to the MN and letting it make the choice? > > >The AAA exchange also might not be accurate. Suppose the MN is a laptop > >and the user forgot that day to put in their WLAN card. The AAA record > >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR > >could hand the MN over to a medium which the MN can't access. > > [Govind] I thought reachability information *from the MN *is part of TAR > selection process. If the MN's WLAN card is not inserted, how do you > suppose reachability for WLAN APs are got from the MN. So why do you think > the network will blindly just handover the MN to a WLAN network? > I don't understand your comment. If the WLAN card isn't in, the MN isn't going to initiate a MIP handover to an interface that is not there. Thus, if the MN is in control of an intertechnology handover, it won't disconnect. However, if the AR is in control of an intertechnology handover, how is it supposed to know that the card isn't there? From your comments above, I surmise you would like to see CAR discovery include a protocol for communicating the MN's current interface state: whether the card is there, whether it is powered on, etc., to the AR. My contention is that this is unnecessarily complex and having the MN control the handover would provide exactly the same functionality at much less protocol complexity cost. Perhaps I am missing something and there is some large benefit to adding this complexity that I do not see. If so, what is it? > >Right, so I am willing to concede that there is a place for reverse > >address translation to support fast handovers, but I don't see this > >fairly limited use in the requirements. I don't think this involves any > >capabilities, mobile node preferences, or any other complications of > >that sort. It is fairly simple. The Layer 2 trigger on the AR says that > >the MN is about to move to a new AP or AR and all that the Layer 2 > >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer 3 > >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > > [Govind] I don't understand your point. As I explained earlier, Requirement > 1 essentially deals with L2 to L3 mapping. Why doesn't MN's > preferences come into picture, if there are 10 APs connected to different > ARs with different capabilities, ofcourse the MN's preferences > come into picture. > I think we agree on this, Govind. Let's move on to where we don't. >The main point I'm making is that if there are multiple > APs available and the MN has to choose among them, then clearly > this has more power implications than just listening to the beacon and > passively forward it to a AR. > Like I said, the MN, at the IP layer, does not today get to choose in a single technology situation. A future L2 might have this capability, but I do not see why that means the AR must get involved. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:35:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14357 for ; Tue, 26 Mar 2002 12:35:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22577; Tue, 26 Mar 2002 12:23:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22536 for ; Tue, 26 Mar 2002 12:23:29 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13641 for ; Tue, 26 Mar 2002 12:23:24 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QHNjs26893 for ; Tue, 26 Mar 2002 11:23:45 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Mar 2002 11:23:26 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 11:22:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:22:31 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHU5oo1f3wzmcK8ThmYCpDSHXRm/AAAMxCZ To: , , X-OriginalArrivalTime: 26 Mar 2002 17:22:32.0589 (UTC) FILETIME=[D0571BD0:01C1D4EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA22539 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, I prefer wording that specifically requires the MN to be involved in getting the CAR information. Thus: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. [DOT] We currently have a requirement stating the usability of information. The question though is whether your requirement for instance in a network-assisted approach would mean that the current AR has to send the entire list of GAARs with capabilities to the MN or that the MN should be able to request this information. The former one looks terribly inefficient to me when it comes to larger capability sets. The latter one is providing-on-request. As I said this is already in the requirements in terms of usability of information. This is clear and unambiguous about what network entity is in control during an intertechnology handover. [DOT] Again as a reminder, TAR selection is not within the scope of CAR discovery, so it should be possible to implement ANY kind of TAR selection. Whether in your model, the MN is 'in control' or 'in charge' doesn't really matter as long as we don't define TAR selection as being in scope, and therefore as to be addressed. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:35:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14366 for ; Tue, 26 Mar 2002 12:35:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25995 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:35:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22577; Tue, 26 Mar 2002 12:23:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22536 for ; Tue, 26 Mar 2002 12:23:29 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13641 for ; Tue, 26 Mar 2002 12:23:24 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QHNjs26893 for ; Tue, 26 Mar 2002 11:23:45 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Mar 2002 11:23:26 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Mar 2002 11:22:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:22:31 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHU5oo1f3wzmcK8ThmYCpDSHXRm/AAAMxCZ To: , , X-OriginalArrivalTime: 26 Mar 2002 17:22:32.0589 (UTC) FILETIME=[D0571BD0:01C1D4EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA22539 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, I prefer wording that specifically requires the MN to be involved in getting the CAR information. Thus: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. [DOT] We currently have a requirement stating the usability of information. The question though is whether your requirement for instance in a network-assisted approach would mean that the current AR has to send the entire list of GAARs with capabilities to the MN or that the MN should be able to request this information. The former one looks terribly inefficient to me when it comes to larger capability sets. The latter one is providing-on-request. As I said this is already in the requirements in terms of usability of information. This is clear and unambiguous about what network entity is in control during an intertechnology handover. [DOT] Again as a reminder, TAR selection is not within the scope of CAR discovery, so it should be possible to implement ANY kind of TAR selection. Whether in your model, the MN is 'in control' or 'in charge' doesn't really matter as long as we don't define TAR selection as being in scope, and therefore as to be addressed. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:36:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14463 for ; Tue, 26 Mar 2002 12:36:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26439 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:36:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21434; Tue, 26 Mar 2002 12:19:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21349 for ; Tue, 26 Mar 2002 12:19:40 -0500 (EST) Received: from hotmail.com (f126.law7.hotmail.com [216.33.237.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13505 for ; Tue, 26 Mar 2002 12:19:34 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:19:07 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:19:07 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:19:07 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:19:07.0707 (UTC) FILETIME=[563898B0:01C1D4EA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: This looks good to me, but with a small attention to detail: What if MN does not want to receive such information or does not want to receive a part of it. Then, CAR discovery should not blast it on MN. To avoid this, we can slightly rephrase it as: "The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities, *whenever and as required by MN*." BR, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 08:33:18 -0800 > >Hemant, > >I prefer wording that specifically requires the MN to be involved in >getting the CAR information. Thus: > > The CAR discovery protocol MUST provide the MN with GAAR >information, along with capabilities. > >This is clear and unambiguous about what network entity is in control >during an intertechnology handover. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: >Sent: Monday, March 25, 2002 9:32 PM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi: > > > > Some comments below: > > > > > > >From: "James Kempf" > > >To: "Eunsoo Shim" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > > > Please just let me remind you that the CAR discovery protocol also > > >provides > > > > mapping of L2 ID to IP address of the new AR which is necessary >for > > >the > > > > low-latency handoff mechanism proposed in the MobileIP WG. So >there is > > >a > > > > case CAR discovery is helpful for single technology handovers. > > > > > > > > > >OK, so what you are saying is that there are two cases: > > > > > >1) Provding the MN with CAR information on what choices are available > > >or, possibly, when the MN moves into an area where a new choice is > > >possible, like moving into a hot spot area, for MNs that have >multiple > > >interfaces. > > > > > >2) Providing the AR with reverse address translation for CARs for MNs > > >that have single interfaces and want fast handover support. > > > > > > > >I agree. > > > > > >I don't get the feeling that these two cases are clearly delineated >in > > >the requirements. In fact, they seem to me like they are really two > > >separate protocols. > > > > [HC] From the requirements perspective, what all the recent discussion >is > > about is probably the following requirement text (with supporting line >that > > CAR discovery is about comparing MN's requirements with GAAR >capabilities > > and slecting CARs from GAARs): > > > > "CAR discovery output MUST be retrievable, possibly selectively, by >MN". > > Also, I assume that there will the the following requirement as well >(I > > think that this was posted before IETF53 and I also saw some WG >members > > endorse it in IETF53 meeting): "MN requirements MUST be made available >for > > CAR discovery". > > > > This would mandate a CAR discovery functionality as follows: > > > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> >MN > > ^ > > | > > | > > Capability information about GAARs > > > > Again, "CAR discovery module" can reside completely in MN, completely >in AR > > or combination depending upon environment, availability of >multiplicity of > > interfaces with MN etc. Further, the nature of MN requirements input >and > > corresponding output depends upon the environement in which CAR >discovery is > > being used. Also, whether the solution is organized into seperate >protocols > > or single protocol is a solution-specific aspect. > > > > (Note: The first requirement in requiremnet spec already says the >address > > translation part. We can keep it so given its importance for >fast/seamless > > handoffs, though it can be subsumed into above generic model (with >"one > > parameter = L2 id", "one capability information about GAARs = L2 to IP >addr. > > maps" and "output=IP address of CAR").) > > > > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding >your > > > > question, couldn't we imagine a case when a network provider wants >do > > >a kind > > > > of load-balancing between different access networks in the >wireless > > >overlay > > > > network? > > > > > > > > > >Sure, but I think that's a very special case. The more general case >(and > > >in fact, the case that is showing up *today*) is that one network > > >provider owns one medium and the other another. Example: at the >airport, > > >the cellular provider owns the CDMA network and some WLAN provider >owns > > >the WLAN network. > > > > [HC]There is a concept of operator owned WLAN that is actually >catching up. > > Some systems are already rolled out in Europe if I am not mistaken. >So, both > > cases are very important - two media owned by two operators and two >media > > owned by single operator. > > > > BR, > > Hemant > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:36:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14451 for ; Tue, 26 Mar 2002 12:36:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21434; Tue, 26 Mar 2002 12:19:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21349 for ; Tue, 26 Mar 2002 12:19:40 -0500 (EST) Received: from hotmail.com (f126.law7.hotmail.com [216.33.237.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13505 for ; Tue, 26 Mar 2002 12:19:34 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:19:07 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:19:07 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:19:07 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:19:07.0707 (UTC) FILETIME=[563898B0:01C1D4EA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: This looks good to me, but with a small attention to detail: What if MN does not want to receive such information or does not want to receive a part of it. Then, CAR discovery should not blast it on MN. To avoid this, we can slightly rephrase it as: "The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities, *whenever and as required by MN*." BR, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 08:33:18 -0800 > >Hemant, > >I prefer wording that specifically requires the MN to be involved in >getting the CAR information. Thus: > > The CAR discovery protocol MUST provide the MN with GAAR >information, along with capabilities. > >This is clear and unambiguous about what network entity is in control >during an intertechnology handover. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: >Sent: Monday, March 25, 2002 9:32 PM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi: > > > > Some comments below: > > > > > > >From: "James Kempf" > > >To: "Eunsoo Shim" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > > > Please just let me remind you that the CAR discovery protocol also > > >provides > > > > mapping of L2 ID to IP address of the new AR which is necessary >for > > >the > > > > low-latency handoff mechanism proposed in the MobileIP WG. So >there is > > >a > > > > case CAR discovery is helpful for single technology handovers. > > > > > > > > > >OK, so what you are saying is that there are two cases: > > > > > >1) Provding the MN with CAR information on what choices are available > > >or, possibly, when the MN moves into an area where a new choice is > > >possible, like moving into a hot spot area, for MNs that have >multiple > > >interfaces. > > > > > >2) Providing the AR with reverse address translation for CARs for MNs > > >that have single interfaces and want fast handover support. > > > > > > > >I agree. > > > > > >I don't get the feeling that these two cases are clearly delineated >in > > >the requirements. In fact, they seem to me like they are really two > > >separate protocols. > > > > [HC] From the requirements perspective, what all the recent discussion >is > > about is probably the following requirement text (with supporting line >that > > CAR discovery is about comparing MN's requirements with GAAR >capabilities > > and slecting CARs from GAARs): > > > > "CAR discovery output MUST be retrievable, possibly selectively, by >MN". > > Also, I assume that there will the the following requirement as well >(I > > think that this was posted before IETF53 and I also saw some WG >members > > endorse it in IETF53 meeting): "MN requirements MUST be made available >for > > CAR discovery". > > > > This would mandate a CAR discovery functionality as follows: > > > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> >MN > > ^ > > | > > | > > Capability information about GAARs > > > > Again, "CAR discovery module" can reside completely in MN, completely >in AR > > or combination depending upon environment, availability of >multiplicity of > > interfaces with MN etc. Further, the nature of MN requirements input >and > > corresponding output depends upon the environement in which CAR >discovery is > > being used. Also, whether the solution is organized into seperate >protocols > > or single protocol is a solution-specific aspect. > > > > (Note: The first requirement in requiremnet spec already says the >address > > translation part. We can keep it so given its importance for >fast/seamless > > handoffs, though it can be subsumed into above generic model (with >"one > > parameter = L2 id", "one capability information about GAARs = L2 to IP >addr. > > maps" and "output=IP address of CAR").) > > > > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding >your > > > > question, couldn't we imagine a case when a network provider wants >do > > >a kind > > > > of load-balancing between different access networks in the >wireless > > >overlay > > > > network? > > > > > > > > > >Sure, but I think that's a very special case. The more general case >(and > > >in fact, the case that is showing up *today*) is that one network > > >provider owns one medium and the other another. Example: at the >airport, > > >the cellular provider owns the CDMA network and some WLAN provider >owns > > >the WLAN network. > > > > [HC]There is a concept of operator owned WLAN that is actually >catching up. > > Some systems are already rolled out in Europe if I am not mistaken. >So, both > > cases are very important - two media owned by two operators and two >media > > owned by single operator. > > > > BR, > > Hemant > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:40:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14880 for ; Tue, 26 Mar 2002 12:40:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26967; Tue, 26 Mar 2002 12:37:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26895 for ; Tue, 26 Mar 2002 12:37:45 -0500 (EST) Received: from hotmail.com (f134.law7.hotmail.com [216.33.237.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14612 for ; Tue, 26 Mar 2002 12:37:43 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:37:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:37:14 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Tue, 26 Mar 2002 17:37:14 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:37:14.0908 (UTC) FILETIME=[DE3E4DC0:01C1D4EC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: I think the main discussion issue that resulted in this email was: What is the cost of scanning APs on other connection (this involves link establishment, authentication as you said, obtaining IP address, receiving capabilities). Note that, all this work (and associated power) will be wasted if the user does not like the capabilites at the end of day. Please let us know if you think this to be a relevant consideration at all. Please ignore my comment about 3 or more APs. Hemant >From: "Michael A. Ramalho" >To: "James Kempf" , "Hemant Chaskar" >, >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Tue, 26 Mar 2002 11:14:13 -0500 > >At 01:59 PM 3/25/2002 -0800, James Kempf wrote: > >> > Just to be ultra clear - Luxury of two interfaces is not a generic >> > assumption for CAR discovery problem formulation. Two-connection WLAN >>card >> > is good for 2 APs, but what if there are 3 or 4 or 5 APs. >> > > >This may sound like a stupid statement for some .... but even a single >WLAN card can scan during periods of (relative) inactivity to search for >beacons of other APs. > >Given this ability/possibility (depends on how the drivers were written), >one would assume that two cards are more than enough to search >for the (next) highest signal quality AP it can authenticate (or get >required QoS) on. Thus while maintaining an existing session >on one card - you try to authenticate on the next best AP (in some >sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE >WLAN card may be possible in the future with "fast-retunable" WLAN >cards - but it is clearly doable today with two cards. You only need >to define heuristics for your MNs (e.g., default routes, etc.) to send >the packets to/from the preferred association. > >So ... why exactly doesn't the two WLAN card case handle an >arbitrary number of potential APs? > > >>Does the MN have different interface cards for each or are they the >>same? >> >> jak >> >> >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >Michael A. Ramalho, Ph.D. >Office email: mramalho@cisco.com >Personal email: mar42@cornell.edu >Office: +1.732.449.5762 >Cell: +1.732.809.0188 > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:40:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14888 for ; Tue, 26 Mar 2002 12:40:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27990 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:40:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26967; Tue, 26 Mar 2002 12:37:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26895 for ; Tue, 26 Mar 2002 12:37:45 -0500 (EST) Received: from hotmail.com (f134.law7.hotmail.com [216.33.237.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14612 for ; Tue, 26 Mar 2002 12:37:43 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:37:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:37:14 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Tue, 26 Mar 2002 17:37:14 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:37:14.0908 (UTC) FILETIME=[DE3E4DC0:01C1D4EC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: I think the main discussion issue that resulted in this email was: What is the cost of scanning APs on other connection (this involves link establishment, authentication as you said, obtaining IP address, receiving capabilities). Note that, all this work (and associated power) will be wasted if the user does not like the capabilites at the end of day. Please let us know if you think this to be a relevant consideration at all. Please ignore my comment about 3 or more APs. Hemant >From: "Michael A. Ramalho" >To: "James Kempf" , "Hemant Chaskar" >, >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Tue, 26 Mar 2002 11:14:13 -0500 > >At 01:59 PM 3/25/2002 -0800, James Kempf wrote: > >> > Just to be ultra clear - Luxury of two interfaces is not a generic >> > assumption for CAR discovery problem formulation. Two-connection WLAN >>card >> > is good for 2 APs, but what if there are 3 or 4 or 5 APs. >> > > >This may sound like a stupid statement for some .... but even a single >WLAN card can scan during periods of (relative) inactivity to search for >beacons of other APs. > >Given this ability/possibility (depends on how the drivers were written), >one would assume that two cards are more than enough to search >for the (next) highest signal quality AP it can authenticate (or get >required QoS) on. Thus while maintaining an existing session >on one card - you try to authenticate on the next best AP (in some >sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE >WLAN card may be possible in the future with "fast-retunable" WLAN >cards - but it is clearly doable today with two cards. You only need >to define heuristics for your MNs (e.g., default routes, etc.) to send >the packets to/from the preferred association. > >So ... why exactly doesn't the two WLAN card case handle an >arbitrary number of potential APs? > > >>Does the MN have different interface cards for each or are they the >>same? >> >> jak >> >> >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >Michael A. Ramalho, Ph.D. >Office email: mramalho@cisco.com >Personal email: mar42@cornell.edu >Office: +1.732.449.5762 >Cell: +1.732.809.0188 > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:42:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15167 for ; Tue, 26 Mar 2002 12:42:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25464; Tue, 26 Mar 2002 12:33:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25419 for ; Tue, 26 Mar 2002 12:33:08 -0500 (EST) Received: from hotmail.com (f161.law9.hotmail.com [64.4.9.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14309 for ; Tue, 26 Mar 2002 12:33:06 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:32:37 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:32:37 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 12:32:37 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:32:37.0961 (UTC) FILETIME=[392B8B90:01C1D4EC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Just a couple of quick clarifications to understand your point better. Regards, Govind. >=> Which entity runs the TAR ?? This MUST NOT >be out of scope. This *is* the issue here, you >can't leave the definition so loose. [Govind] Hmm, Could you clarify this a little more on this for me. Are you saying that the CAR discovery process which ends before TAR selection starts, is affected by where the TAR selection process resides. I agree that the CAR discovery output must be fed as an input to TAR selection. Wouldn't doing that be enough? Just for clarification. See the explanation of my concern later in this email. > > > > > However, for the openness of implementing any kind of TAR selection > > schemes, the current requirements take care of this by demanding > > the usability of CAR information by others (see exact wording in > > the document). With that requirement, CAR discovery solutions must > > enable to implement ANY kind of TAR selection, whether AR- or > > MN-based. > >=> There are different requirements for each case. >I don't think we should go through this _again_. >Steve presentation was very clear I think and most >people agreed. > [Govind]I agree that based on whether CAR discovery is performed at the AR or MN, some of the current requirements have to be re-worded to remove any pro-AR bias. Therefore I agree that for example the first requirement can become in some sense: MUST find IP addresses of GAARs (in pseudo code) if [L2 becaons received as input] then map to appropriate GAAR IP address; /* how the mapping is done is particular to the solution */ else Find IP address; /* How the IP address is found is particular to the solution */ wouldn't that cover the case you have in mind. However, this does not talk about TAR selection at all. First the MN (in your case) must get capabilities. If there are any other L2 beacons in the area maybe it has to repeat the same process there too. Once its done with the L2 becons (how many the MN chooses to look at is the MN's business) CAR discovery ends. The MN passes on the information to the TAR selection process (which probably in your case resides in the MN) to make the final decision right? But what has the original requirement have to do with the process of delivering the output of CAR discovery to the TAR selection process? As an example, the MN could push the output to the AR to make the final decision and still the original requirement holds good is it not? I agree that a requirement is needed that the CAR discovery process MUST have provisions to feed its output to the TAR selection process. Will this additional requirement satisfy your concerns? _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:42:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15178 for ; Tue, 26 Mar 2002 12:42:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28695 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:42:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25464; Tue, 26 Mar 2002 12:33:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25419 for ; Tue, 26 Mar 2002 12:33:08 -0500 (EST) Received: from hotmail.com (f161.law9.hotmail.com [64.4.9.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14309 for ; Tue, 26 Mar 2002 12:33:06 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:32:37 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:32:37 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 12:32:37 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:32:37.0961 (UTC) FILETIME=[392B8B90:01C1D4EC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, Just a couple of quick clarifications to understand your point better. Regards, Govind. >=> Which entity runs the TAR ?? This MUST NOT >be out of scope. This *is* the issue here, you >can't leave the definition so loose. [Govind] Hmm, Could you clarify this a little more on this for me. Are you saying that the CAR discovery process which ends before TAR selection starts, is affected by where the TAR selection process resides. I agree that the CAR discovery output must be fed as an input to TAR selection. Wouldn't doing that be enough? Just for clarification. See the explanation of my concern later in this email. > > > > > However, for the openness of implementing any kind of TAR selection > > schemes, the current requirements take care of this by demanding > > the usability of CAR information by others (see exact wording in > > the document). With that requirement, CAR discovery solutions must > > enable to implement ANY kind of TAR selection, whether AR- or > > MN-based. > >=> There are different requirements for each case. >I don't think we should go through this _again_. >Steve presentation was very clear I think and most >people agreed. > [Govind]I agree that based on whether CAR discovery is performed at the AR or MN, some of the current requirements have to be re-worded to remove any pro-AR bias. Therefore I agree that for example the first requirement can become in some sense: MUST find IP addresses of GAARs (in pseudo code) if [L2 becaons received as input] then map to appropriate GAAR IP address; /* how the mapping is done is particular to the solution */ else Find IP address; /* How the IP address is found is particular to the solution */ wouldn't that cover the case you have in mind. However, this does not talk about TAR selection at all. First the MN (in your case) must get capabilities. If there are any other L2 beacons in the area maybe it has to repeat the same process there too. Once its done with the L2 becons (how many the MN chooses to look at is the MN's business) CAR discovery ends. The MN passes on the information to the TAR selection process (which probably in your case resides in the MN) to make the final decision right? But what has the original requirement have to do with the process of delivering the output of CAR discovery to the TAR selection process? As an example, the MN could push the output to the AR to make the final decision and still the original requirement holds good is it not? I agree that a requirement is needed that the CAR discovery process MUST have provisions to feed its output to the TAR selection process. Will this additional requirement satisfy your concerns? _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:44:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15360 for ; Tue, 26 Mar 2002 12:44:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23294; Tue, 26 Mar 2002 12:26:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23224 for ; Tue, 26 Mar 2002 12:26:09 -0500 (EST) Received: from hotmail.com (f184.law7.hotmail.com [216.33.237.184]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13814 for ; Tue, 26 Mar 2002 12:26:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:25:38 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:25:38 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:25:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:25:38.0336 (UTC) FILETIME=[3F0DDA00:01C1D4EB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: I do not think so. There are ways to use Geospace information to do this for inter-tech and inter-admin handovers as well. But I do not want to talk about solutions now. The issue is, whether this requirement is MAY/SHOULD/MUST or REMOVE, from the protocol functionality perspective. Hemant >From: "Hesham Soliman (ERA)" >To: "'Hemant Chaskar'" , seamoby@ietf.org >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 18:07:24 +0100 > > > "It MUST/SHOULD be possible for an AR or an MN (depending > > upon solution > > scenario) to verify that some other AR is indeed a GAAR." > > > >=> I think this statement will only make sense >if you narrow the scope for the AR-AR protocol >to only work within a small group of routers >within the same access tech and belonging to >the same operator. > >Hesham > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:44:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15370 for ; Tue, 26 Mar 2002 12:44:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29225 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:44:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23294; Tue, 26 Mar 2002 12:26:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23224 for ; Tue, 26 Mar 2002 12:26:09 -0500 (EST) Received: from hotmail.com (f184.law7.hotmail.com [216.33.237.184]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13814 for ; Tue, 26 Mar 2002 12:26:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 09:25:38 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 17:25:38 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:25:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 17:25:38.0336 (UTC) FILETIME=[3F0DDA00:01C1D4EB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: I do not think so. There are ways to use Geospace information to do this for inter-tech and inter-admin handovers as well. But I do not want to talk about solutions now. The issue is, whether this requirement is MAY/SHOULD/MUST or REMOVE, from the protocol functionality perspective. Hemant >From: "Hesham Soliman (ERA)" >To: "'Hemant Chaskar'" , seamoby@ietf.org >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 18:07:24 +0100 > > > "It MUST/SHOULD be possible for an AR or an MN (depending > > upon solution > > scenario) to verify that some other AR is indeed a GAAR." > > > >=> I think this statement will only make sense >if you narrow the scope for the AR-AR protocol >to only work within a small group of routers >within the same access tech and belonging to >the same operator. > >Hesham > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:46:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15571 for ; Tue, 26 Mar 2002 12:46:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25590; Tue, 26 Mar 2002 12:33:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25546 for ; Tue, 26 Mar 2002 12:33:23 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14316 for ; Tue, 26 Mar 2002 12:33:20 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHWpI03146; Tue, 26 Mar 2002 09:32:51 -0800 (PST) Message-ID: <004101c1d4ec$07b000f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Tue, 26 Mar 2002 09:31:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, The requirements are supposed to constrain the solution in a particular direction. Constraining CAR discovery to avoid complex protocols for communication of the MN's interface card state to the network is an example. Can you articulate why such a solution is so much better than having the MN decide based on the CAR discovery information that we should continue to consider it? jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Monday, March 25, 2002 2:11 PM Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case > > > > James, > > >I can't see how the AR can know how many interfaces the MN has. On any > >particular day, there may be two or only one, or maybe even none if the > >user forgot all her interface cards. > [Govind] Well this information can be kept as part of the MN's profile. But > I am sure there are other ways to do it. As I explained in the previous > mail, I don't see why the MN's forgetting to power on a interface card or > forget inserting is such a big deal. Again, I am not > advocating that this is the way to do it. All I am saying is that > we shouldn't say that this isn't possible at this stage when we are just > considering requirements. > > > > >The AR won't do the waking, the MN will. That is, if the MN is getting > >traffic on one interface, it will get the CAR information on that > >interface, then the MN will make the decision about whether to power up > >the other interface. > >How can the AR wake the MN on an interface that doesn't have any power, > >much less IP service? > > [Govind] Ofcourse, the MN will do the waking, but the AR can help it wake up > selectively as opposed to the MN periodically waking up as you seem to > suggest as the only way to go. > > > > >More specifically, the software on the MN will probably ask the user > >about whether they want to switch it on, or perhaps some kind of user > >agent. > > [Govind] Maybe, but that is quite out of scope for the current discussion. > The point is whether the network can help or not. I believe > that it can. > > > > > > [Govind] What if it wants to move from one WLAN network to another... > > > essentially to save cost for eg?, and it has just one interface. > > > Clearly, CAR discovery is needed for FMIPv6 and context transfer and > > > they do talk about WLAN -> WLAN handovers. > > > [snip] > > > >To my knowledge, it is not possible to deploy two different 802.11b > >networks in the same area. It would be possible to deploy an 802.11a and > >802.11b network because they operate in different frequency ranges, but > >I view that as essentially two different media. Not sure about 802.11g. > > [Govind]Frankly, I don't know about this i.e., if it is a part of the spec.. > > But theoretically at least it should be possible to operate in the same > frequency. Even if the spreading codes are the same. Yes, this will cause > packet collisions but CSMA/CA can handle it is it not? All we have > to make sure is we backoff properly and make sure that the MN receives > beacons. My previous discussions however were under the assumptions > that multiple APs of WLANs are found. > > > > > > [Govind] I don't see any great loss of simplicity in the latter. I do > >see > > > the bandwidth/power/time efficiency in the latter though. > > > > > > > > > >Well, the other alternative is that the AR could simply pass the CAR > >information along when the MN arrives. No need for the AR to know > >anything more than that the MN arrives, i.e. keep it reeeaaal simple. > > [Govind] I agree that we should keep the actual solution simple. > But in the process we shouldn't compromise on getting to the best solution. > > > Regards, > Govind. > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:46:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15580 for ; Tue, 26 Mar 2002 12:46:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29860 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:46:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25590; Tue, 26 Mar 2002 12:33:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25546 for ; Tue, 26 Mar 2002 12:33:23 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14316 for ; Tue, 26 Mar 2002 12:33:20 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHWpI03146; Tue, 26 Mar 2002 09:32:51 -0800 (PST) Message-ID: <004101c1d4ec$07b000f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case Date: Tue, 26 Mar 2002 09:31:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, The requirements are supposed to constrain the solution in a particular direction. Constraining CAR discovery to avoid complex protocols for communication of the MN's interface card state to the network is an example. Can you articulate why such a solution is so much better than having the MN decide based on the CAR discovery information that we should continue to consider it? jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Monday, March 25, 2002 2:11 PM Subject: Re: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case > > > > James, > > >I can't see how the AR can know how many interfaces the MN has. On any > >particular day, there may be two or only one, or maybe even none if the > >user forgot all her interface cards. > [Govind] Well this information can be kept as part of the MN's profile. But > I am sure there are other ways to do it. As I explained in the previous > mail, I don't see why the MN's forgetting to power on a interface card or > forget inserting is such a big deal. Again, I am not > advocating that this is the way to do it. All I am saying is that > we shouldn't say that this isn't possible at this stage when we are just > considering requirements. > > > > >The AR won't do the waking, the MN will. That is, if the MN is getting > >traffic on one interface, it will get the CAR information on that > >interface, then the MN will make the decision about whether to power up > >the other interface. > >How can the AR wake the MN on an interface that doesn't have any power, > >much less IP service? > > [Govind] Ofcourse, the MN will do the waking, but the AR can help it wake up > selectively as opposed to the MN periodically waking up as you seem to > suggest as the only way to go. > > > > >More specifically, the software on the MN will probably ask the user > >about whether they want to switch it on, or perhaps some kind of user > >agent. > > [Govind] Maybe, but that is quite out of scope for the current discussion. > The point is whether the network can help or not. I believe > that it can. > > > > > > [Govind] What if it wants to move from one WLAN network to another... > > > essentially to save cost for eg?, and it has just one interface. > > > Clearly, CAR discovery is needed for FMIPv6 and context transfer and > > > they do talk about WLAN -> WLAN handovers. > > > [snip] > > > >To my knowledge, it is not possible to deploy two different 802.11b > >networks in the same area. It would be possible to deploy an 802.11a and > >802.11b network because they operate in different frequency ranges, but > >I view that as essentially two different media. Not sure about 802.11g. > > [Govind]Frankly, I don't know about this i.e., if it is a part of the spec.. > > But theoretically at least it should be possible to operate in the same > frequency. Even if the spreading codes are the same. Yes, this will cause > packet collisions but CSMA/CA can handle it is it not? All we have > to make sure is we backoff properly and make sure that the MN receives > beacons. My previous discussions however were under the assumptions > that multiple APs of WLANs are found. > > > > > > [Govind] I don't see any great loss of simplicity in the latter. I do > >see > > > the bandwidth/power/time efficiency in the latter though. > > > > > > > > > >Well, the other alternative is that the AR could simply pass the CAR > >information along when the MN arrives. No need for the AR to know > >anything more than that the MN arrives, i.e. keep it reeeaaal simple. > > [Govind] I agree that we should keep the actual solution simple. > But in the process we shouldn't compromise on getting to the best solution. > > > Regards, > Govind. > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:47:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15649 for ; Tue, 26 Mar 2002 12:47:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24951; Tue, 26 Mar 2002 12:31:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24912 for ; Tue, 26 Mar 2002 12:31:24 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14220 for ; Tue, 26 Mar 2002 12:31:21 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHUoI03096; Tue, 26 Mar 2002 09:30:50 -0800 (PST) Message-ID: <003b01c1d4eb$bf795ed0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 09:29:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, The issue is one of complexity. If the MN knows what interfaces it has, and which are powered up, then why not simply let it decide? Perhaps I am missing something, but I cannot see what is gained by having a complex protocol to communicate MN interface state to the AR. Can you articulate what the benefits are, and why they are so much greater than having the MN decide that we should add this complexity? jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Monday, March 25, 2002 10:11 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > Some agreements and some disagreements below, marked as . > > > >From: "James Kempf" > >To: "Hemant Chaskar" > >CC: "Kempf" > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Mon, 25 Mar 2002 13:23:33 -0800 > > > > > > > > > After the CAR discovery discussion in IETF53, it seems that we > >need to > > > > > emphasize certain points about CAR discovery. They are as follows: > > > > > > > > > > - CAR discovery always considers MN requirements while choosing > >CARs > > > >from > > > > > GAARs. > > > > > > > > > > > > >This statement sounds like some other entity beside the MN is doing > >the > > > >choosing (TAR selection). > > > > > > [HC] The statement is about "CAR discovery" (as seen from the first > >two > > > words of the sentence), which is different from TAR selection, as > >stated in > > > problem statement. Then, why would a statement made for CAR discovery > >imply > > > anything for TAR selection? > > > > > > I can't see the relevance of CAR discovery > > > >The relevance is that I would like the requirement to read as follows: > > > > The CAR discovery protocol MUST provide the MN with enough > >information about GAARs, including information concerning capabilities, > >so that the MN can make a choice of which CAR to select. > > As I already said, this requirements has to be there. I completely > agree with you. But then, it is also important to unambiguously state that > "MN requirements MUST be made available for CAR discovery if needed". > > > > >No ambiguity about what is doing the selecting. > > > > > [HC] Nobody is denying that MN should be given choice. But that does > >not > > > mean that processor instructions for comparing MN requirements with AR > > > capabilities need to be executed in MN. They could as well be executed > >in > > > AR. Not executing processor instructions in MN does not mean that MN > >does > > > not have choice. What matters is input to execution of instructions. > > > > > > >So explain to me how the AR is supposed to know what kinds of interfaces > >the MN has? I don't know why this is so hard to understand, maybe I'm > >not explaining it well. > > Is it too difficult for MN to tell so to AR? I do not think so. There > is another possibility of having it in MN's service profile as well. > > I can't see how the AR can know what interfaces > >the MN has on any particular day, so I can't possibly see a role for the > >AR in selecting an interface for the MN. > > > > > > > > So I would rephrase this: > > > > > > > > CAR discovery provides the MN with information on CARs for the > >MN to > > > >choose which TAR it wants to > > > > hand over to. > > > > > > > > > [HC] That is good. But it is not a "rephrase", it is a "different" > > > statement. What I was talking about is "providing MN requirements to > >CAR > > > discovery module", what you are saying in above statement is > >"providing CAR > > > output to MN". Both are different, but I think both need to be there. > > > > > > >"CAR discovery module" is too ambiguous. I'd like the requirements to > >clearly state that the MN is the one in charge for intertechnology > >handover. > > But then, "being in charge" is very ambiguous too. What does it > precisely mean form an algorithmic perspective? If it precludes > network-assisted CAR discovery, then I am not sure. I think network-assisted > CAR discovery can be useful for certain intertechnology cases too. It does > not immediately make sense to me to fix such a solution for inter-technology > case. > > >Otherwise, people start proposing complicated AAA transactions > >that are completely unnecessary and likely to fail anyway. See my above > >rewording. The AR *should not* and *cannot* have any role in selecting > >an interface for the MN in an intertechnology handover situation, > >because it *cannot* know a priori what interfaces the MN has. > > [HC] That is like fixing a solution. In the requirements phase, we should > give freedom to designers to design what is the best from performance > perspective and specific environments. As long as requirements do not > constrain above solution that you have in mind, what is the concern? > > Also, MN can easily tell AR what interfaces it has (send on ICMP message for > example) or this information can be statically configured in MN's service > profile. > > > > >What I am saying is your proposal for requirement language is likely to > >lead to unrealistic and complicated proposals for implementation, that > >have a high likelihood of failing in many cases. > > > > > >This is too complicated. After solcitiing the new RA, the MN can > >decide > > > >whether to connect or not. > > > > > > [HC] I disagree that this is complicated. It is fairly simple: Listen > >to > > > beacon - grab AP id - send to AR_current - wait for CAR ID. This is > >very > > > time and power efficient, and also, can feed into fast/seamless > >handoff > > > protocols. > > > > > > >Why go through the AR on the other interface when you can simply solicit > >an RA on the new one? This is a standard IPv6 procedure. What's the > >point of introducing an entirely new procedure? > > > >Furthermore, how does the MN know to power up the second interface in > >the first place? The whole point of CAR discovery, IMHO, is to tell the > >MN exactly that. Once it knows, it can simply use standard IPv6/MIPv6 > >mechanisms (or IPv4 if the network is a IPv4 network). > > [HC] What your are saying here is one solution. I do not think that any of > the requirements preclude it. But that does not mean that the requirements > should be formulated around this solution. > > > > > > [HC] It hears the new AP (e.g. an RF broadcast channel), not the new > >AR yet. > > > Various things need to happen including many message exchanges over > >wireless > > > before MN can be deemed to be listening to new AR. > > > > > > >One of those things is that it solicits an RA on the new interface. This > >is not "many message exchanges" it is exactly 1, at the IP level. Or wer > >e you thinking of GPRS? > > [HC] Sure, just like MN can go from GPRS to WLAN, it can go from WLAN to > GPRS as well. > > > > > > >The current AR doesn't have to be involved if the MN periodically > >polls. > > > > > > [HC] Periodic polling is power inefficient compared to selecting > >awakeing. > > > Also, waking up for WLAN beacons that are not willing to provide you > >service > > > is not efficient. > > > > > > >Hemant, we are talking about sending traffic on which the MN already has > >active IP service, not a dormant mode MN. > > [HC]MN already has IP traffic service on one interface. The second one is > sleeping. Waking it up and sending IP level messages through it (when > possibly not required) does consume power and takes processor MIPs. > > >If you don't like polling, and I agree that it is inefficient, there are > >other ways to do it. We could have an update pushed to the MN when a new > >network medium becomes available, like when it enters a hotspot. > > > [HC] Yes, I think that is one example of the usefulness of network-assisted > CAR discovery for inter-technology case. Polling is clearly very > inefficient. > > > > > jak > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:47:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15656 for ; Tue, 26 Mar 2002 12:47:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00096 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:47:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24951; Tue, 26 Mar 2002 12:31:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24912 for ; Tue, 26 Mar 2002 12:31:24 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14220 for ; Tue, 26 Mar 2002 12:31:21 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHUoI03096; Tue, 26 Mar 2002 09:30:50 -0800 (PST) Message-ID: <003b01c1d4eb$bf795ed0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 09:29:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, The issue is one of complexity. If the MN knows what interfaces it has, and which are powered up, then why not simply let it decide? Perhaps I am missing something, but I cannot see what is gained by having a complex protocol to communicate MN interface state to the AR. Can you articulate what the benefits are, and why they are so much greater than having the MN decide that we should add this complexity? jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Monday, March 25, 2002 10:11 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > Some agreements and some disagreements below, marked as . > > > >From: "James Kempf" > >To: "Hemant Chaskar" > >CC: "Kempf" > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Mon, 25 Mar 2002 13:23:33 -0800 > > > > > > > > > After the CAR discovery discussion in IETF53, it seems that we > >need to > > > > > emphasize certain points about CAR discovery. They are as follows: > > > > > > > > > > - CAR discovery always considers MN requirements while choosing > >CARs > > > >from > > > > > GAARs. > > > > > > > > > > > > >This statement sounds like some other entity beside the MN is doing > >the > > > >choosing (TAR selection). > > > > > > [HC] The statement is about "CAR discovery" (as seen from the first > >two > > > words of the sentence), which is different from TAR selection, as > >stated in > > > problem statement. Then, why would a statement made for CAR discovery > >imply > > > anything for TAR selection? > > > > > > I can't see the relevance of CAR discovery > > > >The relevance is that I would like the requirement to read as follows: > > > > The CAR discovery protocol MUST provide the MN with enough > >information about GAARs, including information concerning capabilities, > >so that the MN can make a choice of which CAR to select. > > As I already said, this requirements has to be there. I completely > agree with you. But then, it is also important to unambiguously state that > "MN requirements MUST be made available for CAR discovery if needed". > > > > >No ambiguity about what is doing the selecting. > > > > > [HC] Nobody is denying that MN should be given choice. But that does > >not > > > mean that processor instructions for comparing MN requirements with AR > > > capabilities need to be executed in MN. They could as well be executed > >in > > > AR. Not executing processor instructions in MN does not mean that MN > >does > > > not have choice. What matters is input to execution of instructions. > > > > > > >So explain to me how the AR is supposed to know what kinds of interfaces > >the MN has? I don't know why this is so hard to understand, maybe I'm > >not explaining it well. > > Is it too difficult for MN to tell so to AR? I do not think so. There > is another possibility of having it in MN's service profile as well. > > I can't see how the AR can know what interfaces > >the MN has on any particular day, so I can't possibly see a role for the > >AR in selecting an interface for the MN. > > > > > > > > So I would rephrase this: > > > > > > > > CAR discovery provides the MN with information on CARs for the > >MN to > > > >choose which TAR it wants to > > > > hand over to. > > > > > > > > > [HC] That is good. But it is not a "rephrase", it is a "different" > > > statement. What I was talking about is "providing MN requirements to > >CAR > > > discovery module", what you are saying in above statement is > >"providing CAR > > > output to MN". Both are different, but I think both need to be there. > > > > > > >"CAR discovery module" is too ambiguous. I'd like the requirements to > >clearly state that the MN is the one in charge for intertechnology > >handover. > > But then, "being in charge" is very ambiguous too. What does it > precisely mean form an algorithmic perspective? If it precludes > network-assisted CAR discovery, then I am not sure. I think network-assisted > CAR discovery can be useful for certain intertechnology cases too. It does > not immediately make sense to me to fix such a solution for inter-technology > case. > > >Otherwise, people start proposing complicated AAA transactions > >that are completely unnecessary and likely to fail anyway. See my above > >rewording. The AR *should not* and *cannot* have any role in selecting > >an interface for the MN in an intertechnology handover situation, > >because it *cannot* know a priori what interfaces the MN has. > > [HC] That is like fixing a solution. In the requirements phase, we should > give freedom to designers to design what is the best from performance > perspective and specific environments. As long as requirements do not > constrain above solution that you have in mind, what is the concern? > > Also, MN can easily tell AR what interfaces it has (send on ICMP message for > example) or this information can be statically configured in MN's service > profile. > > > > >What I am saying is your proposal for requirement language is likely to > >lead to unrealistic and complicated proposals for implementation, that > >have a high likelihood of failing in many cases. > > > > > >This is too complicated. After solcitiing the new RA, the MN can > >decide > > > >whether to connect or not. > > > > > > [HC] I disagree that this is complicated. It is fairly simple: Listen > >to > > > beacon - grab AP id - send to AR_current - wait for CAR ID. This is > >very > > > time and power efficient, and also, can feed into fast/seamless > >handoff > > > protocols. > > > > > > >Why go through the AR on the other interface when you can simply solicit > >an RA on the new one? This is a standard IPv6 procedure. What's the > >point of introducing an entirely new procedure? > > > >Furthermore, how does the MN know to power up the second interface in > >the first place? The whole point of CAR discovery, IMHO, is to tell the > >MN exactly that. Once it knows, it can simply use standard IPv6/MIPv6 > >mechanisms (or IPv4 if the network is a IPv4 network). > > [HC] What your are saying here is one solution. I do not think that any of > the requirements preclude it. But that does not mean that the requirements > should be formulated around this solution. > > > > > > [HC] It hears the new AP (e.g. an RF broadcast channel), not the new > >AR yet. > > > Various things need to happen including many message exchanges over > >wireless > > > before MN can be deemed to be listening to new AR. > > > > > > >One of those things is that it solicits an RA on the new interface. This > >is not "many message exchanges" it is exactly 1, at the IP level. Or wer > >e you thinking of GPRS? > > [HC] Sure, just like MN can go from GPRS to WLAN, it can go from WLAN to > GPRS as well. > > > > > > >The current AR doesn't have to be involved if the MN periodically > >polls. > > > > > > [HC] Periodic polling is power inefficient compared to selecting > >awakeing. > > > Also, waking up for WLAN beacons that are not willing to provide you > >service > > > is not efficient. > > > > > > >Hemant, we are talking about sending traffic on which the MN already has > >active IP service, not a dormant mode MN. > > [HC]MN already has IP traffic service on one interface. The second one is > sleeping. Waking it up and sending IP level messages through it (when > possibly not required) does consume power and takes processor MIPs. > > >If you don't like polling, and I agree that it is inefficient, there are > >other ways to do it. We could have an update pushed to the MN when a new > >network medium becomes available, like when it enters a hotspot. > > > [HC] Yes, I think that is one example of the usefulness of network-assisted > CAR discovery for inter-technology case. Polling is clearly very > inefficient. > > > > > jak > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 12:54:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16083 for ; Tue, 26 Mar 2002 12:54:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01019; Tue, 26 Mar 2002 12:51:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00985 for ; Tue, 26 Mar 2002 12:51:00 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15841 for ; Tue, 26 Mar 2002 12:50:57 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHoPI03627; Tue, 26 Mar 2002 09:50:25 -0800 (PST) Message-ID: <005301c1d4ee$7bd583e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Tue, 26 Mar 2002 09:48:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Let's not deep dive on how the MN uses L2 beacon information. This is fundamentally out of our control, it is an L2 issue. I think the primary disagreement we have is over whether a complex protocol is needed to communicate the MN's interface state to the AR so it can use the CAR information to decide whether to perform an intertechnology handover, or whether the CAR information should be sent to the MN and let it decide. I don't see an advantage to the former that is on the order of the complexity it would introduce into the protocol. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Monday, March 25, 2002 2:23 PM Subject: Re: [Seamoby] Comments on the requirements draft > > > > > > > > > >If the latter were not so, the MN could just use standard Router > > > > > >Discovery on the interface and there would be no need for CAR > > > >discovery. > > > > > > [Govind] Again, this is possible, essentially what you are saying here > > > is explained in Example 2. But the fact is that if there are many such > > > APs then the process in Example 2 is expensive both in time as well > > > as bandwidth efficiency as well as power as pointed in my earlier > >mail. > > > [snip] > > > > > > >I don't understand this. If the MN's power is up for it getting a > >beacon, it presumably brought the interface up that far because it wants > >to use it. What's the bandwidth and power consideration? > > > >The harder case is how the MN finds out that it should bring up the > >interface in the first place. > > [Govind] Yes, it wants to use it. But it does not to waste power on CAR > discovery and choosing among a plethora of beacons. Exactly my point. > If the MN is going to use it to connect to a beacon, get RtAdv, get > capabilities etc and then reject it because it does not fit its profile > isn't there a wastage of bandwidth and power? > > > > > > >CAR discovery is completely irrelevent if the MN brings up the > > > >interface. Neighbor Discovery is fine for discovering routers - the > >MN > > > >solicits router adverts, the routers send them. What's the problem? > > > > > > > >The only reason for CAR discovery is so that the MN doesn't need to > > > >bring up the interface to discover what's available. The sooner we > >can > > > >agree on that, the sooner we can get to the hard questions, like how > >to > > > >do it. > > > > > > [Govind] I disagree. Again please see my previous answers. > > > I agree completely that we need > > > to get to the actual protocol designing process soon. But I don't > > > agree with your premise in the previous paragraph at all. > > > > > > >Please explain. > > > >You seem to think the problem lies in finding an AR when the MN has > >already brought up an interface. I'm saying that that problem is already > >solved by IPv6 router discovery. > > > >I think the problem lies in the MN finding out that there is another > >wireless technology available, so that it can bring up the interface far > >enough to get the beacon. > > [Govind] I think the main miscommunication here is that you say when > this interface is up it is connected to an AP and thats it. In my world, > when the interface is up it is scanning for possible APs and trying to > decide which one to connect to, but not actually connected to one. I agree > that once L2 layer connectivity is established you can use standard router > discovery. No argument there. But the only point I'm tryng to make rather > unsuccessfully here so far is that the correct way to go MAY not be to > accept the first L2 connection. However, if your > earlier point is true that only one WLAN AP can be found then we don't > have an argument as I agree CAR discovery is not of much use there, except > probably to indicate to the MN that sticking with the other interface is > better, in the event that the new AR does not have the > requisite capabilities. > > > >That and doing reverse address translation for router/access point L2 > >identifiers to IP addresses. > > > Regards, > Govind. > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 12:54:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16095 for ; Tue, 26 Mar 2002 12:54:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01829 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 12:54:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01019; Tue, 26 Mar 2002 12:51:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00985 for ; Tue, 26 Mar 2002 12:51:00 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15841 for ; Tue, 26 Mar 2002 12:50:57 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QHoPI03627; Tue, 26 Mar 2002 09:50:25 -0800 (PST) Message-ID: <005301c1d4ee$7bd583e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Comments on the requirements draft Date: Tue, 26 Mar 2002 09:48:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Let's not deep dive on how the MN uses L2 beacon information. This is fundamentally out of our control, it is an L2 issue. I think the primary disagreement we have is over whether a complex protocol is needed to communicate the MN's interface state to the AR so it can use the CAR information to decide whether to perform an intertechnology handover, or whether the CAR information should be sent to the MN and let it decide. I don't see an advantage to the former that is on the order of the complexity it would introduce into the protocol. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Monday, March 25, 2002 2:23 PM Subject: Re: [Seamoby] Comments on the requirements draft > > > > > > > > > >If the latter were not so, the MN could just use standard Router > > > > > >Discovery on the interface and there would be no need for CAR > > > >discovery. > > > > > > [Govind] Again, this is possible, essentially what you are saying here > > > is explained in Example 2. But the fact is that if there are many such > > > APs then the process in Example 2 is expensive both in time as well > > > as bandwidth efficiency as well as power as pointed in my earlier > >mail. > > > [snip] > > > > > > >I don't understand this. If the MN's power is up for it getting a > >beacon, it presumably brought the interface up that far because it wants > >to use it. What's the bandwidth and power consideration? > > > >The harder case is how the MN finds out that it should bring up the > >interface in the first place. > > [Govind] Yes, it wants to use it. But it does not to waste power on CAR > discovery and choosing among a plethora of beacons. Exactly my point. > If the MN is going to use it to connect to a beacon, get RtAdv, get > capabilities etc and then reject it because it does not fit its profile > isn't there a wastage of bandwidth and power? > > > > > > >CAR discovery is completely irrelevent if the MN brings up the > > > >interface. Neighbor Discovery is fine for discovering routers - the > >MN > > > >solicits router adverts, the routers send them. What's the problem? > > > > > > > >The only reason for CAR discovery is so that the MN doesn't need to > > > >bring up the interface to discover what's available. The sooner we > >can > > > >agree on that, the sooner we can get to the hard questions, like how > >to > > > >do it. > > > > > > [Govind] I disagree. Again please see my previous answers. > > > I agree completely that we need > > > to get to the actual protocol designing process soon. But I don't > > > agree with your premise in the previous paragraph at all. > > > > > > >Please explain. > > > >You seem to think the problem lies in finding an AR when the MN has > >already brought up an interface. I'm saying that that problem is already > >solved by IPv6 router discovery. > > > >I think the problem lies in the MN finding out that there is another > >wireless technology available, so that it can bring up the interface far > >enough to get the beacon. > > [Govind] I think the main miscommunication here is that you say when > this interface is up it is connected to an AP and thats it. In my world, > when the interface is up it is scanning for possible APs and trying to > decide which one to connect to, but not actually connected to one. I agree > that once L2 layer connectivity is established you can use standard router > discovery. No argument there. But the only point I'm tryng to make rather > unsuccessfully here so far is that the correct way to go MAY not be to > accept the first L2 connection. However, if your > earlier point is true that only one WLAN AP can be found then we don't > have an argument as I agree CAR discovery is not of much use there, except > probably to indicate to the MN that sticking with the other interface is > better, in the event that the new AR does not have the > requisite capabilities. > > > >That and doing reverse address translation for router/access point L2 > >identifiers to IP addresses. > > > Regards, > Govind. > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 13:28:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17586 for ; Tue, 26 Mar 2002 13:28:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10595; Tue, 26 Mar 2002 13:25:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10556 for ; Tue, 26 Mar 2002 13:25:33 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17494 for ; Tue, 26 Mar 2002 13:25:30 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QIPUkY000392 for ; Tue, 26 Mar 2002 19:25:30 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Mar 26 19:25:29 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 19:15:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:25:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > I do not think so. There are ways to use Geospace > information to do this for > inter-tech and inter-admin handovers as well. => Come on... Geospace to get information about the WLAN in starbucks ?? Hesham But I do not > want to talk > about solutions now. The issue is, whether this requirement is > MAY/SHOULD/MUST or REMOVE, from the protocol functionality > perspective. > > Hemant > > > >From: "Hesham Soliman (ERA)" > >To: "'Hemant Chaskar'" , seamoby@ietf.org > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 18:07:24 +0100 > > > > > "It MUST/SHOULD be possible for an AR or an MN (depending > > > upon solution > > > scenario) to verify that some other AR is indeed a GAAR." > > > > > > >=> I think this statement will only make sense > >if you narrow the scope for the AR-AR protocol > >to only work within a small group of routers > >within the same access tech and belonging to > >the same operator. > > > >Hesham > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 13:28:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17595 for ; Tue, 26 Mar 2002 13:28:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11433 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 13:28:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10595; Tue, 26 Mar 2002 13:25:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10556 for ; Tue, 26 Mar 2002 13:25:33 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17494 for ; Tue, 26 Mar 2002 13:25:30 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QIPUkY000392 for ; Tue, 26 Mar 2002 19:25:30 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Mar 26 19:25:29 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 19:15:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:25:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > I do not think so. There are ways to use Geospace > information to do this for > inter-tech and inter-admin handovers as well. => Come on... Geospace to get information about the WLAN in starbucks ?? Hesham But I do not > want to talk > about solutions now. The issue is, whether this requirement is > MAY/SHOULD/MUST or REMOVE, from the protocol functionality > perspective. > > Hemant > > > >From: "Hesham Soliman (ERA)" > >To: "'Hemant Chaskar'" , seamoby@ietf.org > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 18:07:24 +0100 > > > > > "It MUST/SHOULD be possible for an AR or an MN (depending > > > upon solution > > > scenario) to verify that some other AR is indeed a GAAR." > > > > > > >=> I think this statement will only make sense > >if you narrow the scope for the AR-AR protocol > >to only work within a small group of routers > >within the same access tech and belonging to > >the same operator. > > > >Hesham > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 13:30:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17731 for ; Tue, 26 Mar 2002 13:30:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08266; Tue, 26 Mar 2002 13:16:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08219 for ; Tue, 26 Mar 2002 13:16:34 -0500 (EST) Received: from hotmail.com (f134.law9.hotmail.com [64.4.9.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17176 for ; Tue, 26 Mar 2002 13:16:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 10:16:03 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 18:16:03 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 13:16:03 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 18:16:03.0277 (UTC) FILETIME=[4A0F37D0:01C1D4F2] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >We seem not to be connecting. [Govind] I agree and thats what makes any technical discussion interesting :) > > > > > > > >The only place where I can see CAR discovery involved for a single > > >technology handover is for reverse address translation, as in >Eunsoo's > > >note. > > > > > > > [Govind] That CAR discovery is needed for reverse translation is quite > > obvious from requirement 1 of the current requirement draft. I thought > > that was the main idea behind the requirement. Anyways, my previous > > mail was saying this too. > > > >OK. [Govind] We agree. Good! > > > [Govind] I agree that the MN *must* be involved too. The main >disconnect > > between us is that you assume that the MN has no role whatsoever > > if the handover is network controlled. Clearly, the handover can be > > controlled by the network, i.e., tell the MN when to disconnect etc >but > > still take into account all of the MN's preferences. I don't >understand > > why we are having to get this point across too! > >So here is the basic disagreement: > >I don't see the point in a complicated protocol for the MN to "express >its preferences" to the AR, when the >AR can just hand over the CAR information to the MN and let the MN >choose. [Govind] First, I don't think that it is a "complicated" protocol as you suggest. As I pointed out it could just be part of the MN's profile. Second, pushing capabilities down to the MN for its decision has power,bandwidth and time considerations which one may want to consider. Again, I am not saying that what you say is not an option. But saying that the MN MUST be the only one deciding the TAR restricts the field totally which I think is rather pre-mature. > > >Regarding the MN > > only knowing which interfaces are powered on. What big difference does > > this make? > >It makes a big difference! If the interface isn't powered on and the AR >says to the MN "handover to that interface," the MN has just lost >network connectivity. Don't you agree? [Govind] I don't understand, how a "working" TAR selection algorithm which has MN reachability information as one input will allow this to happen. > > >If the network knows what interfaces the MN has then it can > > advise it to power on at the appropriate time. If it is already >powered > > on the MN just discards this. If not it acts on it. If the card is not > > inserted then it just discards the message too. What is the difficulty > > that you see here. Maybe you can explain it. > > > >Please explain to me why you want to do all this complex signaling >between the network and the MN, when all >that is required is to simply send the MN the list of CARs and have it >do the selecting? What does all this >complexity buy us? [Govind] First, I disagree that this is complex. All it requires is match what APs are available in the neighborhood to what the MN has. What does this buy us as against pushing everything to the MN: saving power for the MN. Saving wireless bandwidth is another. But again, the main disconnect between you and me is not disagreeing with what you propose as the solution but your seeming disagreement with any other option. BTW, aren't we transgressing a bit too much into solution and TAR selection phase. So I propose that we have this discussion at a later stage, because we are going to have it then again :) > >If we accept your proposal, then we are not just doing a CAR discovery >protocol but also a protocol for having the MN tell the network what >interfaces it has and what their current state is. [Govind] But unless the CAR discovery protocol knows what the requirements for the MN are how does it decide what the CARs for the MN are? If you read the definition of CAR it says GAARs whose capabilities can satisfy the MN's requirements As I said, telling the MN's interface states is not necessary at all. This is just too >complicated. The MN knows this stuff, given the right information, it >can act on it accordingly without having to get the network involved. I >simply don't see what adding this level of complexity buys us. [Govind] See above. >I'm not saying it is infeasible, I'm saying that a rational engineering >tradeoff between a complex protocol involving signaling MN interface >state and one letting the MN simply make the choice itself seems, to me >at least, to go in the direction of the latter. [Govind] Again without accepting that complexity of the protocol is very high :), we should also make sure what effect this decision has on the MN w.r.t to power and bandwidth. > >Can you explain to me what, exactly, sending the MN's interface state >around buys us that we don't get by simply sending the CAR information >to the MN and letting it make the choice? [Govind] See above. > > > > >The AAA exchange also might not be accurate. Suppose the MN is a >laptop > > >and the user forgot that day to put in their WLAN card. The AAA >record > > >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR > > >could hand the MN over to a medium which the MN can't access. > > > > [Govind] I thought reachability information *from the MN *is part of >TAR > > selection process. If the MN's WLAN card is not inserted, how do you > > suppose reachability for WLAN APs are got from the MN. So why do you >think > > the network will blindly just handover the MN to a WLAN network? > > > >I don't understand your comment. If the WLAN card isn't in, the MN isn't >going to initiate a MIP handover to an interface that is not there. >Thus, if the MN is in control of an intertechnology handover, it won't >disconnect. >However, if the AR is in control of an intertechnology handover, how is >it supposed to know that the card isn't there? [Govind] No one is arguing that the reachbility information from the MN to APs is NOT an integral part of the TAR selection process. Once this reachability information there it does not matter whether the TAR selection process resides in the network or the MN as far as your issue is concerned. > >From your comments above, I surmise you would like to see CAR discovery >include a protocol for communicating the MN's current interface state: >whether the card is there, whether it is powered on, etc., to the AR. [Govind] Nope I'm not saying this is necessary. For TAR selection the generic statement that the MN's requirements MUST be made known to CAR discovery is more than enough. Waking up an already awake device or trying to wake up an non-existent device too such a requirement will just provide an optimization to avoid some messages. >My >contention is that this is unnecessarily complex and having the MN >control the handover would provide exactly the same functionality at >much less protocol complexity cost. > >Perhaps I am missing something and there is some large benefit to adding >this complexity that I do not see. If so, what is it? [Govind] Please see above. > > > >Right, so I am willing to concede that there is a place for reverse > > >address translation to support fast handovers, but I don't see this > > >fairly limited use in the requirements. I don't think this involves >any > > >capabilities, mobile node preferences, or any other complications of > > >that sort. It is fairly simple. The Layer 2 trigger on the AR says >that > > >the MN is about to move to a new AP or AR and all that the Layer 2 > > >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer >3 > > >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > > > > [Govind] I don't understand your point. As I explained earlier, >Requirement > > 1 essentially deals with L2 to L3 mapping. Why doesn't MN's > > preferences come into picture, if there are 10 APs connected to >different > > ARs with different capabilities, ofcourse the MN's preferences > > come into picture. > > > >I think we agree on this, Govind. Let's move on to where we don't. [Govind] Sure. > > >The main point I'm making is that if there are multiple > > APs available and the MN has to choose among them, then clearly > > this has more power implications than just listening to the beacon and > > passively forward it to a AR. > > > >Like I said, the MN, at the IP layer, does not today get to choose in a >single technology situation. A future L2 might have this capability, but >I do not see why that means the AR must get involved. [Govind] Well for this future L2 that you mention, I have explained this several times, if the MN has to connect and disconnect to every AP then get IP connectivity, get capability info etc and then decide not to use it is a waste of time and bandwidth. Therefore, to say that a solution that involves the current AR is feasible is not ok IMHO. But again, I suggest lets leave this issue for now and get back to it later when things are more clearer. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 13:30:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17743 for ; Tue, 26 Mar 2002 13:30:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11971 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 13:30:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08266; Tue, 26 Mar 2002 13:16:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08219 for ; Tue, 26 Mar 2002 13:16:34 -0500 (EST) Received: from hotmail.com (f134.law9.hotmail.com [64.4.9.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17176 for ; Tue, 26 Mar 2002 13:16:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 10:16:03 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 18:16:03 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 13:16:03 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 18:16:03.0277 (UTC) FILETIME=[4A0F37D0:01C1D4F2] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >We seem not to be connecting. [Govind] I agree and thats what makes any technical discussion interesting :) > > > > > > > >The only place where I can see CAR discovery involved for a single > > >technology handover is for reverse address translation, as in >Eunsoo's > > >note. > > > > > > > [Govind] That CAR discovery is needed for reverse translation is quite > > obvious from requirement 1 of the current requirement draft. I thought > > that was the main idea behind the requirement. Anyways, my previous > > mail was saying this too. > > > >OK. [Govind] We agree. Good! > > > [Govind] I agree that the MN *must* be involved too. The main >disconnect > > between us is that you assume that the MN has no role whatsoever > > if the handover is network controlled. Clearly, the handover can be > > controlled by the network, i.e., tell the MN when to disconnect etc >but > > still take into account all of the MN's preferences. I don't >understand > > why we are having to get this point across too! > >So here is the basic disagreement: > >I don't see the point in a complicated protocol for the MN to "express >its preferences" to the AR, when the >AR can just hand over the CAR information to the MN and let the MN >choose. [Govind] First, I don't think that it is a "complicated" protocol as you suggest. As I pointed out it could just be part of the MN's profile. Second, pushing capabilities down to the MN for its decision has power,bandwidth and time considerations which one may want to consider. Again, I am not saying that what you say is not an option. But saying that the MN MUST be the only one deciding the TAR restricts the field totally which I think is rather pre-mature. > > >Regarding the MN > > only knowing which interfaces are powered on. What big difference does > > this make? > >It makes a big difference! If the interface isn't powered on and the AR >says to the MN "handover to that interface," the MN has just lost >network connectivity. Don't you agree? [Govind] I don't understand, how a "working" TAR selection algorithm which has MN reachability information as one input will allow this to happen. > > >If the network knows what interfaces the MN has then it can > > advise it to power on at the appropriate time. If it is already >powered > > on the MN just discards this. If not it acts on it. If the card is not > > inserted then it just discards the message too. What is the difficulty > > that you see here. Maybe you can explain it. > > > >Please explain to me why you want to do all this complex signaling >between the network and the MN, when all >that is required is to simply send the MN the list of CARs and have it >do the selecting? What does all this >complexity buy us? [Govind] First, I disagree that this is complex. All it requires is match what APs are available in the neighborhood to what the MN has. What does this buy us as against pushing everything to the MN: saving power for the MN. Saving wireless bandwidth is another. But again, the main disconnect between you and me is not disagreeing with what you propose as the solution but your seeming disagreement with any other option. BTW, aren't we transgressing a bit too much into solution and TAR selection phase. So I propose that we have this discussion at a later stage, because we are going to have it then again :) > >If we accept your proposal, then we are not just doing a CAR discovery >protocol but also a protocol for having the MN tell the network what >interfaces it has and what their current state is. [Govind] But unless the CAR discovery protocol knows what the requirements for the MN are how does it decide what the CARs for the MN are? If you read the definition of CAR it says GAARs whose capabilities can satisfy the MN's requirements As I said, telling the MN's interface states is not necessary at all. This is just too >complicated. The MN knows this stuff, given the right information, it >can act on it accordingly without having to get the network involved. I >simply don't see what adding this level of complexity buys us. [Govind] See above. >I'm not saying it is infeasible, I'm saying that a rational engineering >tradeoff between a complex protocol involving signaling MN interface >state and one letting the MN simply make the choice itself seems, to me >at least, to go in the direction of the latter. [Govind] Again without accepting that complexity of the protocol is very high :), we should also make sure what effect this decision has on the MN w.r.t to power and bandwidth. > >Can you explain to me what, exactly, sending the MN's interface state >around buys us that we don't get by simply sending the CAR information >to the MN and letting it make the choice? [Govind] See above. > > > > >The AAA exchange also might not be accurate. Suppose the MN is a >laptop > > >and the user forgot that day to put in their WLAN card. The AAA >record > > >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR > > >could hand the MN over to a medium which the MN can't access. > > > > [Govind] I thought reachability information *from the MN *is part of >TAR > > selection process. If the MN's WLAN card is not inserted, how do you > > suppose reachability for WLAN APs are got from the MN. So why do you >think > > the network will blindly just handover the MN to a WLAN network? > > > >I don't understand your comment. If the WLAN card isn't in, the MN isn't >going to initiate a MIP handover to an interface that is not there. >Thus, if the MN is in control of an intertechnology handover, it won't >disconnect. >However, if the AR is in control of an intertechnology handover, how is >it supposed to know that the card isn't there? [Govind] No one is arguing that the reachbility information from the MN to APs is NOT an integral part of the TAR selection process. Once this reachability information there it does not matter whether the TAR selection process resides in the network or the MN as far as your issue is concerned. > >From your comments above, I surmise you would like to see CAR discovery >include a protocol for communicating the MN's current interface state: >whether the card is there, whether it is powered on, etc., to the AR. [Govind] Nope I'm not saying this is necessary. For TAR selection the generic statement that the MN's requirements MUST be made known to CAR discovery is more than enough. Waking up an already awake device or trying to wake up an non-existent device too such a requirement will just provide an optimization to avoid some messages. >My >contention is that this is unnecessarily complex and having the MN >control the handover would provide exactly the same functionality at >much less protocol complexity cost. > >Perhaps I am missing something and there is some large benefit to adding >this complexity that I do not see. If so, what is it? [Govind] Please see above. > > > >Right, so I am willing to concede that there is a place for reverse > > >address translation to support fast handovers, but I don't see this > > >fairly limited use in the requirements. I don't think this involves >any > > >capabilities, mobile node preferences, or any other complications of > > >that sort. It is fairly simple. The Layer 2 trigger on the AR says >that > > >the MN is about to move to a new AP or AR and all that the Layer 2 > > >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer >3 > > >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > > > > [Govind] I don't understand your point. As I explained earlier, >Requirement > > 1 essentially deals with L2 to L3 mapping. Why doesn't MN's > > preferences come into picture, if there are 10 APs connected to >different > > ARs with different capabilities, ofcourse the MN's preferences > > come into picture. > > > >I think we agree on this, Govind. Let's move on to where we don't. [Govind] Sure. > > >The main point I'm making is that if there are multiple > > APs available and the MN has to choose among them, then clearly > > this has more power implications than just listening to the beacon and > > passively forward it to a AR. > > > >Like I said, the MN, at the IP layer, does not today get to choose in a >single technology situation. A future L2 might have this capability, but >I do not see why that means the AR must get involved. [Govind] Well for this future L2 that you mention, I have explained this several times, if the MN has to connect and disconnect to every AP then get IP connectivity, get capability info etc and then decide not to use it is a waste of time and bandwidth. Therefore, to say that a solution that involves the current AR is feasible is not ok IMHO. But again, I suggest lets leave this issue for now and get back to it later when things are more clearer. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 13:31:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17832 for ; Tue, 26 Mar 2002 13:31:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11575; Tue, 26 Mar 2002 13:29:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11498 for ; Tue, 26 Mar 2002 13:29:05 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17631 for ; Tue, 26 Mar 2002 13:29:02 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QIT3kY000930 for ; Tue, 26 Mar 2002 19:29:03 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 26 19:29:03 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 19:18:55 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 19:29:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > >=> Which entity runs the TAR ?? This MUST NOT > >be out of scope. This *is* the issue here, you > >can't leave the definition so loose. > > [Govind] Hmm, Could you clarify this a little more on this for me. > Are you saying that the CAR discovery process which ends before > TAR selection starts, is affected by where the TAR selection > process resides. => Of course. Process A is needed for process B, therefore the node running B will need to run A or trigger someone to run it and pass the results. I agree that the CAR discovery output must be > fed as an input to TAR selection. Wouldn't doing that be enough? > Just for clarification. See the explanation of my concern > later in this > email. => There are different requirements depending on who runs the CAR. I hope we can at least agree on this. What is the requirement for changes in physical topology if the MN is running the CAR ??? If the physical location of a BS changes so that it doesn't have the coverage area where the MN is, then guess what, the MN's interface will not come up! Nothing to do with CAR or any protocols. Hesham > > > > > > > > > However, for the openness of implementing any kind of > TAR selection > > > schemes, the current requirements take care of this > by demanding > > > the usability of CAR information by others (see exact > wording in > > > the document). With that requirement, CAR discovery > solutions must > > > enable to implement ANY kind of TAR selection, whether AR- or > > > MN-based. > > > >=> There are different requirements for each case. > >I don't think we should go through this _again_. > >Steve presentation was very clear I think and most > >people agreed. > > > [Govind]I agree that based on whether CAR discovery is performed at > the AR or MN, some of the current requirements have to be re-worded > to remove any pro-AR bias. Therefore I agree that for example the > first requirement can become in some sense: > > MUST find IP addresses of GAARs (in pseudo code) > > if [L2 becaons received as input] > then map to appropriate GAAR IP address; /* how the mapping > is done is > particular to > the solution */ > else > Find IP address; /* How the IP address is found is > particular to the > solution */ > > wouldn't that cover the case you have in mind. However, this does > not talk about TAR selection at all. First the MN (in your case) > must get capabilities. If there are any other L2 beacons in the area > maybe it has to repeat the same process there too. Once its > done with > the L2 becons (how many the MN chooses to look at is the > MN's business) > CAR discovery ends. The MN passes on the information to the > TAR selection > process (which probably in your case resides in the MN) to > make the final > decision right? But what has the original requirement have to do > with the process of delivering the output of CAR discovery > to the TAR > selection process? As an example, the MN could push the > output to the AR > to make the final decision and still the original > requirement holds good > is it not? > > I agree that a requirement is needed that the CAR discovery process > MUST have provisions to feed its output to the TAR > selection process. > Will this additional requirement satisfy your concerns? > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 13:31:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17841 for ; Tue, 26 Mar 2002 13:31:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12162 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 13:31:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11575; Tue, 26 Mar 2002 13:29:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11498 for ; Tue, 26 Mar 2002 13:29:05 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17631 for ; Tue, 26 Mar 2002 13:29:02 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QIT3kY000930 for ; Tue, 26 Mar 2002 19:29:03 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 26 19:29:03 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 19:18:55 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 19:29:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > >=> Which entity runs the TAR ?? This MUST NOT > >be out of scope. This *is* the issue here, you > >can't leave the definition so loose. > > [Govind] Hmm, Could you clarify this a little more on this for me. > Are you saying that the CAR discovery process which ends before > TAR selection starts, is affected by where the TAR selection > process resides. => Of course. Process A is needed for process B, therefore the node running B will need to run A or trigger someone to run it and pass the results. I agree that the CAR discovery output must be > fed as an input to TAR selection. Wouldn't doing that be enough? > Just for clarification. See the explanation of my concern > later in this > email. => There are different requirements depending on who runs the CAR. I hope we can at least agree on this. What is the requirement for changes in physical topology if the MN is running the CAR ??? If the physical location of a BS changes so that it doesn't have the coverage area where the MN is, then guess what, the MN's interface will not come up! Nothing to do with CAR or any protocols. Hesham > > > > > > > > > However, for the openness of implementing any kind of > TAR selection > > > schemes, the current requirements take care of this > by demanding > > > the usability of CAR information by others (see exact > wording in > > > the document). With that requirement, CAR discovery > solutions must > > > enable to implement ANY kind of TAR selection, whether AR- or > > > MN-based. > > > >=> There are different requirements for each case. > >I don't think we should go through this _again_. > >Steve presentation was very clear I think and most > >people agreed. > > > [Govind]I agree that based on whether CAR discovery is performed at > the AR or MN, some of the current requirements have to be re-worded > to remove any pro-AR bias. Therefore I agree that for example the > first requirement can become in some sense: > > MUST find IP addresses of GAARs (in pseudo code) > > if [L2 becaons received as input] > then map to appropriate GAAR IP address; /* how the mapping > is done is > particular to > the solution */ > else > Find IP address; /* How the IP address is found is > particular to the > solution */ > > wouldn't that cover the case you have in mind. However, this does > not talk about TAR selection at all. First the MN (in your case) > must get capabilities. If there are any other L2 beacons in the area > maybe it has to repeat the same process there too. Once its > done with > the L2 becons (how many the MN chooses to look at is the > MN's business) > CAR discovery ends. The MN passes on the information to the > TAR selection > process (which probably in your case resides in the MN) to > make the final > decision right? But what has the original requirement have to do > with the process of delivering the output of CAR discovery > to the TAR > selection process? As an example, the MN could push the > output to the AR > to make the final decision and still the original > requirement holds good > is it not? > > I agree that a requirement is needed that the CAR discovery process > MUST have provisions to feed its output to the TAR > selection process. > Will this additional requirement satisfy your concerns? > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 13:35:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18215 for ; Tue, 26 Mar 2002 13:35:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10328; Tue, 26 Mar 2002 13:24:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10301 for ; Tue, 26 Mar 2002 13:24:31 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17460 for ; Tue, 26 Mar 2002 13:24:28 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QIOPoq022658 for ; Tue, 26 Mar 2002 19:24:25 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 26 19:24:24 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 19:14:17 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:24:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > This looks good to me, but with a small attention to detail: > > What if MN does not want to receive such information or > does not want to > receive a part of it. Then, CAR discovery should not blast > it on MN. => The MN will ignore it if it doesn't need it. To > avoid this, we can slightly rephrase it as: > > "The CAR discovery protocol MUST provide the MN with GAAR > information, along > with capabilities, *whenever and as required by MN*." > => I disagree this is a very strange argument for removing the MN from the loop. How does the AR know ?? Do we have to invent another protocol that the MN should implement to say no ?! Can we please make this simple? Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 13:49:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18685 for ; Tue, 26 Mar 2002 13:49:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14899; Tue, 26 Mar 2002 13:42:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14869 for ; Tue, 26 Mar 2002 13:42:32 -0500 (EST) Received: from hotmail.com (f211.law9.hotmail.com [64.4.9.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18462 for ; Tue, 26 Mar 2002 13:42:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 10:42:01 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 18:42:00 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 13:42:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 18:42:01.0263 (UTC) FILETIME=[EAB103F0:01C1D4F5] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, >=> There are different requirements depending on who >runs the CAR. I hope we can at least agree on this. >What is the requirement for changes in physical >topology if the MN is running the CAR ??? >If the physical location of a BS changes so that >it doesn't have the coverage area where the MN is, >then guess what, the MN's interface will not come up! >Nothing to do with CAR or any protocols. [Govind] I agree with this and I thought that was the whole purpose of pseudo code I had written in my previous mail with Requirement 1 as an example. So maybe we can rephrase each requirement (if needed) with suggestions from you and others. I can start it off by re-wording the controversial requirements and post it on the list. What I was trying to state in my earlier mail was that I did not understand how CAR discovery requrements were affected by where the TAR selection resides. I thought using the pseudo code I explained that we will be able to do this without getting into the messy ground of TAR selection at this moment. This with the additional statement that CAR discovery output MUST be made available to TAR selection whereever it resides. I am attaching the pseudo-code just incase you missed it. // Start paragraph from previous mail [Govind]I agree that based on whether CAR discovery is performed at the AR or MN, some of the current requirements have to be re-worded to remove any pro-AR bias. Therefore I agree that for example the first requirement can become in some sense: MUST find IP addresses of GAARs (in pseudo code) if [L2 becaons received as input] then map to appropriate GAAR IP address; /* how the mapping is done particular to the solution */ else Find IP address; /* How the IP address is found is particular to the solution */ wouldn't that cover the case you have in mind. However, this does not talk about TAR selection at all. First the MN (in your case) must get capabilities. If there are any other L2 beacons in the area maybe it has to repeat the same process there too. Once its done with the L2 becons (how many the MN chooses to look at is the MN's business) CAR discovery ends. The MN passes on the information to the TAR selection process (which probably in your case resides in the MN) to make the final decision right? But what has the original requirement have to do with the process of delivering the output of CAR discovery to the TAR selection process? As an example, the MN could push the output to the AR to make the final decision and still the original requirement holds good is it not? I agree that a requirement is needed that the CAR discovery process MUST have provisions to feed its output to the TAR selection process. Will this additional requirement satisfy your concerns? // End paragraph from previous mail _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Mar 26 13:49:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18694 for ; Tue, 26 Mar 2002 13:49:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16656 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 13:49:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14899; Tue, 26 Mar 2002 13:42:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14869 for ; Tue, 26 Mar 2002 13:42:32 -0500 (EST) Received: from hotmail.com (f211.law9.hotmail.com [64.4.9.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18462 for ; Tue, 26 Mar 2002 13:42:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 10:42:01 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 18:42:00 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 13:42:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 18:42:01.0263 (UTC) FILETIME=[EAB103F0:01C1D4F5] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Hesham, >=> There are different requirements depending on who >runs the CAR. I hope we can at least agree on this. >What is the requirement for changes in physical >topology if the MN is running the CAR ??? >If the physical location of a BS changes so that >it doesn't have the coverage area where the MN is, >then guess what, the MN's interface will not come up! >Nothing to do with CAR or any protocols. [Govind] I agree with this and I thought that was the whole purpose of pseudo code I had written in my previous mail with Requirement 1 as an example. So maybe we can rephrase each requirement (if needed) with suggestions from you and others. I can start it off by re-wording the controversial requirements and post it on the list. What I was trying to state in my earlier mail was that I did not understand how CAR discovery requrements were affected by where the TAR selection resides. I thought using the pseudo code I explained that we will be able to do this without getting into the messy ground of TAR selection at this moment. This with the additional statement that CAR discovery output MUST be made available to TAR selection whereever it resides. I am attaching the pseudo-code just incase you missed it. // Start paragraph from previous mail [Govind]I agree that based on whether CAR discovery is performed at the AR or MN, some of the current requirements have to be re-worded to remove any pro-AR bias. Therefore I agree that for example the first requirement can become in some sense: MUST find IP addresses of GAARs (in pseudo code) if [L2 becaons received as input] then map to appropriate GAAR IP address; /* how the mapping is done particular to the solution */ else Find IP address; /* How the IP address is found is particular to the solution */ wouldn't that cover the case you have in mind. However, this does not talk about TAR selection at all. First the MN (in your case) must get capabilities. If there are any other L2 beacons in the area maybe it has to repeat the same process there too. Once its done with the L2 becons (how many the MN chooses to look at is the MN's business) CAR discovery ends. The MN passes on the information to the TAR selection process (which probably in your case resides in the MN) to make the final decision right? But what has the original requirement have to do with the process of delivering the output of CAR discovery to the TAR selection process? As an example, the MN could push the output to the AR to make the final decision and still the original requirement holds good is it not? I agree that a requirement is needed that the CAR discovery process MUST have provisions to feed its output to the TAR selection process. Will this additional requirement satisfy your concerns? // End paragraph from previous mail _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 14:28:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18223 for ; Tue, 26 Mar 2002 13:35:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13287 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 13:35:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10328; Tue, 26 Mar 2002 13:24:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10301 for ; Tue, 26 Mar 2002 13:24:31 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17460 for ; Tue, 26 Mar 2002 13:24:28 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QIOPoq022658 for ; Tue, 26 Mar 2002 19:24:25 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 26 19:24:24 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 19:14:17 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB7D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:24:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > This looks good to me, but with a small attention to detail: > > What if MN does not want to receive such information or > does not want to > receive a part of it. Then, CAR discovery should not blast > it on MN. => The MN will ignore it if it doesn't need it. To > avoid this, we can slightly rephrase it as: > > "The CAR discovery protocol MUST provide the MN with GAAR > information, along > with capabilities, *whenever and as required by MN*." > => I disagree this is a very strange argument for removing the MN from the loop. How does the AR know ?? Do we have to invent another protocol that the MN should implement to say no ?! Can we please make this simple? Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 15:01:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21214 for ; Tue, 26 Mar 2002 15:01:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04111; Tue, 26 Mar 2002 14:54:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04070 for ; Tue, 26 Mar 2002 14:54:21 -0500 (EST) Received: from hotmail.com (f129.law7.hotmail.com [216.33.237.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20749 for ; Tue, 26 Mar 2002 14:54:16 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 11:53:48 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 19:53:48 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:53:48 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 19:53:48.0805 (UTC) FILETIME=[F22FC350:01C1D4FF] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: Why do you think that anybody is trying to remove MN from loop? On the contrary, we are giving even more control to MN of deciding whether it wants to receive all the information, a part of it or none. This fits well in line with giving end host absolute control over CAR discovery. If we do not have that extension to requirement, it seems that network is assuming on behalf of MN that MN does need all this information, when MN actually chooses not to. Of course, nothing prevents us from having a default case of blasting MN with all GAARs and their requirements. Blindly blasting MN with requirements looks very inefficient to me. Further, this will in the future considerably restrict the detailedness of capability information that we can to consider. Finally, you said below that MN can ignore it. But then, why spend wireless bandwidth and MN processing power (it takes processing power to ignore too) to receive unwanted information. BR, Hemant >From: "Hesham Soliman (ERA)" >To: "'Hemant Chaskar'" , seamoby@ietf.org >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 19:24:19 +0100 > > > This looks good to me, but with a small attention to detail: > > > > What if MN does not want to receive such information or > > does not want to > > receive a part of it. Then, CAR discovery should not blast > > it on MN. > >=> The MN will ignore it if it doesn't >need it. > > To > > avoid this, we can slightly rephrase it as: > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > information, along > > with capabilities, *whenever and as required by MN*." > > >=> I disagree this is a very strange >argument for removing the MN from the loop. >How does the AR know ?? Do we have to invent >another protocol that the MN should implement >to say no ?! > >Can we please make this simple? > >Hesham _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 15:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21222 for ; Tue, 26 Mar 2002 15:01:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06229 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 15:01:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04111; Tue, 26 Mar 2002 14:54:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04070 for ; Tue, 26 Mar 2002 14:54:21 -0500 (EST) Received: from hotmail.com (f129.law7.hotmail.com [216.33.237.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20749 for ; Tue, 26 Mar 2002 14:54:16 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 11:53:48 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 19:53:48 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:53:48 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 19:53:48.0805 (UTC) FILETIME=[F22FC350:01C1D4FF] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: Why do you think that anybody is trying to remove MN from loop? On the contrary, we are giving even more control to MN of deciding whether it wants to receive all the information, a part of it or none. This fits well in line with giving end host absolute control over CAR discovery. If we do not have that extension to requirement, it seems that network is assuming on behalf of MN that MN does need all this information, when MN actually chooses not to. Of course, nothing prevents us from having a default case of blasting MN with all GAARs and their requirements. Blindly blasting MN with requirements looks very inefficient to me. Further, this will in the future considerably restrict the detailedness of capability information that we can to consider. Finally, you said below that MN can ignore it. But then, why spend wireless bandwidth and MN processing power (it takes processing power to ignore too) to receive unwanted information. BR, Hemant >From: "Hesham Soliman (ERA)" >To: "'Hemant Chaskar'" , seamoby@ietf.org >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 19:24:19 +0100 > > > This looks good to me, but with a small attention to detail: > > > > What if MN does not want to receive such information or > > does not want to > > receive a part of it. Then, CAR discovery should not blast > > it on MN. > >=> The MN will ignore it if it doesn't >need it. > > To > > avoid this, we can slightly rephrase it as: > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > information, along > > with capabilities, *whenever and as required by MN*." > > >=> I disagree this is a very strange >argument for removing the MN from the loop. >How does the AR know ?? Do we have to invent >another protocol that the MN should implement >to say no ?! > >Can we please make this simple? > >Hesham _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 15:32:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22445 for ; Tue, 26 Mar 2002 15:32:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13090; Tue, 26 Mar 2002 15:27:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13018 for ; Tue, 26 Mar 2002 15:27:05 -0500 (EST) Received: from hotmail.com (f122.law7.hotmail.com [216.33.237.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22153 for ; Tue, 26 Mar 2002 15:27:02 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 12:26:29 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 20:26:29 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 20:26:29 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 20:26:29.0488 (UTC) FILETIME=[82D83F00:01C1D504] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry, some errors in the previous email. I meant "capabilites" and "not requirements" in some of the following sentences. Here is the corrected version: ------- Hi Hesham: Why do you think that anybody is trying to remove MN from loop? On the contrary, we are giving even more control to MN of deciding whether it wants to receive all the information, a part of it or none. This fits well in line with giving end host absolute control over CAR discovery. If we do not have that extension to requirement, it seems that network is assuming on behalf of MN that MN does need all this information, when MN actually chooses not to. Of course, nothing prevents us from having a default case of blasting MN with all GAARs and their capabilities. Blindly blasting MN with GAAR capabilities looks very inefficient to me. Further, this will in the future considerably restrict the detailedness of capability information that we can to consider. Finally, you said below that MN can ignore it. But then, why spend wireless bandwidth and MN processing power (it takes processing power to ignore too) to receive unwanted information. BR, Hemant -------------------------------------------- >From: "Hemant Chaskar" >To: hesham.soliman@era.ericsson.se, seamoby@ietf.org >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 19:53:48 > >Hi Hesham: > >Why do you think that anybody is trying to remove MN from loop? On the >contrary, we are giving even more control to MN of deciding whether it >wants >to receive all the information, a part of it or none. > >This fits well in line with giving end host absolute control over CAR >discovery. If we do not have that extension to requirement, it seems that >network is assuming on behalf of MN that MN does need all this information, >when MN actually chooses not to. Of course, nothing prevents us from having >a default case of blasting MN with all GAARs and their requirements. > >Blindly blasting MN with requirements looks very inefficient to me. >Further, >this will in the future considerably restrict the detailedness of >capability >information that we can to consider. > >Finally, you said below that MN can ignore it. But then, why spend wireless >bandwidth and MN processing power (it takes processing power to ignore too) >to receive unwanted information. > >BR, >Hemant > > >>From: "Hesham Soliman (ERA)" >>To: "'Hemant Chaskar'" , seamoby@ietf.org >>Subject: RE: [Seamoby] Examples of CAR discovery >>Date: Tue, 26 Mar 2002 19:24:19 +0100 >> >> > This looks good to me, but with a small attention to detail: >> > >> > What if MN does not want to receive such information or >> > does not want to >> > receive a part of it. Then, CAR discovery should not blast >> > it on MN. >> >>=> The MN will ignore it if it doesn't >>need it. >> >> To >> > avoid this, we can slightly rephrase it as: >> > >> > "The CAR discovery protocol MUST provide the MN with GAAR >> > information, along >> > with capabilities, *whenever and as required by MN*." >> > >>=> I disagree this is a very strange >>argument for removing the MN from the loop. >>How does the AR know ?? Do we have to invent >>another protocol that the MN should implement >>to say no ?! >> >>Can we please make this simple? >> >>Hesham > > >_________________________________________________________________ >Send and receive Hotmail on your mobile device: http://mobile.msn.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 15:32:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22453 for ; Tue, 26 Mar 2002 15:32:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14549 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 15:32:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13090; Tue, 26 Mar 2002 15:27:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13018 for ; Tue, 26 Mar 2002 15:27:05 -0500 (EST) Received: from hotmail.com (f122.law7.hotmail.com [216.33.237.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22153 for ; Tue, 26 Mar 2002 15:27:02 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 12:26:29 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 20:26:29 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 20:26:29 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 20:26:29.0488 (UTC) FILETIME=[82D83F00:01C1D504] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry, some errors in the previous email. I meant "capabilites" and "not requirements" in some of the following sentences. Here is the corrected version: ------- Hi Hesham: Why do you think that anybody is trying to remove MN from loop? On the contrary, we are giving even more control to MN of deciding whether it wants to receive all the information, a part of it or none. This fits well in line with giving end host absolute control over CAR discovery. If we do not have that extension to requirement, it seems that network is assuming on behalf of MN that MN does need all this information, when MN actually chooses not to. Of course, nothing prevents us from having a default case of blasting MN with all GAARs and their capabilities. Blindly blasting MN with GAAR capabilities looks very inefficient to me. Further, this will in the future considerably restrict the detailedness of capability information that we can to consider. Finally, you said below that MN can ignore it. But then, why spend wireless bandwidth and MN processing power (it takes processing power to ignore too) to receive unwanted information. BR, Hemant -------------------------------------------- >From: "Hemant Chaskar" >To: hesham.soliman@era.ericsson.se, seamoby@ietf.org >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 19:53:48 > >Hi Hesham: > >Why do you think that anybody is trying to remove MN from loop? On the >contrary, we are giving even more control to MN of deciding whether it >wants >to receive all the information, a part of it or none. > >This fits well in line with giving end host absolute control over CAR >discovery. If we do not have that extension to requirement, it seems that >network is assuming on behalf of MN that MN does need all this information, >when MN actually chooses not to. Of course, nothing prevents us from having >a default case of blasting MN with all GAARs and their requirements. > >Blindly blasting MN with requirements looks very inefficient to me. >Further, >this will in the future considerably restrict the detailedness of >capability >information that we can to consider. > >Finally, you said below that MN can ignore it. But then, why spend wireless >bandwidth and MN processing power (it takes processing power to ignore too) >to receive unwanted information. > >BR, >Hemant > > >>From: "Hesham Soliman (ERA)" >>To: "'Hemant Chaskar'" , seamoby@ietf.org >>Subject: RE: [Seamoby] Examples of CAR discovery >>Date: Tue, 26 Mar 2002 19:24:19 +0100 >> >> > This looks good to me, but with a small attention to detail: >> > >> > What if MN does not want to receive such information or >> > does not want to >> > receive a part of it. Then, CAR discovery should not blast >> > it on MN. >> >>=> The MN will ignore it if it doesn't >>need it. >> >> To >> > avoid this, we can slightly rephrase it as: >> > >> > "The CAR discovery protocol MUST provide the MN with GAAR >> > information, along >> > with capabilities, *whenever and as required by MN*." >> > >>=> I disagree this is a very strange >>argument for removing the MN from the loop. >>How does the AR know ?? Do we have to invent >>another protocol that the MN should implement >>to say no ?! >> >>Can we please make this simple? >> >>Hesham > > >_________________________________________________________________ >Send and receive Hotmail on your mobile device: http://mobile.msn.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 15:38:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22661 for ; Tue, 26 Mar 2002 15:38:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14970; Tue, 26 Mar 2002 15:34:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14941 for ; Tue, 26 Mar 2002 15:34:34 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22535 for ; Tue, 26 Mar 2002 15:34:30 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKXwI09438; Tue, 26 Mar 2002 12:33:59 -0800 (PST) Message-ID: <01c401c1d505$554f55e0$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 12:32:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Regarding the requirements for CAR discovery, we therefore should > allow any kind of CAR discovery solutions as well, as long as they > fulfill the basic job requirements, namely providing said set of CARs > (under several constraints, such as preserving existing security models). Hence, any solution, either MN-based, AR-based, network-assisted, or > whatever, should be feasible with the requirements, even though some > people might not believe that certain solutions are possible or sufficient. Keep in mind that the best proof is the assessment of a provided solution. > Sorry, Dirk, but I thought we settled this in Minneapolis. The point of requirements is to constrain the solution set sufficiently that the selected solution solves the problem in a way that makes engineering sense. I have not yet heard an argument as to why AR-based CAR discovery makes engineering sense. If you think the requirements should allow that possibility, then please give me an argument why. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 15:38:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22670 for ; Tue, 26 Mar 2002 15:38:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15781 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 15:38:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14970; Tue, 26 Mar 2002 15:34:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14941 for ; Tue, 26 Mar 2002 15:34:34 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22535 for ; Tue, 26 Mar 2002 15:34:30 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKXwI09438; Tue, 26 Mar 2002 12:33:59 -0800 (PST) Message-ID: <01c401c1d505$554f55e0$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 12:32:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > Regarding the requirements for CAR discovery, we therefore should > allow any kind of CAR discovery solutions as well, as long as they > fulfill the basic job requirements, namely providing said set of CARs > (under several constraints, such as preserving existing security models). Hence, any solution, either MN-based, AR-based, network-assisted, or > whatever, should be feasible with the requirements, even though some > people might not believe that certain solutions are possible or sufficient. Keep in mind that the best proof is the assessment of a provided solution. > Sorry, Dirk, but I thought we settled this in Minneapolis. The point of requirements is to constrain the solution set sufficiently that the selected solution solves the problem in a way that makes engineering sense. I have not yet heard an argument as to why AR-based CAR discovery makes engineering sense. If you think the requirements should allow that possibility, then please give me an argument why. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 15:54:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23121 for ; Tue, 26 Mar 2002 15:54:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18299; Tue, 26 Mar 2002 15:48:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18269 for ; Tue, 26 Mar 2002 15:48:14 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22932 for ; Tue, 26 Mar 2002 15:48:10 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKlZI09768; Tue, 26 Mar 2002 12:47:35 -0800 (PST) Message-ID: <01f401c1d507$3be204c0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:45:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > [DOT] We currently have a requirement stating the usability of > information. The question though is whether your requirement for > instance in a network-assisted approach would mean that the current > AR has to send the entire list of GAARs with capabilities to the MN > or that the MN should be able to request this information. The former one > looks terribly inefficient to me when it comes to larger capability sets. > The latter one is providing-on-request. As I said this is already in the > requirements in terms of usability of information. > This is TBD. > This is clear and unambiguous about what network entity is in control > during an intertechnology handover. > > [DOT] Again as a reminder, TAR selection is not within the scope of > CAR discovery, so it should be possible to implement ANY kind of > TAR selection. Whether in your model, the MN is 'in control' or > 'in charge' doesn't really matter as long as we don't define > TAR selection as being in scope, and therefore as to be addressed. > Right, just so long as the requirements don't make this ambiguous. I don't think we want people proposing complicated AAA-based solutions for having the MN tell the network whether one of its interfaces is switched on when the MN just needs to check its power mangement software itself. :-) The requirements should be clearly worded to indicate that the MN is in charge. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 15:54:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23130 for ; Tue, 26 Mar 2002 15:54:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19819 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 15:54:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18299; Tue, 26 Mar 2002 15:48:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18269 for ; Tue, 26 Mar 2002 15:48:14 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22932 for ; Tue, 26 Mar 2002 15:48:10 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKlZI09768; Tue, 26 Mar 2002 12:47:35 -0800 (PST) Message-ID: <01f401c1d507$3be204c0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:45:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > [DOT] We currently have a requirement stating the usability of > information. The question though is whether your requirement for > instance in a network-assisted approach would mean that the current > AR has to send the entire list of GAARs with capabilities to the MN > or that the MN should be able to request this information. The former one > looks terribly inefficient to me when it comes to larger capability sets. > The latter one is providing-on-request. As I said this is already in the > requirements in terms of usability of information. > This is TBD. > This is clear and unambiguous about what network entity is in control > during an intertechnology handover. > > [DOT] Again as a reminder, TAR selection is not within the scope of > CAR discovery, so it should be possible to implement ANY kind of > TAR selection. Whether in your model, the MN is 'in control' or > 'in charge' doesn't really matter as long as we don't define > TAR selection as being in scope, and therefore as to be addressed. > Right, just so long as the requirements don't make this ambiguous. I don't think we want people proposing complicated AAA-based solutions for having the MN tell the network whether one of its interfaces is switched on when the MN just needs to check its power mangement software itself. :-) The requirements should be clearly worded to indicate that the MN is in charge. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 15:59:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23385 for ; Tue, 26 Mar 2002 15:59:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19236; Tue, 26 Mar 2002 15:52:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19205 for ; Tue, 26 Mar 2002 15:52:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23035 for ; Tue, 26 Mar 2002 15:52:00 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKpVI09860; Tue, 26 Mar 2002 12:51:31 -0800 (PST) Message-ID: <022201c1d507$c85bc7b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:49:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Sounds fine to me. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Tuesday, March 26, 2002 5:19 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > This looks good to me, but with a small attention to detail: > > What if MN does not want to receive such information or does not want to > receive a part of it. Then, CAR discovery should not blast it on MN. To > avoid this, we can slightly rephrase it as: > > "The CAR discovery protocol MUST provide the MN with GAAR information, along > with capabilities, *whenever and as required by MN*." > > BR, > Hemant > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 08:33:18 -0800 > > > >Hemant, > > > >I prefer wording that specifically requires the MN to be involved in > >getting the CAR information. Thus: > > > > The CAR discovery protocol MUST provide the MN with GAAR > >information, along with capabilities. > > > >This is clear and unambiguous about what network entity is in control > >during an intertechnology handover. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: > >Sent: Monday, March 25, 2002 9:32 PM > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi: > > > > > > Some comments below: > > > > > > > > > >From: "James Kempf" > > > >To: "Eunsoo Shim" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > > > > > Please just let me remind you that the CAR discovery protocol also > > > >provides > > > > > mapping of L2 ID to IP address of the new AR which is necessary > >for > > > >the > > > > > low-latency handoff mechanism proposed in the MobileIP WG. So > >there is > > > >a > > > > > case CAR discovery is helpful for single technology handovers. > > > > > > > > > > > > >OK, so what you are saying is that there are two cases: > > > > > > > >1) Provding the MN with CAR information on what choices are available > > > >or, possibly, when the MN moves into an area where a new choice is > > > >possible, like moving into a hot spot area, for MNs that have > >multiple > > > >interfaces. > > > > > > > >2) Providing the AR with reverse address translation for CARs for MNs > > > >that have single interfaces and want fast handover support. > > > > > > > > > > >I agree. > > > > > > > >I don't get the feeling that these two cases are clearly delineated > >in > > > >the requirements. In fact, they seem to me like they are really two > > > >separate protocols. > > > > > > [HC] From the requirements perspective, what all the recent discussion > >is > > > about is probably the following requirement text (with supporting line > >that > > > CAR discovery is about comparing MN's requirements with GAAR > >capabilities > > > and slecting CARs from GAARs): > > > > > > "CAR discovery output MUST be retrievable, possibly selectively, by > >MN". > > > Also, I assume that there will the the following requirement as well > >(I > > > think that this was posted before IETF53 and I also saw some WG > >members > > > endorse it in IETF53 meeting): "MN requirements MUST be made available > >for > > > CAR discovery". > > > > > > This would mandate a CAR discovery functionality as follows: > > > > > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> > >MN > > > ^ > > > | > > > | > > > Capability information about GAARs > > > > > > Again, "CAR discovery module" can reside completely in MN, completely > >in AR > > > or combination depending upon environment, availability of > >multiplicity of > > > interfaces with MN etc. Further, the nature of MN requirements input > >and > > > corresponding output depends upon the environement in which CAR > >discovery is > > > being used. Also, whether the solution is organized into seperate > >protocols > > > or single protocol is a solution-specific aspect. > > > > > > (Note: The first requirement in requiremnet spec already says the > >address > > > translation part. We can keep it so given its importance for > >fast/seamless > > > handoffs, though it can be subsumed into above generic model (with > >"one > > > parameter = L2 id", "one capability information about GAARs = L2 to IP > >addr. > > > maps" and "output=IP address of CAR").) > > > > > > > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding > >your > > > > > question, couldn't we imagine a case when a network provider wants > >do > > > >a kind > > > > > of load-balancing between different access networks in the > >wireless > > > >overlay > > > > > network? > > > > > > > > > > > > >Sure, but I think that's a very special case. The more general case > >(and > > > >in fact, the case that is showing up *today*) is that one network > > > >provider owns one medium and the other another. Example: at the > >airport, > > > >the cellular provider owns the CDMA network and some WLAN provider > >owns > > > >the WLAN network. > > > > > > [HC]There is a concept of operator owned WLAN that is actually > >catching up. > > > Some systems are already rolled out in Europe if I am not mistaken. > >So, both > > > cases are very important - two media owned by two operators and two > >media > > > owned by single operator. > > > > > > BR, > > > Hemant > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 16:00:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23394 for ; Tue, 26 Mar 2002 16:00:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21109 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19236; Tue, 26 Mar 2002 15:52:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19205 for ; Tue, 26 Mar 2002 15:52:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23035 for ; Tue, 26 Mar 2002 15:52:00 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKpVI09860; Tue, 26 Mar 2002 12:51:31 -0800 (PST) Message-ID: <022201c1d507$c85bc7b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:49:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Sounds fine to me. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Tuesday, March 26, 2002 5:19 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > This looks good to me, but with a small attention to detail: > > What if MN does not want to receive such information or does not want to > receive a part of it. Then, CAR discovery should not blast it on MN. To > avoid this, we can slightly rephrase it as: > > "The CAR discovery protocol MUST provide the MN with GAAR information, along > with capabilities, *whenever and as required by MN*." > > BR, > Hemant > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 08:33:18 -0800 > > > >Hemant, > > > >I prefer wording that specifically requires the MN to be involved in > >getting the CAR information. Thus: > > > > The CAR discovery protocol MUST provide the MN with GAAR > >information, along with capabilities. > > > >This is clear and unambiguous about what network entity is in control > >during an intertechnology handover. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: > >Sent: Monday, March 25, 2002 9:32 PM > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi: > > > > > > Some comments below: > > > > > > > > > >From: "James Kempf" > > > >To: "Eunsoo Shim" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > > > > > Please just let me remind you that the CAR discovery protocol also > > > >provides > > > > > mapping of L2 ID to IP address of the new AR which is necessary > >for > > > >the > > > > > low-latency handoff mechanism proposed in the MobileIP WG. So > >there is > > > >a > > > > > case CAR discovery is helpful for single technology handovers. > > > > > > > > > > > > >OK, so what you are saying is that there are two cases: > > > > > > > >1) Provding the MN with CAR information on what choices are available > > > >or, possibly, when the MN moves into an area where a new choice is > > > >possible, like moving into a hot spot area, for MNs that have > >multiple > > > >interfaces. > > > > > > > >2) Providing the AR with reverse address translation for CARs for MNs > > > >that have single interfaces and want fast handover support. > > > > > > > > > > >I agree. > > > > > > > >I don't get the feeling that these two cases are clearly delineated > >in > > > >the requirements. In fact, they seem to me like they are really two > > > >separate protocols. > > > > > > [HC] From the requirements perspective, what all the recent discussion > >is > > > about is probably the following requirement text (with supporting line > >that > > > CAR discovery is about comparing MN's requirements with GAAR > >capabilities > > > and slecting CARs from GAARs): > > > > > > "CAR discovery output MUST be retrievable, possibly selectively, by > >MN". > > > Also, I assume that there will the the following requirement as well > >(I > > > think that this was posted before IETF53 and I also saw some WG > >members > > > endorse it in IETF53 meeting): "MN requirements MUST be made available > >for > > > CAR discovery". > > > > > > This would mandate a CAR discovery functionality as follows: > > > > > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> > >MN > > > ^ > > > | > > > | > > > Capability information about GAARs > > > > > > Again, "CAR discovery module" can reside completely in MN, completely > >in AR > > > or combination depending upon environment, availability of > >multiplicity of > > > interfaces with MN etc. Further, the nature of MN requirements input > >and > > > corresponding output depends upon the environement in which CAR > >discovery is > > > being used. Also, whether the solution is organized into seperate > >protocols > > > or single protocol is a solution-specific aspect. > > > > > > (Note: The first requirement in requiremnet spec already says the > >address > > > translation part. We can keep it so given its importance for > >fast/seamless > > > handoffs, though it can be subsumed into above generic model (with > >"one > > > parameter = L2 id", "one capability information about GAARs = L2 to IP > >addr. > > > maps" and "output=IP address of CAR").) > > > > > > > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding > >your > > > > > question, couldn't we imagine a case when a network provider wants > >do > > > >a kind > > > > > of load-balancing between different access networks in the > >wireless > > > >overlay > > > > > network? > > > > > > > > > > > > >Sure, but I think that's a very special case. The more general case > >(and > > > >in fact, the case that is showing up *today*) is that one network > > > >provider owns one medium and the other another. Example: at the > >airport, > > > >the cellular provider owns the CDMA network and some WLAN provider > >owns > > > >the WLAN network. > > > > > > [HC]There is a concept of operator owned WLAN that is actually > >catching up. > > > Some systems are already rolled out in Europe if I am not mistaken. > >So, both > > > cases are very important - two media owned by two operators and two > >media > > > owned by single operator. > > > > > > BR, > > > Hemant > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 16:06:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23749 for ; Tue, 26 Mar 2002 16:06:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21071; Tue, 26 Mar 2002 15:59:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21034 for ; Tue, 26 Mar 2002 15:59:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23382 for ; Tue, 26 Mar 2002 15:59:52 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKxNI10069; Tue, 26 Mar 2002 12:59:23 -0800 (PST) Message-ID: <026e01c1d508$e1ec9f00$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:57:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit But..but.. How can you push into the MN's profile that on Tues. March 26 Mr. Fu forget his network card because he had to take his kid to the doctor? jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Tuesday, March 26, 2002 10:16 AM Subject: Re: [Seamoby] Examples of CAR discovery > > > James, > > >We seem not to be connecting. > > [Govind] I agree and thats what makes any technical discussion interesting > :) > > > > > > > > > > >The only place where I can see CAR discovery involved for a single > > > >technology handover is for reverse address translation, as in > >Eunsoo's > > > >note. > > > > > > > > > > [Govind] That CAR discovery is needed for reverse translation is quite > > > obvious from requirement 1 of the current requirement draft. I thought > > > that was the main idea behind the requirement. Anyways, my previous > > > mail was saying this too. > > > > > > >OK. > > [Govind] We agree. Good! > > > > > [Govind] I agree that the MN *must* be involved too. The main > >disconnect > > > between us is that you assume that the MN has no role whatsoever > > > if the handover is network controlled. Clearly, the handover can be > > > controlled by the network, i.e., tell the MN when to disconnect etc > >but > > > still take into account all of the MN's preferences. I don't > >understand > > > why we are having to get this point across too! > > > >So here is the basic disagreement: > > > >I don't see the point in a complicated protocol for the MN to "express > >its preferences" to the AR, when the > >AR can just hand over the CAR information to the MN and let the MN > >choose. > > [Govind] First, I don't think that it is a "complicated" protocol > as you suggest. As I pointed out it could just be part of the MN's profile. > Second, pushing capabilities down to the MN for its decision > has power,bandwidth and time considerations which one may want to consider. > Again, I am not saying that what you say is not an option. But > saying that the MN MUST be the only one deciding the TAR restricts > the field totally which I think is rather pre-mature. > > > > > >Regarding the MN > > > only knowing which interfaces are powered on. What big difference does > > > this make? > > > >It makes a big difference! If the interface isn't powered on and the AR > >says to the MN "handover to that interface," the MN has just lost > >network connectivity. Don't you agree? > > [Govind] I don't understand, how a "working" TAR selection algorithm which > has MN reachability information as one input will allow this to happen. > > > > > > > >If the network knows what interfaces the MN has then it can > > > advise it to power on at the appropriate time. If it is already > >powered > > > on the MN just discards this. If not it acts on it. If the card is not > > > inserted then it just discards the message too. What is the difficulty > > > that you see here. Maybe you can explain it. > > > > > > > >Please explain to me why you want to do all this complex signaling > >between the network and the MN, when all > >that is required is to simply send the MN the list of CARs and have it > >do the selecting? What does all this > >complexity buy us? > > [Govind] First, I disagree that this is complex. All it requires is > match what APs are available in the neighborhood to what the MN has. > What does this buy us as against pushing everything to the MN: saving power > for the MN. Saving wireless bandwidth is another. But again, the main > disconnect between you and me is not > disagreeing with what you propose as the solution but your seeming > disagreement with any other option. > BTW, aren't we transgressing a bit > too much into solution and TAR selection phase. So I propose that we > have this discussion at a later stage, because we are going to have it > then again :) > > > > >If we accept your proposal, then we are not just doing a CAR discovery > >protocol but also a protocol for having the MN tell the network what > >interfaces it has and what their current state is. > [Govind] But unless the CAR discovery protocol knows what the requirements > for the MN are how does it decide what the CARs for the MN > are? If you read the definition of CAR it says GAARs whose capabilities > can satisfy the MN's requirements As I said, telling the MN's interface > states is not necessary at all. > > This is just too > >complicated. The MN knows this stuff, given the right information, it > >can act on it accordingly without having to get the network involved. I > >simply don't see what adding this level of complexity buys us. > > [Govind] See above. > > >I'm not saying it is infeasible, I'm saying that a rational engineering > >tradeoff between a complex protocol involving signaling MN interface > >state and one letting the MN simply make the choice itself seems, to me > >at least, to go in the direction of the latter. > > [Govind] Again without accepting that complexity of the protocol is very > high :), we should also make sure what effect this decision has on the MN > w.r.t to power and bandwidth. > > > >Can you explain to me what, exactly, sending the MN's interface state > >around buys us that we don't get by simply sending the CAR information > >to the MN and letting it make the choice? > > [Govind] See above. > > > > > > > >The AAA exchange also might not be accurate. Suppose the MN is a > >laptop > > > >and the user forgot that day to put in their WLAN card. The AAA > >record > > > >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR > > > >could hand the MN over to a medium which the MN can't access. > > > > > > [Govind] I thought reachability information *from the MN *is part of > >TAR > > > selection process. If the MN's WLAN card is not inserted, how do you > > > suppose reachability for WLAN APs are got from the MN. So why do you > >think > > > the network will blindly just handover the MN to a WLAN network? > > > > > > >I don't understand your comment. If the WLAN card isn't in, the MN isn't > >going to initiate a MIP handover to an interface that is not there. > >Thus, if the MN is in control of an intertechnology handover, it won't > >disconnect. > >However, if the AR is in control of an intertechnology handover, how is > >it supposed to know that the card isn't there? > > [Govind] No one is arguing that the reachbility information from the MN to > APs is NOT an integral part of the TAR selection process. Once this > reachability information there it does not matter whether the TAR selection > process resides in the network or the MN as far as your issue > is concerned. > > > > >From your comments above, I surmise you would like to see CAR discovery > >include a protocol for communicating the MN's current interface state: > >whether the card is there, whether it is powered on, etc., to the AR. > > [Govind] Nope I'm not saying this is necessary. For TAR selection the > generic statement that the MN's requirements MUST be made known to CAR > discovery is more than enough. > > Waking up an already awake device or trying to wake up an non-existent > device too such a requirement will just provide an optimization to > avoid some messages. > > > >My > >contention is that this is unnecessarily complex and having the MN > >control the handover would provide exactly the same functionality at > >much less protocol complexity cost. > > > >Perhaps I am missing something and there is some large benefit to adding > >this complexity that I do not see. If so, what is it? > > [Govind] Please see above. > > > > > >Right, so I am willing to concede that there is a place for reverse > > > >address translation to support fast handovers, but I don't see this > > > >fairly limited use in the requirements. I don't think this involves > >any > > > >capabilities, mobile node preferences, or any other complications of > > > >that sort. It is fairly simple. The Layer 2 trigger on the AR says > >that > > > >the MN is about to move to a new AP or AR and all that the Layer 2 > > > >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer > >3 > > > >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > > > > > > [Govind] I don't understand your point. As I explained earlier, > >Requirement > > > 1 essentially deals with L2 to L3 mapping. Why doesn't MN's > > > preferences come into picture, if there are 10 APs connected to > >different > > > ARs with different capabilities, ofcourse the MN's preferences > > > come into picture. > > > > > > >I think we agree on this, Govind. Let's move on to where we don't. > > [Govind] Sure. > > > > >The main point I'm making is that if there are multiple > > > APs available and the MN has to choose among them, then clearly > > > this has more power implications than just listening to the beacon and > > > passively forward it to a AR. > > > > > > > >Like I said, the MN, at the IP layer, does not today get to choose in a > >single technology situation. A future L2 might have this capability, but > >I do not see why that means the AR must get involved. > > [Govind] Well for this future L2 that you mention, I have explained this > several times, if the MN has to > connect and disconnect to every AP then get IP connectivity, get capability > info etc and then decide not to use it is a waste of time and bandwidth. > Therefore, to say that a solution that involves the current AR is feasible > is not ok IMHO. > But again, I suggest lets leave this issue for now and get back to > it later when things are more clearer. > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 16:18:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24470 for ; Tue, 26 Mar 2002 16:18:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25656; Tue, 26 Mar 2002 16:15:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25617 for ; Tue, 26 Mar 2002 16:15:37 -0500 (EST) Received: from hotmail.com (f34.law9.hotmail.com [64.4.9.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24278 for ; Tue, 26 Mar 2002 16:15:33 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:15:05 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:15:05 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 16:15:05 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:15:05.0791 (UTC) FILETIME=[4D18C4F0:01C1D50B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, > >But..but.. > >How can you push into the MN's profile that on Tues. March 26 Mr. Fu >forget his network card because he had to take his kid to the doctor? > > jak > [Govind] I have said this several times in my earlier mails but somehow the point was missed. So let me repeat again. Assuming that the forgotten interface card is a WLAN card. For TAR selection this does not matter that Mr Fu's MN forgot his network card. This is because, the TAR selection algorithm (trying to decide the new AR on this Tue March 26) realizes this fact from the absence of reachability (received from the MN) to WLAN APs. This is clearly an implementation issue of the TAR selection algorithm. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 16:18:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24476 for ; Tue, 26 Mar 2002 16:18:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26536 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:18:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25656; Tue, 26 Mar 2002 16:15:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25617 for ; Tue, 26 Mar 2002 16:15:37 -0500 (EST) Received: from hotmail.com (f34.law9.hotmail.com [64.4.9.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24278 for ; Tue, 26 Mar 2002 16:15:33 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:15:05 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:15:05 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 16:15:05 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:15:05.0791 (UTC) FILETIME=[4D18C4F0:01C1D50B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, > >But..but.. > >How can you push into the MN's profile that on Tues. March 26 Mr. Fu >forget his network card because he had to take his kid to the doctor? > > jak > [Govind] I have said this several times in my earlier mails but somehow the point was missed. So let me repeat again. Assuming that the forgotten interface card is a WLAN card. For TAR selection this does not matter that Mr Fu's MN forgot his network card. This is because, the TAR selection algorithm (trying to decide the new AR on this Tue March 26) realizes this fact from the absence of reachability (received from the MN) to WLAN APs. This is clearly an implementation issue of the TAR selection algorithm. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 16:20:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24603 for ; Tue, 26 Mar 2002 16:20:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26233; Tue, 26 Mar 2002 16:17:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26202 for ; Tue, 26 Mar 2002 16:17:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24420 for ; Tue, 26 Mar 2002 16:16:59 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QLGTI10561; Tue, 26 Mar 2002 13:16:29 -0800 (PST) Message-ID: <02c701c1d50b$4573fb70$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Hemant Chaskar'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB7D@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 13:14:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > > This looks good to me, but with a small attention to detail: > > > > What if MN does not want to receive such information or > > does not want to > > receive a part of it. Then, CAR discovery should not blast > > it on MN. > > => The MN will ignore it if it doesn't > need it. > > To > > avoid this, we can slightly rephrase it as: > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > information, along > > with capabilities, *whenever and as required by MN*." > > > => I disagree this is a very strange > argument for removing the MN from the loop. > How does the AR know ?? Do we have to invent > another protocol that the MN should implement > to say no ?! > > Can we please make this simple? > Good point. I don't think we need to include optimizations in the requirements. Let's keep it simple. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 16:20:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24612 for ; Tue, 26 Mar 2002 16:20:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27046 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:20:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26233; Tue, 26 Mar 2002 16:17:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26202 for ; Tue, 26 Mar 2002 16:17:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24420 for ; Tue, 26 Mar 2002 16:16:59 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QLGTI10561; Tue, 26 Mar 2002 13:16:29 -0800 (PST) Message-ID: <02c701c1d50b$4573fb70$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Hemant Chaskar'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB7D@Esealnt861.al.sw.ericsson.se> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 13:14:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > > This looks good to me, but with a small attention to detail: > > > > What if MN does not want to receive such information or > > does not want to > > receive a part of it. Then, CAR discovery should not blast > > it on MN. > > => The MN will ignore it if it doesn't > need it. > > To > > avoid this, we can slightly rephrase it as: > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > information, along > > with capabilities, *whenever and as required by MN*." > > > => I disagree this is a very strange > argument for removing the MN from the loop. > How does the AR know ?? Do we have to invent > another protocol that the MN should implement > to say no ?! > > Can we please make this simple? > Good point. I don't think we need to include optimizations in the requirements. Let's keep it simple. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 16:31:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25518 for ; Tue, 26 Mar 2002 16:31:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28767; Tue, 26 Mar 2002 16:26:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28726 for ; Tue, 26 Mar 2002 16:26:10 -0500 (EST) Received: from hotmail.com (f222.law9.hotmail.com [64.4.9.222]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25000 for ; Tue, 26 Mar 2002 16:26:06 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:25:39 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:25:39 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 16:25:39 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:25:39.0155 (UTC) FILETIME=[C69C7230:01C1D50C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry about a typo in my previous mail. In my reply to James I meant, that it is not necessary to inform the TAR selection algorithm that the card was removed.. I left out the "to inform the TAR selection" by mistake. Ofcourse it is important for the TAR selection algorithm but I meant it can figure out the non availability of the interface card on the fly. Regards, Govind. >James, >> >>But..but.. >> >>How can you push into the MN's profile that on Tues. March 26 Mr. Fu >>forget his network card because he had to take his kid to the doctor? >> >> jak >> > >[Govind] >I have said this several times in my earlier mails but somehow the point >was >missed. So let me repeat again. > >Assuming that the forgotten interface card is a WLAN card. > >For TAR selection this does not matter that Mr Fu's >MN forgot his network card. This is because, the TAR selection >algorithm (trying to decide the new AR on this Tue March 26) >realizes this fact from the absence of reachability >(received from the MN) to WLAN APs. This is clearly an implementation >issue of the TAR selection algorithm. > > > > >Regards, >Govind. > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 16:31:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25525 for ; Tue, 26 Mar 2002 16:31:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00651 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:31:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28767; Tue, 26 Mar 2002 16:26:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28726 for ; Tue, 26 Mar 2002 16:26:10 -0500 (EST) Received: from hotmail.com (f222.law9.hotmail.com [64.4.9.222]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25000 for ; Tue, 26 Mar 2002 16:26:06 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:25:39 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:25:39 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 16:25:39 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:25:39.0155 (UTC) FILETIME=[C69C7230:01C1D50C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Sorry about a typo in my previous mail. In my reply to James I meant, that it is not necessary to inform the TAR selection algorithm that the card was removed.. I left out the "to inform the TAR selection" by mistake. Ofcourse it is important for the TAR selection algorithm but I meant it can figure out the non availability of the interface card on the fly. Regards, Govind. >James, >> >>But..but.. >> >>How can you push into the MN's profile that on Tues. March 26 Mr. Fu >>forget his network card because he had to take his kid to the doctor? >> >> jak >> > >[Govind] >I have said this several times in my earlier mails but somehow the point >was >missed. So let me repeat again. > >Assuming that the forgotten interface card is a WLAN card. > >For TAR selection this does not matter that Mr Fu's >MN forgot his network card. This is because, the TAR selection >algorithm (trying to decide the new AR on this Tue March 26) >realizes this fact from the absence of reachability >(received from the MN) to WLAN APs. This is clearly an implementation >issue of the TAR selection algorithm. > > > > >Regards, >Govind. > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 16:37:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25791 for ; Tue, 26 Mar 2002 16:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00826; Tue, 26 Mar 2002 16:31:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00789 for ; Tue, 26 Mar 2002 16:31:53 -0500 (EST) Received: from hotmail.com (f95.law7.hotmail.com [216.33.237.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25561 for ; Tue, 26 Mar 2002 16:31:49 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:31:22 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:31:21 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 21:31:21 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:31:22.0038 (UTC) FILETIME=[92FC3D60:01C1D50D] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I am bit confused. First the extension to requirement sounded fine to you, now it is not. What is you final opinion? I am not proposing any optimization. There is core flaw in the original requirement that you have proposed. The requirement you proposed means following: As soon as AR sees MN attached to it, it blasts MN with set of GAARs and their capabilities. This is clearly inefficient. This is like empowering the network to spam MN with possibly unwanted information. Sometimes you say MN must be in charge and sometimes you give leeway to network to ignore MN. Why is that? BR, Hemant >From: "James Kempf" >To: "Hesham Soliman \(ERA\)" , >"'Hemant Chaskar'" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > This looks good to me, but with a small attention to detail: > > > > > > What if MN does not want to receive such information or > > > does not want to > > > receive a part of it. Then, CAR discovery should not blast > > > it on MN. > > > > => The MN will ignore it if it doesn't > > need it. > > > > To > > > avoid this, we can slightly rephrase it as: > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > information, along > > > with capabilities, *whenever and as required by MN*." > > > > > => I disagree this is a very strange > > argument for removing the MN from the loop. > > How does the AR know ?? Do we have to invent > > another protocol that the MN should implement > > to say no ?! > > > > Can we please make this simple? > > > >Good point. > >I don't think we need to include optimizations in the requirements. >Let's keep it simple. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 16:39:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26003 for ; Tue, 26 Mar 2002 16:39:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02443; Tue, 26 Mar 2002 16:37:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02406 for ; Tue, 26 Mar 2002 16:37:13 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25785 for ; Tue, 26 Mar 2002 16:37:09 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QLaSI11559; Tue, 26 Mar 2002 13:36:28 -0800 (PST) Message-ID: <033401c1d50e$0ffd6e10$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 13:34:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Premature optimization is never such a good idea. Let's leave it until later. Main issue is that the MN gets the CAR info and makes the TAR decision for ITHO. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Tuesday, March 26, 2002 7:53 PM Subject: RE: [Seamoby] Examples of CAR discovery > Hi Hesham: > > Why do you think that anybody is trying to remove MN from loop? On the > contrary, we are giving even more control to MN of deciding whether it wants > to receive all the information, a part of it or none. > > This fits well in line with giving end host absolute control over CAR > discovery. If we do not have that extension to requirement, it seems that > network is assuming on behalf of MN that MN does need all this information, > when MN actually chooses not to. Of course, nothing prevents us from having > a default case of blasting MN with all GAARs and their requirements. > > Blindly blasting MN with requirements looks very inefficient to me. Further, > this will in the future considerably restrict the detailedness of capability > information that we can to consider. > > Finally, you said below that MN can ignore it. But then, why spend wireless > bandwidth and MN processing power (it takes processing power to ignore too) > to receive unwanted information. > > BR, > Hemant > > > >From: "Hesham Soliman (ERA)" > >To: "'Hemant Chaskar'" , seamoby@ietf.org > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 19:24:19 +0100 > > > > > This looks good to me, but with a small attention to detail: > > > > > > What if MN does not want to receive such information or > > > does not want to > > > receive a part of it. Then, CAR discovery should not blast > > > it on MN. > > > >=> The MN will ignore it if it doesn't > >need it. > > > > To > > > avoid this, we can slightly rephrase it as: > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > information, along > > > with capabilities, *whenever and as required by MN*." > > > > >=> I disagree this is a very strange > >argument for removing the MN from the loop. > >How does the AR know ?? Do we have to invent > >another protocol that the MN should implement > >to say no ?! > > > >Can we please make this simple? > > > >Hesham > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 16:39:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26011 for ; Tue, 26 Mar 2002 16:39:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03247 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:39:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02443; Tue, 26 Mar 2002 16:37:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02406 for ; Tue, 26 Mar 2002 16:37:13 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25785 for ; Tue, 26 Mar 2002 16:37:09 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QLaSI11559; Tue, 26 Mar 2002 13:36:28 -0800 (PST) Message-ID: <033401c1d50e$0ffd6e10$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 13:34:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Premature optimization is never such a good idea. Let's leave it until later. Main issue is that the MN gets the CAR info and makes the TAR decision for ITHO. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Tuesday, March 26, 2002 7:53 PM Subject: RE: [Seamoby] Examples of CAR discovery > Hi Hesham: > > Why do you think that anybody is trying to remove MN from loop? On the > contrary, we are giving even more control to MN of deciding whether it wants > to receive all the information, a part of it or none. > > This fits well in line with giving end host absolute control over CAR > discovery. If we do not have that extension to requirement, it seems that > network is assuming on behalf of MN that MN does need all this information, > when MN actually chooses not to. Of course, nothing prevents us from having > a default case of blasting MN with all GAARs and their requirements. > > Blindly blasting MN with requirements looks very inefficient to me. Further, > this will in the future considerably restrict the detailedness of capability > information that we can to consider. > > Finally, you said below that MN can ignore it. But then, why spend wireless > bandwidth and MN processing power (it takes processing power to ignore too) > to receive unwanted information. > > BR, > Hemant > > > >From: "Hesham Soliman (ERA)" > >To: "'Hemant Chaskar'" , seamoby@ietf.org > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 19:24:19 +0100 > > > > > This looks good to me, but with a small attention to detail: > > > > > > What if MN does not want to receive such information or > > > does not want to > > > receive a part of it. Then, CAR discovery should not blast > > > it on MN. > > > >=> The MN will ignore it if it doesn't > >need it. > > > > To > > > avoid this, we can slightly rephrase it as: > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > information, along > > > with capabilities, *whenever and as required by MN*." > > > > >=> I disagree this is a very strange > >argument for removing the MN from the loop. > >How does the AR know ?? Do we have to invent > >another protocol that the MN should implement > >to say no ?! > > > >Can we please make this simple? > > > >Hesham > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 16:45:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26434 for ; Tue, 26 Mar 2002 16:45:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04456; Tue, 26 Mar 2002 16:43:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04374 for ; Tue, 26 Mar 2002 16:43:09 -0500 (EST) Received: from hotmail.com (f193.law7.hotmail.com [216.33.237.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26264 for ; Tue, 26 Mar 2002 16:43:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:42:37 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:42:37 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 21:42:37 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:42:37.0308 (UTC) FILETIME=[257A43C0:01C1D50F] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I need to clarify the use of terms. Are you saying (1) "GAARs and their capabilities MUST be sent to MN" or (2) "CARs and their capabilities MUST be sent to MN". I am in total disagreement with (1) for the reasons already stated below, I need to think more about (2). Again, disagreement on (1) is not for the sake of optimization, but a fundamentally desirable feature from all angles - MN being in charge, wireless bandwidth and power. BR, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >, >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 13:34:51 -0800 > >Hemant, > >Premature optimization is never such a good idea. Let's leave it until >later. Main issue is that the MN gets the CAR info and makes the TAR >decision for ITHO. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Tuesday, March 26, 2002 7:53 PM >Subject: RE: [Seamoby] Examples of CAR discovery > > > > Hi Hesham: > > > > Why do you think that anybody is trying to remove MN from loop? On the > > contrary, we are giving even more control to MN of deciding whether it >wants > > to receive all the information, a part of it or none. > > > > This fits well in line with giving end host absolute control over CAR > > discovery. If we do not have that extension to requirement, it seems >that > > network is assuming on behalf of MN that MN does need all this >information, > > when MN actually chooses not to. Of course, nothing prevents us from >having > > a default case of blasting MN with all GAARs and their requirements. > > > > Blindly blasting MN with requirements looks very inefficient to me. >Further, > > this will in the future considerably restrict the detailedness of >capability > > information that we can to consider. > > > > Finally, you said below that MN can ignore it. But then, why spend >wireless > > bandwidth and MN processing power (it takes processing power to ignore >too) > > to receive unwanted information. > > > > BR, > > Hemant > > > > > > >From: "Hesham Soliman (ERA)" > > >To: "'Hemant Chaskar'" , seamoby@ietf.org > > >Subject: RE: [Seamoby] Examples of CAR discovery > > >Date: Tue, 26 Mar 2002 19:24:19 +0100 > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > What if MN does not want to receive such information or > > > > does not want to > > > > receive a part of it. Then, CAR discovery should not blast > > > > it on MN. > > > > > >=> The MN will ignore it if it doesn't > > >need it. > > > > > > To > > > > avoid this, we can slightly rephrase it as: > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along > > > > with capabilities, *whenever and as required by MN*." > > > > > > >=> I disagree this is a very strange > > >argument for removing the MN from the loop. > > >How does the AR know ?? Do we have to invent > > >another protocol that the MN should implement > > >to say no ?! > > > > > >Can we please make this simple? > > > > > >Hesham > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 16:45:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26443 for ; Tue, 26 Mar 2002 16:45:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA05143 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:45:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04456; Tue, 26 Mar 2002 16:43:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04374 for ; Tue, 26 Mar 2002 16:43:09 -0500 (EST) Received: from hotmail.com (f193.law7.hotmail.com [216.33.237.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26264 for ; Tue, 26 Mar 2002 16:43:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:42:37 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:42:37 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 21:42:37 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:42:37.0308 (UTC) FILETIME=[257A43C0:01C1D50F] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I need to clarify the use of terms. Are you saying (1) "GAARs and their capabilities MUST be sent to MN" or (2) "CARs and their capabilities MUST be sent to MN". I am in total disagreement with (1) for the reasons already stated below, I need to think more about (2). Again, disagreement on (1) is not for the sake of optimization, but a fundamentally desirable feature from all angles - MN being in charge, wireless bandwidth and power. BR, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >, >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 13:34:51 -0800 > >Hemant, > >Premature optimization is never such a good idea. Let's leave it until >later. Main issue is that the MN gets the CAR info and makes the TAR >decision for ITHO. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Tuesday, March 26, 2002 7:53 PM >Subject: RE: [Seamoby] Examples of CAR discovery > > > > Hi Hesham: > > > > Why do you think that anybody is trying to remove MN from loop? On the > > contrary, we are giving even more control to MN of deciding whether it >wants > > to receive all the information, a part of it or none. > > > > This fits well in line with giving end host absolute control over CAR > > discovery. If we do not have that extension to requirement, it seems >that > > network is assuming on behalf of MN that MN does need all this >information, > > when MN actually chooses not to. Of course, nothing prevents us from >having > > a default case of blasting MN with all GAARs and their requirements. > > > > Blindly blasting MN with requirements looks very inefficient to me. >Further, > > this will in the future considerably restrict the detailedness of >capability > > information that we can to consider. > > > > Finally, you said below that MN can ignore it. But then, why spend >wireless > > bandwidth and MN processing power (it takes processing power to ignore >too) > > to receive unwanted information. > > > > BR, > > Hemant > > > > > > >From: "Hesham Soliman (ERA)" > > >To: "'Hemant Chaskar'" , seamoby@ietf.org > > >Subject: RE: [Seamoby] Examples of CAR discovery > > >Date: Tue, 26 Mar 2002 19:24:19 +0100 > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > What if MN does not want to receive such information or > > > > does not want to > > > > receive a part of it. Then, CAR discovery should not blast > > > > it on MN. > > > > > >=> The MN will ignore it if it doesn't > > >need it. > > > > > > To > > > > avoid this, we can slightly rephrase it as: > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along > > > > with capabilities, *whenever and as required by MN*." > > > > > > >=> I disagree this is a very strange > > >argument for removing the MN from the loop. > > >How does the AR know ?? Do we have to invent > > >another protocol that the MN should implement > > >to say no ?! > > > > > >Can we please make this simple? > > > > > >Hesham > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 16:53:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23761 for ; Tue, 26 Mar 2002 16:06:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA22779 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:06:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21071; Tue, 26 Mar 2002 15:59:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21034 for ; Tue, 26 Mar 2002 15:59:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23382 for ; Tue, 26 Mar 2002 15:59:52 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QKxNI10069; Tue, 26 Mar 2002 12:59:23 -0800 (PST) Message-ID: <026e01c1d508$e1ec9f00$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 12:57:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit But..but.. How can you push into the MN's profile that on Tues. March 26 Mr. Fu forget his network card because he had to take his kid to the doctor? jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Tuesday, March 26, 2002 10:16 AM Subject: Re: [Seamoby] Examples of CAR discovery > > > James, > > >We seem not to be connecting. > > [Govind] I agree and thats what makes any technical discussion interesting > :) > > > > > > > > > > >The only place where I can see CAR discovery involved for a single > > > >technology handover is for reverse address translation, as in > >Eunsoo's > > > >note. > > > > > > > > > > [Govind] That CAR discovery is needed for reverse translation is quite > > > obvious from requirement 1 of the current requirement draft. I thought > > > that was the main idea behind the requirement. Anyways, my previous > > > mail was saying this too. > > > > > > >OK. > > [Govind] We agree. Good! > > > > > [Govind] I agree that the MN *must* be involved too. The main > >disconnect > > > between us is that you assume that the MN has no role whatsoever > > > if the handover is network controlled. Clearly, the handover can be > > > controlled by the network, i.e., tell the MN when to disconnect etc > >but > > > still take into account all of the MN's preferences. I don't > >understand > > > why we are having to get this point across too! > > > >So here is the basic disagreement: > > > >I don't see the point in a complicated protocol for the MN to "express > >its preferences" to the AR, when the > >AR can just hand over the CAR information to the MN and let the MN > >choose. > > [Govind] First, I don't think that it is a "complicated" protocol > as you suggest. As I pointed out it could just be part of the MN's profile. > Second, pushing capabilities down to the MN for its decision > has power,bandwidth and time considerations which one may want to consider. > Again, I am not saying that what you say is not an option. But > saying that the MN MUST be the only one deciding the TAR restricts > the field totally which I think is rather pre-mature. > > > > > >Regarding the MN > > > only knowing which interfaces are powered on. What big difference does > > > this make? > > > >It makes a big difference! If the interface isn't powered on and the AR > >says to the MN "handover to that interface," the MN has just lost > >network connectivity. Don't you agree? > > [Govind] I don't understand, how a "working" TAR selection algorithm which > has MN reachability information as one input will allow this to happen. > > > > > > > >If the network knows what interfaces the MN has then it can > > > advise it to power on at the appropriate time. If it is already > >powered > > > on the MN just discards this. If not it acts on it. If the card is not > > > inserted then it just discards the message too. What is the difficulty > > > that you see here. Maybe you can explain it. > > > > > > > >Please explain to me why you want to do all this complex signaling > >between the network and the MN, when all > >that is required is to simply send the MN the list of CARs and have it > >do the selecting? What does all this > >complexity buy us? > > [Govind] First, I disagree that this is complex. All it requires is > match what APs are available in the neighborhood to what the MN has. > What does this buy us as against pushing everything to the MN: saving power > for the MN. Saving wireless bandwidth is another. But again, the main > disconnect between you and me is not > disagreeing with what you propose as the solution but your seeming > disagreement with any other option. > BTW, aren't we transgressing a bit > too much into solution and TAR selection phase. So I propose that we > have this discussion at a later stage, because we are going to have it > then again :) > > > > >If we accept your proposal, then we are not just doing a CAR discovery > >protocol but also a protocol for having the MN tell the network what > >interfaces it has and what their current state is. > [Govind] But unless the CAR discovery protocol knows what the requirements > for the MN are how does it decide what the CARs for the MN > are? If you read the definition of CAR it says GAARs whose capabilities > can satisfy the MN's requirements As I said, telling the MN's interface > states is not necessary at all. > > This is just too > >complicated. The MN knows this stuff, given the right information, it > >can act on it accordingly without having to get the network involved. I > >simply don't see what adding this level of complexity buys us. > > [Govind] See above. > > >I'm not saying it is infeasible, I'm saying that a rational engineering > >tradeoff between a complex protocol involving signaling MN interface > >state and one letting the MN simply make the choice itself seems, to me > >at least, to go in the direction of the latter. > > [Govind] Again without accepting that complexity of the protocol is very > high :), we should also make sure what effect this decision has on the MN > w.r.t to power and bandwidth. > > > >Can you explain to me what, exactly, sending the MN's interface state > >around buys us that we don't get by simply sending the CAR information > >to the MN and letting it make the choice? > > [Govind] See above. > > > > > > > >The AAA exchange also might not be accurate. Suppose the MN is a > >laptop > > > >and the user forgot that day to put in their WLAN card. The AAA > >record > > > >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR > > > >could hand the MN over to a medium which the MN can't access. > > > > > > [Govind] I thought reachability information *from the MN *is part of > >TAR > > > selection process. If the MN's WLAN card is not inserted, how do you > > > suppose reachability for WLAN APs are got from the MN. So why do you > >think > > > the network will blindly just handover the MN to a WLAN network? > > > > > > >I don't understand your comment. If the WLAN card isn't in, the MN isn't > >going to initiate a MIP handover to an interface that is not there. > >Thus, if the MN is in control of an intertechnology handover, it won't > >disconnect. > >However, if the AR is in control of an intertechnology handover, how is > >it supposed to know that the card isn't there? > > [Govind] No one is arguing that the reachbility information from the MN to > APs is NOT an integral part of the TAR selection process. Once this > reachability information there it does not matter whether the TAR selection > process resides in the network or the MN as far as your issue > is concerned. > > > > >From your comments above, I surmise you would like to see CAR discovery > >include a protocol for communicating the MN's current interface state: > >whether the card is there, whether it is powered on, etc., to the AR. > > [Govind] Nope I'm not saying this is necessary. For TAR selection the > generic statement that the MN's requirements MUST be made known to CAR > discovery is more than enough. > > Waking up an already awake device or trying to wake up an non-existent > device too such a requirement will just provide an optimization to > avoid some messages. > > > >My > >contention is that this is unnecessarily complex and having the MN > >control the handover would provide exactly the same functionality at > >much less protocol complexity cost. > > > >Perhaps I am missing something and there is some large benefit to adding > >this complexity that I do not see. If so, what is it? > > [Govind] Please see above. > > > > > >Right, so I am willing to concede that there is a place for reverse > > > >address translation to support fast handovers, but I don't see this > > > >fairly limited use in the requirements. I don't think this involves > >any > > > >capabilities, mobile node preferences, or any other complications of > > > >that sort. It is fairly simple. The Layer 2 trigger on the AR says > >that > > > >the MN is about to move to a new AP or AR and all that the Layer 2 > > > >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer > >3 > > > >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP. > > > > > > [Govind] I don't understand your point. As I explained earlier, > >Requirement > > > 1 essentially deals with L2 to L3 mapping. Why doesn't MN's > > > preferences come into picture, if there are 10 APs connected to > >different > > > ARs with different capabilities, ofcourse the MN's preferences > > > come into picture. > > > > > > >I think we agree on this, Govind. Let's move on to where we don't. > > [Govind] Sure. > > > > >The main point I'm making is that if there are multiple > > > APs available and the MN has to choose among them, then clearly > > > this has more power implications than just listening to the beacon and > > > passively forward it to a AR. > > > > > > > >Like I said, the MN, at the IP layer, does not today get to choose in a > >single technology situation. A future L2 might have this capability, but > >I do not see why that means the AR must get involved. > > [Govind] Well for this future L2 that you mention, I have explained this > several times, if the MN has to > connect and disconnect to every AP then get IP connectivity, get capability > info etc and then decide not to use it is a waste of time and bandwidth. > Therefore, to say that a solution that involves the current AR is feasible > is not ok IMHO. > But again, I suggest lets leave this issue for now and get back to > it later when things are more clearer. > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:09:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27125 for ; Tue, 26 Mar 2002 17:09:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10161; Tue, 26 Mar 2002 17:04:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10130 for ; Tue, 26 Mar 2002 17:04:20 -0500 (EST) Received: from hotmail.com (f182.law9.hotmail.com [64.4.9.182]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26998 for ; Tue, 26 Mar 2002 17:04:15 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:03:48 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:03:48 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 17:03:48 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:03:48.0691 (UTC) FILETIME=[1B47EA30:01C1D512] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello James, Please see whether the following at least is reasonable enough not to preclude AR based CAR discovery at this moment. 1. For a MN with a single 802.11 interface which is connected to an AR, it can scan for other APs in the neighborhood. Can you tell me how this MN will do capability discovery of the ARs connected to the other APs in the neighborhood without loosing connectivity to the current AR and AP? 2. Also, there are engineering considerations such as bandwidth and power constraints for the MN in adopting an AR-assisted (with help from the MN) CAR discovery process and an AR-unassisted CAR discovery process. Is this fair enough? Regards, Govind. > >Sorry, Dirk, but I thought we settled this in Minneapolis. > >The point of requirements is to constrain the solution set sufficiently >that the selected solution solves the problem in a way that makes >engineering sense. I have not yet heard an argument as to why AR-based >CAR discovery makes engineering sense. > >If you think the requirements should allow that possibility, then please >give me an argument why. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:09:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27136 for ; Tue, 26 Mar 2002 17:09:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11560 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:09:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10161; Tue, 26 Mar 2002 17:04:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10130 for ; Tue, 26 Mar 2002 17:04:20 -0500 (EST) Received: from hotmail.com (f182.law9.hotmail.com [64.4.9.182]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26998 for ; Tue, 26 Mar 2002 17:04:15 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:03:48 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:03:48 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 17:03:48 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:03:48.0691 (UTC) FILETIME=[1B47EA30:01C1D512] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello James, Please see whether the following at least is reasonable enough not to preclude AR based CAR discovery at this moment. 1. For a MN with a single 802.11 interface which is connected to an AR, it can scan for other APs in the neighborhood. Can you tell me how this MN will do capability discovery of the ARs connected to the other APs in the neighborhood without loosing connectivity to the current AR and AP? 2. Also, there are engineering considerations such as bandwidth and power constraints for the MN in adopting an AR-assisted (with help from the MN) CAR discovery process and an AR-unassisted CAR discovery process. Is this fair enough? Regards, Govind. > >Sorry, Dirk, but I thought we settled this in Minneapolis. > >The point of requirements is to constrain the solution set sufficiently >that the selected solution solves the problem in a way that makes >engineering sense. I have not yet heard an argument as to why AR-based >CAR discovery makes engineering sense. > >If you think the requirements should allow that possibility, then please >give me an argument why. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:15:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27334 for ; Tue, 26 Mar 2002 17:15:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12650; Tue, 26 Mar 2002 17:12:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12606 for ; Tue, 26 Mar 2002 17:12:35 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27268 for ; Tue, 26 Mar 2002 17:12:30 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA06723 for ; Tue, 26 Mar 2002 23:09:41 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:12:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Still catching up: Satish wrote: ...... > > Also there should be provision for an AR to do a TAR selection given the > fact that the service provider can have policies that can force a mobiles to > handover due to load conditions, inorder to provide better QoS when the load > on other ARs or the underlying L2 becomes available (One of the most > critical understanding of a 4G network is that there are a host of L2s with > a common IP layer and above) in the present understanding and spectrum > sharing in future SDR scenarios (Please note that inter-technology handover > is where much in the understanding of future 4G and SDR networks - we dont > want our CAR protocol to undergo a lot of changes when the notion of > seamless ness as required by a 4G or an SDR network hits the scene) . No, wait, stop. The handover policies, requirements etc. of a particular network will guide or dictate what the relevant subset of GAARs are for that particular network and access technology. But unless you *dictate* that only MNs with only that particular network and access technology may use CAR discovery, it *will* have to be the MN that does the GAAR -> CAR and CAR -> TAR steps. If nothing else, it is only the MN that carries knowledge of the User's particular policy with respect to cost, and which QoS requirements the applications running at the moment has, which network cards are there today, as James mentioned, and so on. And I really don't think it is reasonable for the User to have information about his policies or running applications or their QoS requirements gratuitously transmitted to whatever APs he is currently connected to. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:15:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27342 for ; Tue, 26 Mar 2002 17:15:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13259 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:15:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12650; Tue, 26 Mar 2002 17:12:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12606 for ; Tue, 26 Mar 2002 17:12:35 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27268 for ; Tue, 26 Mar 2002 17:12:30 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA06723 for ; Tue, 26 Mar 2002 23:09:41 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:12:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <001a01c1d3da$31c8f7b0$9224010a@SATISHJ> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Still catching up: Satish wrote: ...... > > Also there should be provision for an AR to do a TAR selection given the > fact that the service provider can have policies that can force a mobiles to > handover due to load conditions, inorder to provide better QoS when the load > on other ARs or the underlying L2 becomes available (One of the most > critical understanding of a 4G network is that there are a host of L2s with > a common IP layer and above) in the present understanding and spectrum > sharing in future SDR scenarios (Please note that inter-technology handover > is where much in the understanding of future 4G and SDR networks - we dont > want our CAR protocol to undergo a lot of changes when the notion of > seamless ness as required by a 4G or an SDR network hits the scene) . No, wait, stop. The handover policies, requirements etc. of a particular network will guide or dictate what the relevant subset of GAARs are for that particular network and access technology. But unless you *dictate* that only MNs with only that particular network and access technology may use CAR discovery, it *will* have to be the MN that does the GAAR -> CAR and CAR -> TAR steps. If nothing else, it is only the MN that carries knowledge of the User's particular policy with respect to cost, and which QoS requirements the applications running at the moment has, which network cards are there today, as James mentioned, and so on. And I really don't think it is reasonable for the User to have information about his policies or running applications or their QoS requirements gratuitously transmitted to whatever APs he is currently connected to. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:16:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27380 for ; Tue, 26 Mar 2002 17:16:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11996; Tue, 26 Mar 2002 17:11:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11956 for ; Tue, 26 Mar 2002 17:10:59 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27214 for ; Tue, 26 Mar 2002 17:10:55 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id XAA06688; Tue, 26 Mar 2002 23:07:58 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:10:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Catching up on this thread. Sorry if this point has already been made: Hemant wrote: ...> > - The problem statement does not advocate any specific way (network-based or > MN-based or hybrid) of performing CAR discovery. I believe this is pointing us in the wrong direction. I believe it is an essential part of CAR discovery that it is MN-centric. In other words, CAR discovery is the process of the Networks, Current Active Access Points and the MN itself (through stored information, scanning, this, that, and whatever other magic is available) providing *the MN* with information that *the MN* can use to assemble the most appropriate list of GAARs for *that MN* at that moment, from which *the MN* can destill its CARs. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:16:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27388 for ; Tue, 26 Mar 2002 17:16:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13521 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:16:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11996; Tue, 26 Mar 2002 17:11:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11956 for ; Tue, 26 Mar 2002 17:10:59 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27214 for ; Tue, 26 Mar 2002 17:10:55 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id XAA06688; Tue, 26 Mar 2002 23:07:58 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:10:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Catching up on this thread. Sorry if this point has already been made: Hemant wrote: ...> > - The problem statement does not advocate any specific way (network-based or > MN-based or hybrid) of performing CAR discovery. I believe this is pointing us in the wrong direction. I believe it is an essential part of CAR discovery that it is MN-centric. In other words, CAR discovery is the process of the Networks, Current Active Access Points and the MN itself (through stored information, scanning, this, that, and whatever other magic is available) providing *the MN* with information that *the MN* can use to assemble the most appropriate list of GAARs for *that MN* at that moment, from which *the MN* can destill its CARs. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:17:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27425 for ; Tue, 26 Mar 2002 17:17:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12201; Tue, 26 Mar 2002 17:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12153 for ; Tue, 26 Mar 2002 17:11:29 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27237 for ; Tue, 26 Mar 2002 17:11:23 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA06701; Tue, 26 Mar 2002 23:08:12 +0100 From: "Henrik Levkowetz" To: "James Kempf" , "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:11:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <001f01c1d4e3$efc58ad0$7e6015ac@T23KEMPF> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I support James' proposal. Regards, Henrik James wrote: > > Hemant, > > I prefer wording that specifically requires the MN to be involved in > getting the CAR information. Thus: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > This is clear and unambiguous about what network entity is in control > during an intertechnology handover. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: > Sent: Monday, March 25, 2002 9:32 PM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi: > > > > Some comments below: > > > > > > >From: "James Kempf" > > >To: "Eunsoo Shim" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > > > Please just let me remind you that the CAR discovery protocol also > > >provides > > > > mapping of L2 ID to IP address of the new AR which is necessary > for > > >the > > > > low-latency handoff mechanism proposed in the MobileIP WG. So > there is > > >a > > > > case CAR discovery is helpful for single technology handovers. > > > > > > > > > >OK, so what you are saying is that there are two cases: > > > > > >1) Provding the MN with CAR information on what choices are available > > >or, possibly, when the MN moves into an area where a new choice is > > >possible, like moving into a hot spot area, for MNs that have > multiple > > >interfaces. > > > > > >2) Providing the AR with reverse address translation for CARs for MNs > > >that have single interfaces and want fast handover support. > > > > > > > >I agree. > > > > > >I don't get the feeling that these two cases are clearly delineated > in > > >the requirements. In fact, they seem to me like they are really two > > >separate protocols. > > > > [HC] From the requirements perspective, what all the recent discussion > is > > about is probably the following requirement text (with supporting line > that > > CAR discovery is about comparing MN's requirements with GAAR > capabilities > > and slecting CARs from GAARs): > > > > "CAR discovery output MUST be retrievable, possibly selectively, by > MN". > > Also, I assume that there will the the following requirement as well > (I > > think that this was posted before IETF53 and I also saw some WG > members > > endorse it in IETF53 meeting): "MN requirements MUST be made available > for > > CAR discovery". > > > > This would mandate a CAR discovery functionality as follows: > > > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> > MN > > ^ > > | > > | > > Capability information about GAARs > > > > Again, "CAR discovery module" can reside completely in MN, completely > in AR > > or combination depending upon environment, availability of > multiplicity of > > interfaces with MN etc. Further, the nature of MN requirements input > and > > corresponding output depends upon the environement in which CAR > discovery is > > being used. Also, whether the solution is organized into seperate > protocols > > or single protocol is a solution-specific aspect. > > > > (Note: The first requirement in requiremnet spec already says the > address > > translation part. We can keep it so given its importance for > fast/seamless > > handoffs, though it can be subsumed into above generic model (with > "one > > parameter = L2 id", "one capability information about GAARs = L2 to IP > addr. > > maps" and "output=IP address of CAR").) > > > > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding > your > > > > question, couldn't we imagine a case when a network provider wants > do > > >a kind > > > > of load-balancing between different access networks in the > wireless > > >overlay > > > > network? > > > > > > > > > >Sure, but I think that's a very special case. The more general case > (and > > >in fact, the case that is showing up *today*) is that one network > > >provider owns one medium and the other another. Example: at the > airport, > > >the cellular provider owns the CDMA network and some WLAN provider > owns > > >the WLAN network. > > > > [HC]There is a concept of operator owned WLAN that is actually > catching up. > > Some systems are already rolled out in Europe if I am not mistaken. > So, both > > cases are very important - two media owned by two operators and two > media > > owned by single operator. > > > > BR, > > Hemant > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:17:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27434 for ; Tue, 26 Mar 2002 17:17:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13811 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:17:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12201; Tue, 26 Mar 2002 17:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12153 for ; Tue, 26 Mar 2002 17:11:29 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27237 for ; Tue, 26 Mar 2002 17:11:23 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA06701; Tue, 26 Mar 2002 23:08:12 +0100 From: "Henrik Levkowetz" To: "James Kempf" , "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:11:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <001f01c1d4e3$efc58ad0$7e6015ac@T23KEMPF> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I support James' proposal. Regards, Henrik James wrote: > > Hemant, > > I prefer wording that specifically requires the MN to be involved in > getting the CAR information. Thus: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > This is clear and unambiguous about what network entity is in control > during an intertechnology handover. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: > Sent: Monday, March 25, 2002 9:32 PM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi: > > > > Some comments below: > > > > > > >From: "James Kempf" > > >To: "Eunsoo Shim" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Mon, 25 Mar 2002 11:03:08 -0800 > > > > > > > Please just let me remind you that the CAR discovery protocol also > > >provides > > > > mapping of L2 ID to IP address of the new AR which is necessary > for > > >the > > > > low-latency handoff mechanism proposed in the MobileIP WG. So > there is > > >a > > > > case CAR discovery is helpful for single technology handovers. > > > > > > > > > >OK, so what you are saying is that there are two cases: > > > > > >1) Provding the MN with CAR information on what choices are available > > >or, possibly, when the MN moves into an area where a new choice is > > >possible, like moving into a hot spot area, for MNs that have > multiple > > >interfaces. > > > > > >2) Providing the AR with reverse address translation for CARs for MNs > > >that have single interfaces and want fast handover support. > > > > > > > >I agree. > > > > > >I don't get the feeling that these two cases are clearly delineated > in > > >the requirements. In fact, they seem to me like they are really two > > >separate protocols. > > > > [HC] From the requirements perspective, what all the recent discussion > is > > about is probably the following requirement text (with supporting line > that > > CAR discovery is about comparing MN's requirements with GAAR > capabilities > > and slecting CARs from GAARs): > > > > "CAR discovery output MUST be retrievable, possibly selectively, by > MN". > > Also, I assume that there will the the following requirement as well > (I > > think that this was posted before IETF53 and I also saw some WG > members > > endorse it in IETF53 meeting): "MN requirements MUST be made available > for > > CAR discovery". > > > > This would mandate a CAR discovery functionality as follows: > > > > MN Requirements --(parameters)--> CAR Discovery Module --(output)--> > MN > > ^ > > | > > | > > Capability information about GAARs > > > > Again, "CAR discovery module" can reside completely in MN, completely > in AR > > or combination depending upon environment, availability of > multiplicity of > > interfaces with MN etc. Further, the nature of MN requirements input > and > > corresponding output depends upon the environement in which CAR > discovery is > > being used. Also, whether the solution is organized into seperate > protocols > > or single protocol is a solution-specific aspect. > > > > (Note: The first requirement in requiremnet spec already says the > address > > translation part. We can keep it so given its importance for > fast/seamless > > handoffs, though it can be subsumed into above generic model (with > "one > > parameter = L2 id", "one capability information about GAARs = L2 to IP > addr. > > maps" and "output=IP address of CAR").) > > > > > > > > > I understand the IETF is pro-end-point-control. Anyway, regarding > your > > > > question, couldn't we imagine a case when a network provider wants > do > > >a kind > > > > of load-balancing between different access networks in the > wireless > > >overlay > > > > network? > > > > > > > > > >Sure, but I think that's a very special case. The more general case > (and > > >in fact, the case that is showing up *today*) is that one network > > >provider owns one medium and the other another. Example: at the > airport, > > >the cellular provider owns the CDMA network and some WLAN provider > owns > > >the WLAN network. > > > > [HC]There is a concept of operator owned WLAN that is actually > catching up. > > Some systems are already rolled out in Europe if I am not mistaken. > So, both > > cases are very important - two media owned by two operators and two > media > > owned by single operator. > > > > BR, > > Hemant > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:17:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27472 for ; Tue, 26 Mar 2002 17:17:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12469; Tue, 26 Mar 2002 17:12:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12439 for ; Tue, 26 Mar 2002 17:12:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27260 for ; Tue, 26 Mar 2002 17:12:10 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMBgI13024; Tue, 26 Mar 2002 14:11:42 -0800 (PST) Message-ID: <037701c1d512$fbf464f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:10:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit How can the TAR selection algorithm realize the absence of reachability? If the subscriber profile says that the MN has a WLAN card in and, in fact, it doesn't, then there either a) there needs to be some complicated protocol to tell the AR or b) the AR will make a mistake and move the MN to a medium that it currently doesn't have. I maintain that a) is too complicated and b) is an error. And, no, I don't think this is TBD by the TAR implementation. It lies at the heart of whether a network-only controlled algorithm would work for ITHO. jak > James, > > > >But..but.. > > > >How can you push into the MN's profile that on Tues. March 26 Mr. Fu > >forget his network card because he had to take his kid to the doctor? > > > > jak > > > > [Govind] > I have said this several times in my earlier mails but somehow the point was > missed. So let me repeat again. > > Assuming that the forgotten interface card is a WLAN card. > > For TAR selection this does not matter that Mr Fu's > MN forgot his network card. This is because, the TAR selection > algorithm (trying to decide the new AR on this Tue March 26) > realizes this fact from the absence of reachability > (received from the MN) to WLAN APs. This is clearly an implementation > issue of the TAR selection algorithm. > > > > > Regards, > Govind. > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:17:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27482 for ; Tue, 26 Mar 2002 17:17:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13947 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:17:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12469; Tue, 26 Mar 2002 17:12:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12439 for ; Tue, 26 Mar 2002 17:12:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27260 for ; Tue, 26 Mar 2002 17:12:10 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMBgI13024; Tue, 26 Mar 2002 14:11:42 -0800 (PST) Message-ID: <037701c1d512$fbf464f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:10:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit How can the TAR selection algorithm realize the absence of reachability? If the subscriber profile says that the MN has a WLAN card in and, in fact, it doesn't, then there either a) there needs to be some complicated protocol to tell the AR or b) the AR will make a mistake and move the MN to a medium that it currently doesn't have. I maintain that a) is too complicated and b) is an error. And, no, I don't think this is TBD by the TAR implementation. It lies at the heart of whether a network-only controlled algorithm would work for ITHO. jak > James, > > > >But..but.. > > > >How can you push into the MN's profile that on Tues. March 26 Mr. Fu > >forget his network card because he had to take his kid to the doctor? > > > > jak > > > > [Govind] > I have said this several times in my earlier mails but somehow the point was > missed. So let me repeat again. > > Assuming that the forgotten interface card is a WLAN card. > > For TAR selection this does not matter that Mr Fu's > MN forgot his network card. This is because, the TAR selection > algorithm (trying to decide the new AR on this Tue March 26) > realizes this fact from the absence of reachability > (received from the MN) to WLAN APs. This is clearly an implementation > issue of the TAR selection algorithm. > > > > > Regards, > Govind. > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:21:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27579 for ; Tue, 26 Mar 2002 17:21:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14467; Tue, 26 Mar 2002 17:19:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14431 for ; Tue, 26 Mar 2002 17:19:35 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27556 for ; Tue, 26 Mar 2002 17:19:32 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMJ3I13295; Tue, 26 Mar 2002 14:19:03 -0800 (PST) Message-ID: <039801c1d514$02e419d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:17:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit On second thought, let's keep it simple. Premature optimization often has unintended consequences. Sorry for the confusion. I'm having trouble keeping up with 200+ emails a day. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Tuesday, March 26, 2002 9:31 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > I am bit confused. First the extension to requirement sounded fine to you, > now it is not. What is you final opinion? > > I am not proposing any optimization. There is core flaw in the original > requirement that you have proposed. The requirement you proposed means > following: As soon as AR sees MN attached to it, it blasts MN with set of > GAARs and their capabilities. This is clearly inefficient. This is like > empowering the network to spam MN with possibly unwanted information. > > Sometimes you say MN must be in charge and sometimes you give leeway to > network to ignore MN. Why is that? > > BR, > Hemant > > > >From: "James Kempf" > >To: "Hesham Soliman \(ERA\)" , > >"'Hemant Chaskar'" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > What if MN does not want to receive such information or > > > > does not want to > > > > receive a part of it. Then, CAR discovery should not blast > > > > it on MN. > > > > > > => The MN will ignore it if it doesn't > > > need it. > > > > > > To > > > > avoid this, we can slightly rephrase it as: > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along > > > > with capabilities, *whenever and as required by MN*." > > > > > > > => I disagree this is a very strange > > > argument for removing the MN from the loop. > > > How does the AR know ?? Do we have to invent > > > another protocol that the MN should implement > > > to say no ?! > > > > > > Can we please make this simple? > > > > > > >Good point. > > > >I don't think we need to include optimizations in the requirements. > >Let's keep it simple. > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27885 for ; Tue, 26 Mar 2002 17:26:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15874; Tue, 26 Mar 2002 17:24:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15841 for ; Tue, 26 Mar 2002 17:24:13 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27759 for ; Tue, 26 Mar 2002 17:24:10 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA06919; Tue, 26 Mar 2002 23:21:20 +0100 From: "Henrik Levkowetz" To: Cc: Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 23:24:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk wrote: > However, for the openness of implementing any kind of TAR selection > schemes, the current requirements take care of this by demanding > the usability of CAR information by others (see exact wording in > the document). With that requirement, CAR discovery solutions must > enable to implement ANY kind of TAR selection, whether AR- or > MN-based. Hence, it does really not matter whether the final > authority of selection is the MN or any other network-related > entity, since this question is simply out of scope. Mmm, maybe the point which needs to be made here is that any list of GAARs which could be assembled by a particular network or AP may be incomplete, and the only entity in a position to determine the relevant list of GAARs, and from there the CARs, will be the MN. So I believe this non-commital formulation of the process may actually be harmful. The operators of any particular access technology network will of course attempt to optimize the use of their network, and network directed handovers *whithin one access technology network* will be taken care of by that network, but the MN cannot even afford to believe that a particular network may not discriminate against others in its presentation of GAARs (although we should define a protocol which does not encourage such discrimination). So the MN should be the central point, already in the GAAR determination. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:26:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27892 for ; Tue, 26 Mar 2002 17:26:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16421 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:26:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15874; Tue, 26 Mar 2002 17:24:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15841 for ; Tue, 26 Mar 2002 17:24:13 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27759 for ; Tue, 26 Mar 2002 17:24:10 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA06919; Tue, 26 Mar 2002 23:21:20 +0100 From: "Henrik Levkowetz" To: Cc: Subject: RE: [Seamoby] CAR discovery Date: Tue, 26 Mar 2002 23:24:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk wrote: > However, for the openness of implementing any kind of TAR selection > schemes, the current requirements take care of this by demanding > the usability of CAR information by others (see exact wording in > the document). With that requirement, CAR discovery solutions must > enable to implement ANY kind of TAR selection, whether AR- or > MN-based. Hence, it does really not matter whether the final > authority of selection is the MN or any other network-related > entity, since this question is simply out of scope. Mmm, maybe the point which needs to be made here is that any list of GAARs which could be assembled by a particular network or AP may be incomplete, and the only entity in a position to determine the relevant list of GAARs, and from there the CARs, will be the MN. So I believe this non-commital formulation of the process may actually be harmful. The operators of any particular access technology network will of course attempt to optimize the use of their network, and network directed handovers *whithin one access technology network* will be taken care of by that network, but the MN cannot even afford to believe that a particular network may not discriminate against others in its presentation of GAARs (although we should define a protocol which does not encourage such discrimination). So the MN should be the central point, already in the GAAR determination. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:28:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25799 for ; Tue, 26 Mar 2002 16:37:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02468 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 16:37:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00826; Tue, 26 Mar 2002 16:31:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00789 for ; Tue, 26 Mar 2002 16:31:53 -0500 (EST) Received: from hotmail.com (f95.law7.hotmail.com [216.33.237.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25561 for ; Tue, 26 Mar 2002 16:31:49 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 13:31:22 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 21:31:21 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 21:31:21 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 21:31:22.0038 (UTC) FILETIME=[92FC3D60:01C1D50D] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: I am bit confused. First the extension to requirement sounded fine to you, now it is not. What is you final opinion? I am not proposing any optimization. There is core flaw in the original requirement that you have proposed. The requirement you proposed means following: As soon as AR sees MN attached to it, it blasts MN with set of GAARs and their capabilities. This is clearly inefficient. This is like empowering the network to spam MN with possibly unwanted information. Sometimes you say MN must be in charge and sometimes you give leeway to network to ignore MN. Why is that? BR, Hemant >From: "James Kempf" >To: "Hesham Soliman \(ERA\)" , >"'Hemant Chaskar'" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > This looks good to me, but with a small attention to detail: > > > > > > What if MN does not want to receive such information or > > > does not want to > > > receive a part of it. Then, CAR discovery should not blast > > > it on MN. > > > > => The MN will ignore it if it doesn't > > need it. > > > > To > > > avoid this, we can slightly rephrase it as: > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > information, along > > > with capabilities, *whenever and as required by MN*." > > > > > => I disagree this is a very strange > > argument for removing the MN from the loop. > > How does the AR know ?? Do we have to invent > > another protocol that the MN should implement > > to say no ?! > > > > Can we please make this simple? > > > >Good point. > >I don't think we need to include optimizations in the requirements. >Let's keep it simple. > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:36:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28334 for ; Tue, 26 Mar 2002 17:36:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18263; Tue, 26 Mar 2002 17:33:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18232 for ; Tue, 26 Mar 2002 17:33:21 -0500 (EST) Received: from hotmail.com (f188.law9.hotmail.com [64.4.9.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28283 for ; Tue, 26 Mar 2002 17:33:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:32:52 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:32:51 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:32:51 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:32:52.0007 (UTC) FILETIME=[2A60D370:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Because one of the inputs to TAR selection is the reachability information from the MN. Irrespective of what the MN's profile says if the MN does not inform that it can hear to a particular AP (which is of a particular technology) then why will the TAR selection algorithm hand over to the AR which controls that AP? I thought reachability information from the MNs includes what APs it can hear and if a interface is not present why will the MN give information that it can hear an AP of a matching technology? Clearly if the AR clearly intreprets this lack of information from the MN as a signal to hand it over to that very AR then there something wrong in the implementation. There is no need for any complicated protocol. When you look at the issues draft you will see that TAR selection has the reachability information from the MN as one of its input. > >How can the TAR selection algorithm realize the absence of >reachability? If the subscriber profile says that the MN has >a WLAN card in and, in fact, it doesn't, then there either a) there >needs >to be some complicated protocol to tell the AR or b) the AR >will make a mistake and move the MN to a medium that >it currently doesn't have. > >I maintain that a) is too complicated and b) is an error. > >And, no, I don't think this is TBD by the TAR implementation. It >lies at the heart of whether a network-only controlled algorithm >would work for ITHO. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:37:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28369 for ; Tue, 26 Mar 2002 17:37:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18523; Tue, 26 Mar 2002 17:34:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18471 for ; Tue, 26 Mar 2002 17:34:03 -0500 (EST) Received: from hotmail.com (f218.law9.hotmail.com [64.4.9.218]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28290 for ; Tue, 26 Mar 2002 17:34:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:33:34 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:33:33 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:33:33 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:33:34.0049 (UTC) FILETIME=[436FED10:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Because one of the inputs to TAR selection is the reachability information from the MN. Irrespective of what the MN's profile says if the MN does not inform that it can hear to a particular AP (which is of a particular technology) then why will the TAR selection algorithm hand over to the AR which controls that AP? I thought reachability information from the MNs includes what APs it can hear and if a interface is not present why will the MN give information that it can hear an AP of a matching technology? Clearly if the AR clearly intreprets this lack of information from the MN as a signal to hand it over to that very AR then there something wrong in the implementation. There is no need for any complicated protocol. When you look at the issues draft you will see that TAR selection has the reachability information from the MN as one of its input. > >How can the TAR selection algorithm realize the absence of >reachability? If the subscriber profile says that the MN has >a WLAN card in and, in fact, it doesn't, then there either a) there >needs >to be some complicated protocol to tell the AR or b) the AR >will make a mistake and move the MN to a medium that >it currently doesn't have. > >I maintain that a) is too complicated and b) is an error. > >And, no, I don't think this is TBD by the TAR implementation. It >lies at the heart of whether a network-only controlled algorithm >would work for ITHO. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:37:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28380 for ; Tue, 26 Mar 2002 17:37:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19280 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:37:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18523; Tue, 26 Mar 2002 17:34:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18471 for ; Tue, 26 Mar 2002 17:34:03 -0500 (EST) Received: from hotmail.com (f218.law9.hotmail.com [64.4.9.218]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28290 for ; Tue, 26 Mar 2002 17:34:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:33:34 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:33:33 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:33:33 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:33:34.0049 (UTC) FILETIME=[436FED10:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Because one of the inputs to TAR selection is the reachability information from the MN. Irrespective of what the MN's profile says if the MN does not inform that it can hear to a particular AP (which is of a particular technology) then why will the TAR selection algorithm hand over to the AR which controls that AP? I thought reachability information from the MNs includes what APs it can hear and if a interface is not present why will the MN give information that it can hear an AP of a matching technology? Clearly if the AR clearly intreprets this lack of information from the MN as a signal to hand it over to that very AR then there something wrong in the implementation. There is no need for any complicated protocol. When you look at the issues draft you will see that TAR selection has the reachability information from the MN as one of its input. > >How can the TAR selection algorithm realize the absence of >reachability? If the subscriber profile says that the MN has >a WLAN card in and, in fact, it doesn't, then there either a) there >needs >to be some complicated protocol to tell the AR or b) the AR >will make a mistake and move the MN to a medium that >it currently doesn't have. > >I maintain that a) is too complicated and b) is an error. > >And, no, I don't think this is TBD by the TAR implementation. It >lies at the heart of whether a network-only controlled algorithm >would work for ITHO. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:39:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28462 for ; Tue, 26 Mar 2002 17:39:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18356; Tue, 26 Mar 2002 17:33:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18291 for ; Tue, 26 Mar 2002 17:33:28 -0500 (EST) Received: from hotmail.com (f139.law7.hotmail.com [216.33.237.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28286 for ; Tue, 26 Mar 2002 17:33:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:32:58 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:32:58 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 22:32:58 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:32:58.0554 (UTC) FILETIME=[2E47D1A0:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: There is no doubt that MN-centric is fundamental point. But, here is what I mean by this statement: CAR discovery in its simplest terms is about comparing "MN requirements" with "GAAR capabilities". The "place" where this comparison is done (processor MIPs for comparison instructions are executed) is solution-specific and neither relevant in problem statement phase nor requirements phase. An example where such comparison may occur in network is when there is only one interface on MN and it can listen only to radio beacons of surrounding access points. This is similar to break-before-make handoff case. Here, MN cannot receive capabilities of GAARs without letting go the previous connection. Do you think that such cases are not relevant and we should exclude such cases right at the problem statement/requirements stage? BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 23:10:47 +0100 > >Catching up on this thread. Sorry if this point has already >been made: > >Hemant wrote: >...> > > - The problem statement does not advocate any specific way >(network-based or > > MN-based or hybrid) of performing CAR discovery. > >I believe this is pointing us in the wrong direction. I believe it is >an essential part of CAR discovery that it is MN-centric. In other >words, CAR discovery is the process of the Networks, Current Active >Access Points and the MN itself (through stored information, scanning, >this, that, and whatever other magic is available) providing *the MN* >with information that *the MN* can use to assemble the most appropriate >list of GAARs for *that MN* at that moment, from which *the MN* can >destill its CARs. > > Regards, > Henrik > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:42:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28514 for ; Tue, 26 Mar 2002 17:42:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19220; Tue, 26 Mar 2002 17:36:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19183 for ; Tue, 26 Mar 2002 17:36:53 -0500 (EST) Received: from hotmail.com (f214.law7.hotmail.com [216.33.237.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28365 for ; Tue, 26 Mar 2002 17:36:50 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:36:23 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:36:22 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 22:36:22 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:36:23.0090 (UTC) FILETIME=[A8318920:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Simplicity should not compromise fundamentally desirable features. The requirement is fundamentally flawed. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 14:17:26 -0800 > >On second thought, let's keep it simple. Premature optimization often >has unintended consequences. > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails >a day. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Tuesday, March 26, 2002 9:31 PM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi James: > > > > I am bit confused. First the extension to requirement sounded fine to >you, > > now it is not. What is you final opinion? > > > > I am not proposing any optimization. There is core flaw in the >original > > requirement that you have proposed. The requirement you proposed means > > following: As soon as AR sees MN attached to it, it blasts MN with set >of > > GAARs and their capabilities. This is clearly inefficient. This is >like > > empowering the network to spam MN with possibly unwanted information. > > > > Sometimes you say MN must be in charge and sometimes you give leeway >to > > network to ignore MN. Why is that? > > > > BR, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Hesham Soliman \(ERA\)" , > > >"'Hemant Chaskar'" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > What if MN does not want to receive such information or > > > > > does not want to > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > it on MN. > > > > > > > > => The MN will ignore it if it doesn't > > > > need it. > > > > > > > > To > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > => I disagree this is a very strange > > > > argument for removing the MN from the loop. > > > > How does the AR know ?? Do we have to invent > > > > another protocol that the MN should implement > > > > to say no ?! > > > > > > > > Can we please make this simple? > > > > > > > > > >Good point. > > > > > >I don't think we need to include optimizations in the requirements. > > >Let's keep it simple. > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:42:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28524 for ; Tue, 26 Mar 2002 17:42:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20622 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:42:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19220; Tue, 26 Mar 2002 17:36:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19183 for ; Tue, 26 Mar 2002 17:36:53 -0500 (EST) Received: from hotmail.com (f214.law7.hotmail.com [216.33.237.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28365 for ; Tue, 26 Mar 2002 17:36:50 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:36:23 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:36:22 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 22:36:22 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:36:23.0090 (UTC) FILETIME=[A8318920:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Simplicity should not compromise fundamentally desirable features. The requirement is fundamentally flawed. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 14:17:26 -0800 > >On second thought, let's keep it simple. Premature optimization often >has unintended consequences. > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails >a day. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Tuesday, March 26, 2002 9:31 PM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi James: > > > > I am bit confused. First the extension to requirement sounded fine to >you, > > now it is not. What is you final opinion? > > > > I am not proposing any optimization. There is core flaw in the >original > > requirement that you have proposed. The requirement you proposed means > > following: As soon as AR sees MN attached to it, it blasts MN with set >of > > GAARs and their capabilities. This is clearly inefficient. This is >like > > empowering the network to spam MN with possibly unwanted information. > > > > Sometimes you say MN must be in charge and sometimes you give leeway >to > > network to ignore MN. Why is that? > > > > BR, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Hesham Soliman \(ERA\)" , > > >"'Hemant Chaskar'" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > What if MN does not want to receive such information or > > > > > does not want to > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > it on MN. > > > > > > > > => The MN will ignore it if it doesn't > > > > need it. > > > > > > > > To > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > => I disagree this is a very strange > > > > argument for removing the MN from the loop. > > > > How does the AR know ?? Do we have to invent > > > > another protocol that the MN should implement > > > > to say no ?! > > > > > > > > Can we please make this simple? > > > > > > > > > >Good point. > > > > > >I don't think we need to include optimizations in the requirements. > > >Let's keep it simple. > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:54:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28811 for ; Tue, 26 Mar 2002 17:54:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22002; Tue, 26 Mar 2002 17:47:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21928 for ; Tue, 26 Mar 2002 17:47:39 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28654 for ; Tue, 26 Mar 2002 17:47:36 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMl6I14299; Tue, 26 Mar 2002 14:47:06 -0800 (PST) Message-ID: <041801c1d517$edc1a6e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:45:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Right, so the AR hands over the list of GAAR and the MN figures out where it wants to go. What could be simpler? jak ----- Original Message ----- From: "Govind Krishnamurthi" To: ; Sent: Tuesday, March 26, 2002 2:32 PM Subject: Re: [Seamoby] Examples of CAR discovery > James, > Because one of the inputs to TAR selection is the reachability information > from the MN. Irrespective of what the MN's profile > says if the MN does not inform that it can hear to a particular > AP (which is of a particular technology) then why will the TAR > selection algorithm hand over to the AR which controls that AP? > I thought reachability information from the MNs includes what > APs it can hear and if a interface is not present why will the MN > give information that it can hear an AP of a matching technology? > > Clearly if the AR clearly intreprets this lack of information > from the MN as a signal to hand it over to that very AR then there > something wrong in the implementation. > There is no need for any complicated protocol. When you look at > the issues draft you will see that TAR selection has the reachability > information from the MN as one of its input. > > > > >How can the TAR selection algorithm realize the absence of > >reachability? If the subscriber profile says that the MN has > >a WLAN card in and, in fact, it doesn't, then there either a) there > >needs > >to be some complicated protocol to tell the AR or b) the AR > >will make a mistake and move the MN to a medium that > >it currently doesn't have. > > > >I maintain that a) is too complicated and b) is an error. > > > >And, no, I don't think this is TBD by the TAR implementation. It > >lies at the heart of whether a network-only controlled algorithm > >would work for ITHO. > > > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:54:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28820 for ; Tue, 26 Mar 2002 17:54:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23859 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:54:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22002; Tue, 26 Mar 2002 17:47:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21928 for ; Tue, 26 Mar 2002 17:47:39 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28654 for ; Tue, 26 Mar 2002 17:47:36 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMl6I14299; Tue, 26 Mar 2002 14:47:06 -0800 (PST) Message-ID: <041801c1d517$edc1a6e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:45:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Right, so the AR hands over the list of GAAR and the MN figures out where it wants to go. What could be simpler? jak ----- Original Message ----- From: "Govind Krishnamurthi" To: ; Sent: Tuesday, March 26, 2002 2:32 PM Subject: Re: [Seamoby] Examples of CAR discovery > James, > Because one of the inputs to TAR selection is the reachability information > from the MN. Irrespective of what the MN's profile > says if the MN does not inform that it can hear to a particular > AP (which is of a particular technology) then why will the TAR > selection algorithm hand over to the AR which controls that AP? > I thought reachability information from the MNs includes what > APs it can hear and if a interface is not present why will the MN > give information that it can hear an AP of a matching technology? > > Clearly if the AR clearly intreprets this lack of information > from the MN as a signal to hand it over to that very AR then there > something wrong in the implementation. > There is no need for any complicated protocol. When you look at > the issues draft you will see that TAR selection has the reachability > information from the MN as one of its input. > > > > >How can the TAR selection algorithm realize the absence of > >reachability? If the subscriber profile says that the MN has > >a WLAN card in and, in fact, it doesn't, then there either a) there > >needs > >to be some complicated protocol to tell the AR or b) the AR > >will make a mistake and move the MN to a medium that > >it currently doesn't have. > > > >I maintain that a) is too complicated and b) is an error. > > > >And, no, I don't think this is TBD by the TAR implementation. It > >lies at the heart of whether a network-only controlled algorithm > >would work for ITHO. > > > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 17:58:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28942 for ; Tue, 26 Mar 2002 17:58:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23779; Tue, 26 Mar 2002 17:53:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23694 for ; Tue, 26 Mar 2002 17:53:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28803 for ; Tue, 26 Mar 2002 17:53:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMrOI14467; Tue, 26 Mar 2002 14:53:24 -0800 (PST) Message-ID: <043601c1d518$cebdef50$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:51:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Please justify this rather extreme statement. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Tuesday, March 26, 2002 10:36 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > Simplicity should not compromise fundamentally desirable features. The > requirement is fundamentally flawed. > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 14:17:26 -0800 > > > >On second thought, let's keep it simple. Premature optimization often > >has unintended consequences. > > > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails > >a day. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Tuesday, March 26, 2002 9:31 PM > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi James: > > > > > > I am bit confused. First the extension to requirement sounded fine to > >you, > > > now it is not. What is you final opinion? > > > > > > I am not proposing any optimization. There is core flaw in the > >original > > > requirement that you have proposed. The requirement you proposed means > > > following: As soon as AR sees MN attached to it, it blasts MN with set > >of > > > GAARs and their capabilities. This is clearly inefficient. This is > >like > > > empowering the network to spam MN with possibly unwanted information. > > > > > > Sometimes you say MN must be in charge and sometimes you give leeway > >to > > > network to ignore MN. Why is that? > > > > > > BR, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Hemant Chaskar'" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > > > What if MN does not want to receive such information or > > > > > > does not want to > > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > > it on MN. > > > > > > > > > > => The MN will ignore it if it doesn't > > > > > need it. > > > > > > > > > > To > > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > > information, along > > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > > > => I disagree this is a very strange > > > > > argument for removing the MN from the loop. > > > > > How does the AR know ?? Do we have to invent > > > > > another protocol that the MN should implement > > > > > to say no ?! > > > > > > > > > > Can we please make this simple? > > > > > > > > > > > > >Good point. > > > > > > > >I don't think we need to include optimizations in the requirements. > > > >Let's keep it simple. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 17:58:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28952 for ; Tue, 26 Mar 2002 17:58:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24915 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:58:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23779; Tue, 26 Mar 2002 17:53:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23694 for ; Tue, 26 Mar 2002 17:53:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28803 for ; Tue, 26 Mar 2002 17:53:53 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMrOI14467; Tue, 26 Mar 2002 14:53:24 -0800 (PST) Message-ID: <043601c1d518$cebdef50$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:51:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Please justify this rather extreme statement. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Tuesday, March 26, 2002 10:36 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > Simplicity should not compromise fundamentally desirable features. The > requirement is fundamentally flawed. > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 14:17:26 -0800 > > > >On second thought, let's keep it simple. Premature optimization often > >has unintended consequences. > > > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails > >a day. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Tuesday, March 26, 2002 9:31 PM > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi James: > > > > > > I am bit confused. First the extension to requirement sounded fine to > >you, > > > now it is not. What is you final opinion? > > > > > > I am not proposing any optimization. There is core flaw in the > >original > > > requirement that you have proposed. The requirement you proposed means > > > following: As soon as AR sees MN attached to it, it blasts MN with set > >of > > > GAARs and their capabilities. This is clearly inefficient. This is > >like > > > empowering the network to spam MN with possibly unwanted information. > > > > > > Sometimes you say MN must be in charge and sometimes you give leeway > >to > > > network to ignore MN. Why is that? > > > > > > BR, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Hemant Chaskar'" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > > > What if MN does not want to receive such information or > > > > > > does not want to > > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > > it on MN. > > > > > > > > > > => The MN will ignore it if it doesn't > > > > > need it. > > > > > > > > > > To > > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > > information, along > > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > > > => I disagree this is a very strange > > > > > argument for removing the MN from the loop. > > > > > How does the AR know ?? Do we have to invent > > > > > another protocol that the MN should implement > > > > > to say no ?! > > > > > > > > > > Can we please make this simple? > > > > > > > > > > > > >Good point. > > > > > > > >I don't think we need to include optimizations in the requirements. > > > >Let's keep it simple. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 18:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29078 for ; Tue, 26 Mar 2002 18:01:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25396; Tue, 26 Mar 2002 17:59:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25356 for ; Tue, 26 Mar 2002 17:59:31 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29043 for ; Tue, 26 Mar 2002 17:59:28 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA07509; Tue, 26 Mar 2002 23:56:36 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:59:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant wrote: > > Hi Henrik: > > There is no doubt that MN-centric is fundamental point. But, here is what I > mean by this statement: > > CAR discovery in its simplest terms is about comparing "MN requirements" > with "GAAR capabilities". The "place" where this comparison is done > (processor MIPs for comparison instructions are executed) is > solution-specific and neither relevant in problem statement phase nor > requirements phase. Fine. The problem is, now is the time to agree on the constraints on the solution, so that we don't design something inappropriate, or unduly complex. I, for one, believe that it is an important characteristic of this problem, and any appropriate solution, that not only the CAR -> TAR process, but already the final assembly of the GAAR list, and from there the generation of the CAR list, of necessity must reside in the MN as soon as we try to be access technology agnostic. The activities of one particular access technology network in determining handovers for that network should of course influence which of that network's APs appear in the GAAR list. > > An example where such comparison may occur in network is when there is only > one interface on MN and it can listen only to radio beacons of surrounding > access points. This is similar to break-before-make handoff case. Here, MN > cannot receive capabilities of GAARs without letting go the previous > connection. Do you think that such cases are not relevant and we should > exclude such cases right at the problem statement/requirements stage? I think that designing for the one access technology case will cripple the solution. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29087 for ; Tue, 26 Mar 2002 18:01:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25893 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 18:01:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25396; Tue, 26 Mar 2002 17:59:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25356 for ; Tue, 26 Mar 2002 17:59:31 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29043 for ; Tue, 26 Mar 2002 17:59:28 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id XAA07509; Tue, 26 Mar 2002 23:56:36 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 23:59:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant wrote: > > Hi Henrik: > > There is no doubt that MN-centric is fundamental point. But, here is what I > mean by this statement: > > CAR discovery in its simplest terms is about comparing "MN requirements" > with "GAAR capabilities". The "place" where this comparison is done > (processor MIPs for comparison instructions are executed) is > solution-specific and neither relevant in problem statement phase nor > requirements phase. Fine. The problem is, now is the time to agree on the constraints on the solution, so that we don't design something inappropriate, or unduly complex. I, for one, believe that it is an important characteristic of this problem, and any appropriate solution, that not only the CAR -> TAR process, but already the final assembly of the GAAR list, and from there the generation of the CAR list, of necessity must reside in the MN as soon as we try to be access technology agnostic. The activities of one particular access technology network in determining handovers for that network should of course influence which of that network's APs appear in the GAAR list. > > An example where such comparison may occur in network is when there is only > one interface on MN and it can listen only to radio beacons of surrounding > access points. This is similar to break-before-make handoff case. Here, MN > cannot receive capabilities of GAARs without letting go the previous > connection. Do you think that such cases are not relevant and we should > exclude such cases right at the problem statement/requirements stage? I think that designing for the one access technology case will cripple the solution. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 18:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29355 for ; Tue, 26 Mar 2002 18:09:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27486; Tue, 26 Mar 2002 18:06:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27449 for ; Tue, 26 Mar 2002 18:06:43 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29306 for ; Tue, 26 Mar 2002 18:06:39 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id AAA07624; Wed, 27 Mar 2002 00:03:49 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 00:06:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, No, the requirement is just fine. It does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. Regards, Henrik Hemant wrote: > > Hi James: > > Simplicity should not compromise fundamentally desirable features. The > requirement is fundamentally flawed. > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 14:17:26 -0800 > > > >On second thought, let's keep it simple. Premature optimization often > >has unintended consequences. > > > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails > >a day. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Tuesday, March 26, 2002 9:31 PM > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi James: > > > > > > I am bit confused. First the extension to requirement sounded fine to > >you, > > > now it is not. What is you final opinion? > > > > > > I am not proposing any optimization. There is core flaw in the > >original > > > requirement that you have proposed. The requirement you proposed means > > > following: As soon as AR sees MN attached to it, it blasts MN with set > >of > > > GAARs and their capabilities. This is clearly inefficient. This is > >like > > > empowering the network to spam MN with possibly unwanted information. > > > > > > Sometimes you say MN must be in charge and sometimes you give leeway > >to > > > network to ignore MN. Why is that? > > > > > > BR, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Hemant Chaskar'" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > > > What if MN does not want to receive such information or > > > > > > does not want to > > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > > it on MN. > > > > > > > > > > => The MN will ignore it if it doesn't > > > > > need it. > > > > > > > > > > To > > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > > information, along > > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > > > => I disagree this is a very strange > > > > > argument for removing the MN from the loop. > > > > > How does the AR know ?? Do we have to invent > > > > > another protocol that the MN should implement > > > > > to say no ?! > > > > > > > > > > Can we please make this simple? > > > > > > > > > > > > >Good point. > > > > > > > >I don't think we need to include optimizations in the requirements. > > > >Let's keep it simple. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29365 for ; Tue, 26 Mar 2002 18:09:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28172 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 18:09:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27486; Tue, 26 Mar 2002 18:06:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27449 for ; Tue, 26 Mar 2002 18:06:43 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29306 for ; Tue, 26 Mar 2002 18:06:39 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id AAA07624; Wed, 27 Mar 2002 00:03:49 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 00:06:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, No, the requirement is just fine. It does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. Regards, Henrik Hemant wrote: > > Hi James: > > Simplicity should not compromise fundamentally desirable features. The > requirement is fundamentally flawed. > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 14:17:26 -0800 > > > >On second thought, let's keep it simple. Premature optimization often > >has unintended consequences. > > > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails > >a day. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Tuesday, March 26, 2002 9:31 PM > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi James: > > > > > > I am bit confused. First the extension to requirement sounded fine to > >you, > > > now it is not. What is you final opinion? > > > > > > I am not proposing any optimization. There is core flaw in the > >original > > > requirement that you have proposed. The requirement you proposed means > > > following: As soon as AR sees MN attached to it, it blasts MN with set > >of > > > GAARs and their capabilities. This is clearly inefficient. This is > >like > > > empowering the network to spam MN with possibly unwanted information. > > > > > > Sometimes you say MN must be in charge and sometimes you give leeway > >to > > > network to ignore MN. Why is that? > > > > > > BR, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Hesham Soliman \(ERA\)" , > > > >"'Hemant Chaskar'" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > > > What if MN does not want to receive such information or > > > > > > does not want to > > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > > it on MN. > > > > > > > > > > => The MN will ignore it if it doesn't > > > > > need it. > > > > > > > > > > To > > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > > information, along > > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > > > => I disagree this is a very strange > > > > > argument for removing the MN from the loop. > > > > > How does the AR know ?? Do we have to invent > > > > > another protocol that the MN should implement > > > > > to say no ?! > > > > > > > > > > Can we please make this simple? > > > > > > > > > > > > >Good point. > > > > > > > >I don't think we need to include optimizations in the requirements. > > > >Let's keep it simple. > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:13:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27589 for ; Tue, 26 Mar 2002 17:21:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15019 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:21:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14467; Tue, 26 Mar 2002 17:19:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14431 for ; Tue, 26 Mar 2002 17:19:35 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27556 for ; Tue, 26 Mar 2002 17:19:32 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QMJ3I13295; Tue, 26 Mar 2002 14:19:03 -0800 (PST) Message-ID: <039801c1d514$02e419d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 14:17:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit On second thought, let's keep it simple. Premature optimization often has unintended consequences. Sorry for the confusion. I'm having trouble keeping up with 200+ emails a day. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Tuesday, March 26, 2002 9:31 PM Subject: Re: [Seamoby] Examples of CAR discovery > Hi James: > > I am bit confused. First the extension to requirement sounded fine to you, > now it is not. What is you final opinion? > > I am not proposing any optimization. There is core flaw in the original > requirement that you have proposed. The requirement you proposed means > following: As soon as AR sees MN attached to it, it blasts MN with set of > GAARs and their capabilities. This is clearly inefficient. This is like > empowering the network to spam MN with possibly unwanted information. > > Sometimes you say MN must be in charge and sometimes you give leeway to > network to ignore MN. Why is that? > > BR, > Hemant > > > >From: "James Kempf" > >To: "Hesham Soliman \(ERA\)" , > >"'Hemant Chaskar'" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > What if MN does not want to receive such information or > > > > does not want to > > > > receive a part of it. Then, CAR discovery should not blast > > > > it on MN. > > > > > > => The MN will ignore it if it doesn't > > > need it. > > > > > > To > > > > avoid this, we can slightly rephrase it as: > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along > > > > with capabilities, *whenever and as required by MN*." > > > > > > > => I disagree this is a very strange > > > argument for removing the MN from the loop. > > > How does the AR know ?? Do we have to invent > > > another protocol that the MN should implement > > > to say no ?! > > > > > > Can we please make this simple? > > > > > > >Good point. > > > >I don't think we need to include optimizations in the requirements. > >Let's keep it simple. > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 18:14:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29455 for ; Tue, 26 Mar 2002 18:14:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26461; Tue, 26 Mar 2002 18:03:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26423 for ; Tue, 26 Mar 2002 18:03:43 -0500 (EST) Received: from hotmail.com (f267.law9.hotmail.com [64.4.8.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29165 for ; Tue, 26 Mar 2002 18:03:40 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 15:03:14 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 23:03:13 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 18:03:13 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 23:03:14.0055 (UTC) FILETIME=[68674970:01C1D51A] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, So now you agree that the AR can hand over the list of GAARs and their capabilities to the MN (maybe only pass on those which satisfy the MN requirements, which is what CAR discovery was originally about). Which first implies that the network is taking care of CAR discovery. This seems contradictory to your earlier mails saying that there is no basis for network based CAR discovery. So are you now agreeing that network based CAR discovery has its place? Now to the current issue. Why cant the AR send over the GAARs and their associated capabilities to the MN for TAR selection. This comes into the domain of TAR selection. What you suggest can be done and has no basis on where CAR discovery is being done. Similarly I can suggest a scheme, in which for example, wherein this final decision can be taken in the network after considering the MN's requirements and the MN can have a veto power on the decision. There are bandwidth and power considerations in both ( I have described this in an earlier mail in detail and hence don't want to go into it again). But again this is out of scope of CAR discovery. All CAR discovery MUST ensure is that its output is available for TAR selection irrespective of where the TAR selection process resides. Regards, Govind. >Right, so the AR hands over the list of GAAR and the MN figures out >where it wants to go. What could be simpler? > > jak > >----- Original Message ----- >From: "Govind Krishnamurthi" >To: ; >Sent: Tuesday, March 26, 2002 2:32 PM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > James, > > Because one of the inputs to TAR selection is the reachability >information > > from the MN. Irrespective of what the MN's profile > > says if the MN does not inform that it can hear to a particular > > AP (which is of a particular technology) then why will the TAR > > selection algorithm hand over to the AR which controls that AP? > > I thought reachability information from the MNs includes what > > APs it can hear and if a interface is not present why will the MN > > give information that it can hear an AP of a matching technology? > > > > Clearly if the AR clearly intreprets this lack of information > > from the MN as a signal to hand it over to that very AR then there > > something wrong in the implementation. > > There is no need for any complicated protocol. When you look at > > the issues draft you will see that TAR selection has the reachability > > information from the MN as one of its input. > > > > > > > >How can the TAR selection algorithm realize the absence of > > >reachability? If the subscriber profile says that the MN has > > >a WLAN card in and, in fact, it doesn't, then there either a) there > > >needs > > >to be some complicated protocol to tell the AR or b) the AR > > >will make a mistake and move the MN to a medium that > > >it currently doesn't have. > > > > > >I maintain that a) is too complicated and b) is an error. > > > > > >And, no, I don't think this is TBD by the TAR implementation. It > > >lies at the heart of whether a network-only controlled algorithm > > >would work for ITHO. > > > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:14:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29464 for ; Tue, 26 Mar 2002 18:14:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29320 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 18:14:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26461; Tue, 26 Mar 2002 18:03:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26423 for ; Tue, 26 Mar 2002 18:03:43 -0500 (EST) Received: from hotmail.com (f267.law9.hotmail.com [64.4.8.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29165 for ; Tue, 26 Mar 2002 18:03:40 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 15:03:14 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 23:03:13 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 18:03:13 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 23:03:14.0055 (UTC) FILETIME=[68674970:01C1D51A] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, So now you agree that the AR can hand over the list of GAARs and their capabilities to the MN (maybe only pass on those which satisfy the MN requirements, which is what CAR discovery was originally about). Which first implies that the network is taking care of CAR discovery. This seems contradictory to your earlier mails saying that there is no basis for network based CAR discovery. So are you now agreeing that network based CAR discovery has its place? Now to the current issue. Why cant the AR send over the GAARs and their associated capabilities to the MN for TAR selection. This comes into the domain of TAR selection. What you suggest can be done and has no basis on where CAR discovery is being done. Similarly I can suggest a scheme, in which for example, wherein this final decision can be taken in the network after considering the MN's requirements and the MN can have a veto power on the decision. There are bandwidth and power considerations in both ( I have described this in an earlier mail in detail and hence don't want to go into it again). But again this is out of scope of CAR discovery. All CAR discovery MUST ensure is that its output is available for TAR selection irrespective of where the TAR selection process resides. Regards, Govind. >Right, so the AR hands over the list of GAAR and the MN figures out >where it wants to go. What could be simpler? > > jak > >----- Original Message ----- >From: "Govind Krishnamurthi" >To: ; >Sent: Tuesday, March 26, 2002 2:32 PM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > James, > > Because one of the inputs to TAR selection is the reachability >information > > from the MN. Irrespective of what the MN's profile > > says if the MN does not inform that it can hear to a particular > > AP (which is of a particular technology) then why will the TAR > > selection algorithm hand over to the AR which controls that AP? > > I thought reachability information from the MNs includes what > > APs it can hear and if a interface is not present why will the MN > > give information that it can hear an AP of a matching technology? > > > > Clearly if the AR clearly intreprets this lack of information > > from the MN as a signal to hand it over to that very AR then there > > something wrong in the implementation. > > There is no need for any complicated protocol. When you look at > > the issues draft you will see that TAR selection has the reachability > > information from the MN as one of its input. > > > > > > > >How can the TAR selection algorithm realize the absence of > > >reachability? If the subscriber profile says that the MN has > > >a WLAN card in and, in fact, it doesn't, then there either a) there > > >needs > > >to be some complicated protocol to tell the AR or b) the AR > > >will make a mistake and move the MN to a medium that > > >it currently doesn't have. > > > > > >I maintain that a) is too complicated and b) is an error. > > > > > >And, no, I don't think this is TBD by the TAR implementation. It > > >lies at the heart of whether a network-only controlled algorithm > > >would work for ITHO. > > > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:28:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28343 for ; Tue, 26 Mar 2002 17:36:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19094 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:36:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18263; Tue, 26 Mar 2002 17:33:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18232 for ; Tue, 26 Mar 2002 17:33:21 -0500 (EST) Received: from hotmail.com (f188.law9.hotmail.com [64.4.9.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28283 for ; Tue, 26 Mar 2002 17:33:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:32:52 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:32:51 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 17:32:51 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:32:52.0007 (UTC) FILETIME=[2A60D370:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, Because one of the inputs to TAR selection is the reachability information from the MN. Irrespective of what the MN's profile says if the MN does not inform that it can hear to a particular AP (which is of a particular technology) then why will the TAR selection algorithm hand over to the AR which controls that AP? I thought reachability information from the MNs includes what APs it can hear and if a interface is not present why will the MN give information that it can hear an AP of a matching technology? Clearly if the AR clearly intreprets this lack of information from the MN as a signal to hand it over to that very AR then there something wrong in the implementation. There is no need for any complicated protocol. When you look at the issues draft you will see that TAR selection has the reachability information from the MN as one of its input. > >How can the TAR selection algorithm realize the absence of >reachability? If the subscriber profile says that the MN has >a WLAN card in and, in fact, it doesn't, then there either a) there >needs >to be some complicated protocol to tell the AR or b) the AR >will make a mistake and move the MN to a medium that >it currently doesn't have. > >I maintain that a) is too complicated and b) is an error. > >And, no, I don't think this is TBD by the TAR implementation. It >lies at the heart of whether a network-only controlled algorithm >would work for ITHO. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:28:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28471 for ; Tue, 26 Mar 2002 17:39:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20058 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 17:39:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18356; Tue, 26 Mar 2002 17:33:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18291 for ; Tue, 26 Mar 2002 17:33:28 -0500 (EST) Received: from hotmail.com (f139.law7.hotmail.com [216.33.237.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28286 for ; Tue, 26 Mar 2002 17:33:25 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 14:32:58 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 22:32:58 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 22:32:58 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2002 22:32:58.0554 (UTC) FILETIME=[2E47D1A0:01C1D516] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: There is no doubt that MN-centric is fundamental point. But, here is what I mean by this statement: CAR discovery in its simplest terms is about comparing "MN requirements" with "GAAR capabilities". The "place" where this comparison is done (processor MIPs for comparison instructions are executed) is solution-specific and neither relevant in problem statement phase nor requirements phase. An example where such comparison may occur in network is when there is only one interface on MN and it can listen only to radio beacons of surrounding access points. This is similar to break-before-make handoff case. Here, MN cannot receive capabilities of GAARs without letting go the previous connection. Do you think that such cases are not relevant and we should exclude such cases right at the problem statement/requirements stage? BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Tue, 26 Mar 2002 23:10:47 +0100 > >Catching up on this thread. Sorry if this point has already >been made: > >Hemant wrote: >...> > > - The problem statement does not advocate any specific way >(network-based or > > MN-based or hybrid) of performing CAR discovery. > >I believe this is pointing us in the wrong direction. I believe it is >an essential part of CAR discovery that it is MN-centric. In other >words, CAR discovery is the process of the Networks, Current Active >Access Points and the MN itself (through stored information, scanning, >this, that, and whatever other magic is available) providing *the MN* >with information that *the MN* can use to assemble the most appropriate >list of GAARs for *that MN* at that moment, from which *the MN* can >destill its CARs. > > Regards, > Henrik > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 18:48:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00197 for ; Tue, 26 Mar 2002 18:48:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06318; Tue, 26 Mar 2002 18:42:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06277 for ; Tue, 26 Mar 2002 18:42:47 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00078 for ; Tue, 26 Mar 2002 18:42:44 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QNgDI15940; Tue, 26 Mar 2002 15:42:14 -0800 (PST) Message-ID: <046901c1d51f$a1151360$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Date: Tue, 26 Mar 2002 15:40:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit , > So now you agree that the AR can hand over the list of GAARs and > their capabilities to the MN (maybe only pass on those which satisfy > the MN requirements, which is what CAR discovery was originally about). > No, that it sends all, along with the capabilities. Let me repeat the requirement I would like to see (and Henrik apparently agrees) so we are clear on this: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. > Which first implies that the network is taking care of CAR discovery. > This seems contradictory to your earlier mails saying that there is > no basis for network based CAR discovery. So are you now agreeing > that network based CAR discovery has its place? > Please see the requirement above. No contradiction. The protocol allows the MN to discover the GAAR and capabilities, the MN decides which one it wants. Nothing about the AR in control of anything. The MN may use a variant of IPv6 neighbor discovery, the AR may be involved somehow, but that's a protocol design, not a requirement, choice. The requirement is clearly that the MN does the discovery. We now have two working group members who want this reqirement worded just this way. Nothing about "as the MN expresses its preferences" or "by the CAR discovery module" or anything else. And I believe Hesham has also expressed a preference for this requirement. Anybody else out there have an opinion on this? Should we include this requirement instead of requirement 3.4, which has the AR in control? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:48:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00214 for ; Tue, 26 Mar 2002 18:48:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07527 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 18:48:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06318; Tue, 26 Mar 2002 18:42:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06277 for ; Tue, 26 Mar 2002 18:42:47 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00078 for ; Tue, 26 Mar 2002 18:42:44 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QNgDI15940; Tue, 26 Mar 2002 15:42:14 -0800 (PST) Message-ID: <046901c1d51f$a1151360$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Date: Tue, 26 Mar 2002 15:40:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit , > So now you agree that the AR can hand over the list of GAARs and > their capabilities to the MN (maybe only pass on those which satisfy > the MN requirements, which is what CAR discovery was originally about). > No, that it sends all, along with the capabilities. Let me repeat the requirement I would like to see (and Henrik apparently agrees) so we are clear on this: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. > Which first implies that the network is taking care of CAR discovery. > This seems contradictory to your earlier mails saying that there is > no basis for network based CAR discovery. So are you now agreeing > that network based CAR discovery has its place? > Please see the requirement above. No contradiction. The protocol allows the MN to discover the GAAR and capabilities, the MN decides which one it wants. Nothing about the AR in control of anything. The MN may use a variant of IPv6 neighbor discovery, the AR may be involved somehow, but that's a protocol design, not a requirement, choice. The requirement is clearly that the MN does the discovery. We now have two working group members who want this reqirement worded just this way. Nothing about "as the MN expresses its preferences" or "by the CAR discovery module" or anything else. And I believe Hesham has also expressed a preference for this requirement. Anybody else out there have an opinion on this? Should we include this requirement instead of requirement 3.4, which has the AR in control? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 18:52:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00318 for ; Tue, 26 Mar 2002 18:52:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06013; Tue, 26 Mar 2002 18:41:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05977 for ; Tue, 26 Mar 2002 18:41:33 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00052 for ; Tue, 26 Mar 2002 18:41:29 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id AAA08106; Wed, 27 Mar 2002 00:38:38 +0100 From: "Henrik Levkowetz" To: "Govind Krishnamurthi" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 00:41:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind wrote: > So now you agree that the AR can hand over the list of GAARs and > their capabilities to the MN (maybe only pass on those which satisfy > the MN requirements, which is what CAR discovery was originally about). Here you seem to assume that one single AR has the full list of GAARs. I would argue that a flexible and scalable solution would have the final list of GAARs be composed from sublists provided by multiple ARs and the MN. > > Which first implies that the network is taking care of CAR discovery. > This seems contradictory to your earlier mails saying that there is > no basis for network based CAR discovery. So are you now agreeing > that network based CAR discovery has its place? > > Now to the current issue. > Why cant the AR send over the GAARs and their associated capabilities > to the MN for TAR selection. This comes into the domain of > TAR selection. What you suggest can be done and has no basis on > where CAR discovery is being done. Similarly I can suggest a scheme, > in which for example, > wherein this final decision can be taken in the network after considering > the MN's requirements and the MN can have a veto power > on the decision. There are bandwidth and power considerations in both ( I > have described this in an earlier mail in detail and hence don't want to go > into it again). > But again this is out of scope of CAR discovery. All CAR discovery MUST > ensure is that its output is available for TAR selection irrespective > of where the TAR selection process resides. It may be technically possible for all Currently Active Access Routers to transit their GAAR sublist to the MN, who transmit the lot together with its own GAAR sublist to one particular AR, who runs some algorithm and returns the result to the MN. But it certainly doesnt't seem either sensible or optimal to me. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 18:52:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00327 for ; Tue, 26 Mar 2002 18:52:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08496 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 18:52:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06013; Tue, 26 Mar 2002 18:41:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05977 for ; Tue, 26 Mar 2002 18:41:33 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00052 for ; Tue, 26 Mar 2002 18:41:29 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id AAA08106; Wed, 27 Mar 2002 00:38:38 +0100 From: "Henrik Levkowetz" To: "Govind Krishnamurthi" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 00:41:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind wrote: > So now you agree that the AR can hand over the list of GAARs and > their capabilities to the MN (maybe only pass on those which satisfy > the MN requirements, which is what CAR discovery was originally about). Here you seem to assume that one single AR has the full list of GAARs. I would argue that a flexible and scalable solution would have the final list of GAARs be composed from sublists provided by multiple ARs and the MN. > > Which first implies that the network is taking care of CAR discovery. > This seems contradictory to your earlier mails saying that there is > no basis for network based CAR discovery. So are you now agreeing > that network based CAR discovery has its place? > > Now to the current issue. > Why cant the AR send over the GAARs and their associated capabilities > to the MN for TAR selection. This comes into the domain of > TAR selection. What you suggest can be done and has no basis on > where CAR discovery is being done. Similarly I can suggest a scheme, > in which for example, > wherein this final decision can be taken in the network after considering > the MN's requirements and the MN can have a veto power > on the decision. There are bandwidth and power considerations in both ( I > have described this in an earlier mail in detail and hence don't want to go > into it again). > But again this is out of scope of CAR discovery. All CAR discovery MUST > ensure is that its output is available for TAR selection irrespective > of where the TAR selection process resides. It may be technically possible for all Currently Active Access Routers to transit their GAAR sublist to the MN, who transmit the lot together with its own GAAR sublist to one particular AR, who runs some algorithm and returns the result to the MN. But it certainly doesnt't seem either sensible or optimal to me. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 19:47:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01410 for ; Tue, 26 Mar 2002 19:47:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20806; Tue, 26 Mar 2002 19:40:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20765 for ; Tue, 26 Mar 2002 19:40:44 -0500 (EST) Received: from hotmail.com (f255.law7.hotmail.com [216.33.236.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01310 for ; Tue, 26 Mar 2002 19:40:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:40:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:40:13 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 00:40:13 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:40:14.0047 (UTC) FILETIME=[F56396F0:01C1D527] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: There are serious shortcomings of the solution satisfying this requirement. They are described below. How can we finalise this requirement unless it is agreed that these pitfalls do not exist? For this, it might be good idea to visualise how the solution satisfying this requirement looks like and violates basic tenets of engineering design, namely efficiency. The solution satisfying this requirement is obliged to blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a big chunk of data (= number of GAARs times capability set of each). This flood will occur either on active traffic connection which I call case (i) (relevant for single interface MN and two-interface MN where second interface is sleeping) or on second interface which I call case (ii) (relevant for two interface MN with both interfaces awake). There are following effects of this flood: 1. Disruption in traffic: For case (i), it causes disruption in traffic over active traffic channel. 2. Power wastage: For both cases (i) and (ii), receiving this flood causes power wastage. This is because, after receiving these capabilities MN either rejects the new AR (which is worst), and even if it selcects one why does it need to receive capabilities of GAARs that do not matter for it. 3. Bandwidth wastage: An AR needs to send this flood to every MN that it sees. Which means the same information (which could be big enough) is transmitted on downlink so many times. This takes up considerable fraction of downlink capacity. 4. Limit on capability definition: This requirement restricts the definition of capabilities to a very small size, otherwise all ARs will only be transmitting GAAR capabilities to different MNs all the time. This means capability set cannot be comprehensive and extensible. So, IMHO rather than counting who agrees to one statement requirement that you proposed and who have not, we should first analyse above harmful effects before deciding either way. Br, Hemant >From: "James Kempf" >To: "Govind Krishnamurthi" , >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: >Examples of CAR discovery) >Date: Tue, 26 Mar 2002 15:40:36 -0800 > >, > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those which satisfy > > the MN requirements, which is what CAR discovery was originally >about). > > > >No, that it sends all, along with the capabilities. Let me repeat the >requirement I would like to see (and Henrik apparently agrees) so we are >clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > > Which first implies that the network is taking care of CAR discovery. > > This seems contradictory to your earlier mails saying that there is > > no basis for network based CAR discovery. So are you now agreeing > > that network based CAR discovery has its place? > > > >Please see the requirement above. No contradiction. The protocol allows >the MN to discover the GAAR and capabilities, the MN decides which one >it wants. >Nothing about the AR in control of anything. The MN may use a variant of >IPv6 neighbor discovery, the AR may be involved somehow, but that's a >protocol design, not a requirement, choice. The requirement is clearly >that the MN does the discovery. > >We now have two working group members who want this reqirement worded >just this way. Nothing about "as the MN expresses its preferences" or >"by the CAR discovery module" or anything else. And I believe Hesham has >also expressed a preference for this requirement. > >Anybody else out there have an opinion on this? Should we include this >requirement instead of requirement 3.4, which has the AR in control? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 19:47:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01419 for ; Tue, 26 Mar 2002 19:47:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22602 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 19:47:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20806; Tue, 26 Mar 2002 19:40:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20765 for ; Tue, 26 Mar 2002 19:40:44 -0500 (EST) Received: from hotmail.com (f255.law7.hotmail.com [216.33.236.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01310 for ; Tue, 26 Mar 2002 19:40:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:40:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:40:13 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 00:40:13 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:40:14.0047 (UTC) FILETIME=[F56396F0:01C1D527] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: There are serious shortcomings of the solution satisfying this requirement. They are described below. How can we finalise this requirement unless it is agreed that these pitfalls do not exist? For this, it might be good idea to visualise how the solution satisfying this requirement looks like and violates basic tenets of engineering design, namely efficiency. The solution satisfying this requirement is obliged to blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a big chunk of data (= number of GAARs times capability set of each). This flood will occur either on active traffic connection which I call case (i) (relevant for single interface MN and two-interface MN where second interface is sleeping) or on second interface which I call case (ii) (relevant for two interface MN with both interfaces awake). There are following effects of this flood: 1. Disruption in traffic: For case (i), it causes disruption in traffic over active traffic channel. 2. Power wastage: For both cases (i) and (ii), receiving this flood causes power wastage. This is because, after receiving these capabilities MN either rejects the new AR (which is worst), and even if it selcects one why does it need to receive capabilities of GAARs that do not matter for it. 3. Bandwidth wastage: An AR needs to send this flood to every MN that it sees. Which means the same information (which could be big enough) is transmitted on downlink so many times. This takes up considerable fraction of downlink capacity. 4. Limit on capability definition: This requirement restricts the definition of capabilities to a very small size, otherwise all ARs will only be transmitting GAAR capabilities to different MNs all the time. This means capability set cannot be comprehensive and extensible. So, IMHO rather than counting who agrees to one statement requirement that you proposed and who have not, we should first analyse above harmful effects before deciding either way. Br, Hemant >From: "James Kempf" >To: "Govind Krishnamurthi" , >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: >Examples of CAR discovery) >Date: Tue, 26 Mar 2002 15:40:36 -0800 > >, > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those which satisfy > > the MN requirements, which is what CAR discovery was originally >about). > > > >No, that it sends all, along with the capabilities. Let me repeat the >requirement I would like to see (and Henrik apparently agrees) so we are >clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > > Which first implies that the network is taking care of CAR discovery. > > This seems contradictory to your earlier mails saying that there is > > no basis for network based CAR discovery. So are you now agreeing > > that network based CAR discovery has its place? > > > >Please see the requirement above. No contradiction. The protocol allows >the MN to discover the GAAR and capabilities, the MN decides which one >it wants. >Nothing about the AR in control of anything. The MN may use a variant of >IPv6 neighbor discovery, the AR may be involved somehow, but that's a >protocol design, not a requirement, choice. The requirement is clearly >that the MN does the discovery. > >We now have two working group members who want this reqirement worded >just this way. Nothing about "as the MN expresses its preferences" or >"by the CAR discovery module" or anything else. And I believe Hesham has >also expressed a preference for this requirement. > >Anybody else out there have an opinion on this? Should we include this >requirement instead of requirement 3.4, which has the AR in control? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 19:47:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01475 for ; Tue, 26 Mar 2002 19:47:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21263; Tue, 26 Mar 2002 19:42:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21219 for ; Tue, 26 Mar 2002 19:42:01 -0500 (EST) Received: from hotmail.com (f38.law9.hotmail.com [64.4.9.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01357 for ; Tue, 26 Mar 2002 19:41:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:41:31 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:41:31 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:41:31 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:41:31.0391 (UTC) FILETIME=[237D58F0:01C1D528] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik, I am assuming nothing. I'm merely pointing out that the GAARs can be discovered by the AR along with their capabilities. This is part of CAR discovery. The other part being matching these capabilities with the requirements of the MN. All I'm saying that it is possible to do that in the AR too. >Govind wrote: > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those which satisfy > > the MN requirements, which is what CAR discovery was originally about). > >Here you seem to assume that one single AR has the full list of GAARs. >I would argue that a flexible and scalable solution would have the final >list of GAARs be composed from sublists provided by multiple ARs and the >MN. [Govind] This may be possible. >It may be technically possible for all Currently Active Access Routers to >transit their GAAR sublist to the MN, who transmit the lot together with >its own GAAR sublist to one particular AR, who runs some algorithm and >returns the result to the MN. > >But it certainly doesnt't seem either sensible or optimal to me. [Govind] WHat do you mean currently active Access routers? The MN is currently attached just to one AR and we are talking about the GAARs of this currently attached AR to which the MN may potentially handoff too. Second, I agree what you propose is neither sensible not optimal. But I don't think anyone is suggesting that. To do this we have to go into solution space. But transmitting the GAARs and their capabilties to the MN has its bandwidth and power constraints too. I am not arguing against one another. All I'm saying is we shouldn't totally reject AR based CAR discovery now. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 19:47:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01483 for ; Tue, 26 Mar 2002 19:47:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22746 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 19:47:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21263; Tue, 26 Mar 2002 19:42:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21219 for ; Tue, 26 Mar 2002 19:42:01 -0500 (EST) Received: from hotmail.com (f38.law9.hotmail.com [64.4.9.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01357 for ; Tue, 26 Mar 2002 19:41:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:41:31 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:41:31 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 26 Mar 2002 19:41:31 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:41:31.0391 (UTC) FILETIME=[237D58F0:01C1D528] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik, I am assuming nothing. I'm merely pointing out that the GAARs can be discovered by the AR along with their capabilities. This is part of CAR discovery. The other part being matching these capabilities with the requirements of the MN. All I'm saying that it is possible to do that in the AR too. >Govind wrote: > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those which satisfy > > the MN requirements, which is what CAR discovery was originally about). > >Here you seem to assume that one single AR has the full list of GAARs. >I would argue that a flexible and scalable solution would have the final >list of GAARs be composed from sublists provided by multiple ARs and the >MN. [Govind] This may be possible. >It may be technically possible for all Currently Active Access Routers to >transit their GAAR sublist to the MN, who transmit the lot together with >its own GAAR sublist to one particular AR, who runs some algorithm and >returns the result to the MN. > >But it certainly doesnt't seem either sensible or optimal to me. [Govind] WHat do you mean currently active Access routers? The MN is currently attached just to one AR and we are talking about the GAARs of this currently attached AR to which the MN may potentially handoff too. Second, I agree what you propose is neither sensible not optimal. But I don't think anyone is suggesting that. To do this we have to go into solution space. But transmitting the GAARs and their capabilties to the MN has its bandwidth and power constraints too. I am not arguing against one another. All I'm saying is we shouldn't totally reject AR based CAR discovery now. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 19:51:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01536 for ; Tue, 26 Mar 2002 19:51:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23064; Tue, 26 Mar 2002 19:48:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23026 for ; Tue, 26 Mar 2002 19:48:45 -0500 (EST) Received: from hotmail.com (f150.law7.hotmail.com [216.33.237.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01505 for ; Tue, 26 Mar 2002 19:48:43 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:48:15 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:48:15 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 00:48:15 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:48:15.0739 (UTC) FILETIME=[147FF4B0:01C1D529] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: If we honestly think that the requirement does not oblige AR to blast all GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do we need to hide this fact? We can come up with something else, if you do not like on-demand extension. I think without such extension the solution satisfying this requirement may have serious shortcomings that I described in my other email to James. BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 00:06:37 +0100 > >Hemant, > > No, the requirement is just fine. It does not require *all* GAAR >information, it does not require *on-demand operation*, it expresses >exactly >what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > Regards, > Henrik > >Hemant wrote: > > > > Hi James: > > > > Simplicity should not compromise fundamentally desirable features. The > > requirement is fundamentally flawed. > > > > Hemant > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Tue, 26 Mar 2002 14:17:26 -0800 > > > > > >On second thought, let's keep it simple. Premature optimization often > > >has unintended consequences. > > > > > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails > > >a day. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Tuesday, March 26, 2002 9:31 PM > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > > Hi James: > > > > > > > > I am bit confused. First the extension to requirement sounded fine >to > > >you, > > > > now it is not. What is you final opinion? > > > > > > > > I am not proposing any optimization. There is core flaw in the > > >original > > > > requirement that you have proposed. The requirement you proposed >means > > > > following: As soon as AR sees MN attached to it, it blasts MN with >set > > >of > > > > GAARs and their capabilities. This is clearly inefficient. This is > > >like > > > > empowering the network to spam MN with possibly unwanted >information. > > > > > > > > Sometimes you say MN must be in charge and sometimes you give leeway > > >to > > > > network to ignore MN. Why is that? > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Hesham Soliman \(ERA\)" , > > > > >"'Hemant Chaskar'" , > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > > > > > What if MN does not want to receive such information or > > > > > > > does not want to > > > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > > > it on MN. > > > > > > > > > > > > => The MN will ignore it if it doesn't > > > > > > need it. > > > > > > > > > > > > To > > > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > > > information, along > > > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > > > > > => I disagree this is a very strange > > > > > > argument for removing the MN from the loop. > > > > > > How does the AR know ?? Do we have to invent > > > > > > another protocol that the MN should implement > > > > > > to say no ?! > > > > > > > > > > > > Can we please make this simple? > > > > > > > > > > > > > > > >Good point. > > > > > > > > > >I don't think we need to include optimizations in the requirements. > > > > >Let's keep it simple. > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > _________________________________________________________________ > > > > Send and receive Hotmail on your mobile device: >http://mobile.msn.com > > > > > > > > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 19:51:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01547 for ; Tue, 26 Mar 2002 19:51:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA23650 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 19:51:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23064; Tue, 26 Mar 2002 19:48:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23026 for ; Tue, 26 Mar 2002 19:48:45 -0500 (EST) Received: from hotmail.com (f150.law7.hotmail.com [216.33.237.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01505 for ; Tue, 26 Mar 2002 19:48:43 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:48:15 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:48:15 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 00:48:15 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:48:15.0739 (UTC) FILETIME=[147FF4B0:01C1D529] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: If we honestly think that the requirement does not oblige AR to blast all GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do we need to hide this fact? We can come up with something else, if you do not like on-demand extension. I think without such extension the solution satisfying this requirement may have serious shortcomings that I described in my other email to James. BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 00:06:37 +0100 > >Hemant, > > No, the requirement is just fine. It does not require *all* GAAR >information, it does not require *on-demand operation*, it expresses >exactly >what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > Regards, > Henrik > >Hemant wrote: > > > > Hi James: > > > > Simplicity should not compromise fundamentally desirable features. The > > requirement is fundamentally flawed. > > > > Hemant > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Tue, 26 Mar 2002 14:17:26 -0800 > > > > > >On second thought, let's keep it simple. Premature optimization often > > >has unintended consequences. > > > > > >Sorry for the confusion. I'm having trouble keeping up with 200+ emails > > >a day. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Tuesday, March 26, 2002 9:31 PM > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > > Hi James: > > > > > > > > I am bit confused. First the extension to requirement sounded fine >to > > >you, > > > > now it is not. What is you final opinion? > > > > > > > > I am not proposing any optimization. There is core flaw in the > > >original > > > > requirement that you have proposed. The requirement you proposed >means > > > > following: As soon as AR sees MN attached to it, it blasts MN with >set > > >of > > > > GAARs and their capabilities. This is clearly inefficient. This is > > >like > > > > empowering the network to spam MN with possibly unwanted >information. > > > > > > > > Sometimes you say MN must be in charge and sometimes you give leeway > > >to > > > > network to ignore MN. Why is that? > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Hesham Soliman \(ERA\)" , > > > > >"'Hemant Chaskar'" , > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Tue, 26 Mar 2002 13:14:52 -0800 > > > > > > > > > > > > > > > > > This looks good to me, but with a small attention to detail: > > > > > > > > > > > > > > What if MN does not want to receive such information or > > > > > > > does not want to > > > > > > > receive a part of it. Then, CAR discovery should not blast > > > > > > > it on MN. > > > > > > > > > > > > => The MN will ignore it if it doesn't > > > > > > need it. > > > > > > > > > > > > To > > > > > > > avoid this, we can slightly rephrase it as: > > > > > > > > > > > > > > "The CAR discovery protocol MUST provide the MN with GAAR > > > > > > > information, along > > > > > > > with capabilities, *whenever and as required by MN*." > > > > > > > > > > > > > => I disagree this is a very strange > > > > > > argument for removing the MN from the loop. > > > > > > How does the AR know ?? Do we have to invent > > > > > > another protocol that the MN should implement > > > > > > to say no ?! > > > > > > > > > > > > Can we please make this simple? > > > > > > > > > > > > > > > >Good point. > > > > > > > > > >I don't think we need to include optimizations in the requirements. > > > > >Let's keep it simple. > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > _________________________________________________________________ > > > > Send and receive Hotmail on your mobile device: >http://mobile.msn.com > > > > > > > > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 19:56:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01644 for ; Tue, 26 Mar 2002 19:56:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24508; Tue, 26 Mar 2002 19:54:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24468 for ; Tue, 26 Mar 2002 19:54:03 -0500 (EST) Received: from hotmail.com (f236.law9.hotmail.com [64.4.9.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01594 for ; Tue, 26 Mar 2002 19:54:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:53:33 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:53:33 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Tue, 26 Mar 2002 19:53:33 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:53:33.0403 (UTC) FILETIME=[D1D7A2B0:01C1D529] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >, > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those which satisfy > > the MN requirements, which is what CAR discovery was originally >about). > > > >No, that it sends all, along with the capabilities. Let me repeat the >requirement I would like to see (and Henrik apparently agrees) so we are >clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > [Govind] First what you are calling as CAR discovery is not CAR discovery. What you are saying is GAAR + associated capabilities discovery not CAR discovery therefore part of CAR discovery. CAR discovery matches the requirements of the MN with the capabilities of the GAARs. Having said that, if the purpose of the sending this information to the MN is to run the TAR selection algorithm there, then it would be prudent to filter out some of the GAARs (which don't satisfy the MN's requirements) and send only the remaining to the MN. That would reduce the bandwidth as well as power. Having said that, I disagree with this requirement which first forces a particular TAR selection aspect onto CAR discovery which I feel is totally not required. A better requirement is CAR discovery output MUST be made available to the TAR selection algorithm whereever it resides. >Please see the requirement above. No contradiction. The protocol allows >the MN to discover the GAAR and capabilities, the MN decides which one >it wants. >Nothing about the AR in control of anything. The MN may use a variant >of >IPv6 neighbor discovery, the AR may be involved somehow, but that's a >protocol design, not a requirement, choice. The requirement is clearly >that the MN does the discovery. [Govind] I don't agree to the fact that MN must alone do the discovery. >We now have two working group members who want this reqirement worded >just this way. Nothing about "as the MN expresses its preferences" or >"by the CAR discovery module" or anything else. And I believe Hesham has >also expressed a preference for this requirement. [Govind] Well I'm against it and I know others who have objected to this too. > >Anybody else out there have an opinion on this? Should we include this >requirement instead of requirement 3.4, which has the AR in control? [Govind] I agree that the requirement 3.4 may look biased toward a AR solution and we can re-word it. But to swing the pendulum to the other extreme which prohibits anything other than a MN based discovery is not correct. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 19:56:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01653 for ; Tue, 26 Mar 2002 19:56:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25029 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 19:56:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24508; Tue, 26 Mar 2002 19:54:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24468 for ; Tue, 26 Mar 2002 19:54:03 -0500 (EST) Received: from hotmail.com (f236.law9.hotmail.com [64.4.9.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01594 for ; Tue, 26 Mar 2002 19:54:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 16:53:33 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 00:53:33 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Tue, 26 Mar 2002 19:53:33 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 00:53:33.0403 (UTC) FILETIME=[D1D7A2B0:01C1D529] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >, > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those which satisfy > > the MN requirements, which is what CAR discovery was originally >about). > > > >No, that it sends all, along with the capabilities. Let me repeat the >requirement I would like to see (and Henrik apparently agrees) so we are >clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > [Govind] First what you are calling as CAR discovery is not CAR discovery. What you are saying is GAAR + associated capabilities discovery not CAR discovery therefore part of CAR discovery. CAR discovery matches the requirements of the MN with the capabilities of the GAARs. Having said that, if the purpose of the sending this information to the MN is to run the TAR selection algorithm there, then it would be prudent to filter out some of the GAARs (which don't satisfy the MN's requirements) and send only the remaining to the MN. That would reduce the bandwidth as well as power. Having said that, I disagree with this requirement which first forces a particular TAR selection aspect onto CAR discovery which I feel is totally not required. A better requirement is CAR discovery output MUST be made available to the TAR selection algorithm whereever it resides. >Please see the requirement above. No contradiction. The protocol allows >the MN to discover the GAAR and capabilities, the MN decides which one >it wants. >Nothing about the AR in control of anything. The MN may use a variant >of >IPv6 neighbor discovery, the AR may be involved somehow, but that's a >protocol design, not a requirement, choice. The requirement is clearly >that the MN does the discovery. [Govind] I don't agree to the fact that MN must alone do the discovery. >We now have two working group members who want this reqirement worded >just this way. Nothing about "as the MN expresses its preferences" or >"by the CAR discovery module" or anything else. And I believe Hesham has >also expressed a preference for this requirement. [Govind] Well I'm against it and I know others who have objected to this too. > >Anybody else out there have an opinion on this? Should we include this >requirement instead of requirement 3.4, which has the AR in control? [Govind] I agree that the requirement 3.4 may look biased toward a AR solution and we can re-word it. But to swing the pendulum to the other extreme which prohibits anything other than a MN based discovery is not correct. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 20:07:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01875 for ; Tue, 26 Mar 2002 20:07:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27471; Tue, 26 Mar 2002 20:05:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27388 for ; Tue, 26 Mar 2002 20:05:16 -0500 (EST) Received: from hotmail.com (f187.law7.hotmail.com [216.33.237.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01839 for ; Tue, 26 Mar 2002 20:05:14 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 17:04:46 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 01:04:46 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 01:04:46 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 01:04:46.0477 (UTC) FILETIME=[630693D0:01C1D52B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: -------------------------------------snip------------------------------ > > > > An example where such comparison may occur in network is when there is >only > > one interface on MN and it can listen only to radio beacons of >surrounding > > access points. This is similar to break-before-make handoff case. Here, >MN > > cannot receive capabilities of GAARs without letting go the previous > > connection. Do you think that such cases are not relevant and we should > > exclude such cases right at the problem statement/requirements stage? > >I think that designing for the one access technology case will cripple >the solution. [HC] I do not understand your comment. Are you essentially saying that "This case is irrelevant for CAR discovery" or "Completely AR unassisted CAR discovery is optimal for this case too". IMHO neither requirements nor problem statement should ignore any use cases. If they do, it should be explicitly stated so in the spec, so that designers are not misguided to apply solutions to cases for which they are not designed. BR, Hemant > > Regards, > Henrik > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 20:07:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01885 for ; Tue, 26 Mar 2002 20:07:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28111 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 20:07:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27471; Tue, 26 Mar 2002 20:05:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27388 for ; Tue, 26 Mar 2002 20:05:16 -0500 (EST) Received: from hotmail.com (f187.law7.hotmail.com [216.33.237.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01839 for ; Tue, 26 Mar 2002 20:05:14 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Mar 2002 17:04:46 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 01:04:46 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 01:04:46 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 01:04:46.0477 (UTC) FILETIME=[630693D0:01C1D52B] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: -------------------------------------snip------------------------------ > > > > An example where such comparison may occur in network is when there is >only > > one interface on MN and it can listen only to radio beacons of >surrounding > > access points. This is similar to break-before-make handoff case. Here, >MN > > cannot receive capabilities of GAARs without letting go the previous > > connection. Do you think that such cases are not relevant and we should > > exclude such cases right at the problem statement/requirements stage? > >I think that designing for the one access technology case will cripple >the solution. [HC] I do not understand your comment. Are you essentially saying that "This case is irrelevant for CAR discovery" or "Completely AR unassisted CAR discovery is optimal for this case too". IMHO neither requirements nor problem statement should ignore any use cases. If they do, it should be explicitly stated so in the spec, so that designers are not misguided to apply solutions to cases for which they are not designed. BR, Hemant > > Regards, > Henrik > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 20:22:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02256 for ; Tue, 26 Mar 2002 20:22:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28822; Tue, 26 Mar 2002 20:10:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28772 for ; Tue, 26 Mar 2002 20:10:18 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01965 for ; Tue, 26 Mar 2002 20:10:15 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id CAA09395 for ; Wed, 27 Mar 2002 02:07:26 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 02:10:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, You apparently did not read my recent posting. Cut'n'Paste: No, the requirement is just fine. It does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I think that's the essence of it. Do you oppose this? Why? Do you want to make things more complicated than they have to be? Henrik Hemant wrote: > > Hi James: > > There are serious shortcomings of the solution satisfying this requirement. > They are described below. How can we finalise this requirement unless it is > agreed that these pitfalls do not exist? > > For this, it might be good idea to visualise how the solution satisfying > this requirement looks like and violates basic tenets of engineering design, > namely efficiency. The solution satisfying this requirement is obliged to > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > big chunk of data (= number of GAARs times capability set of each). This > flood will occur either on active traffic connection which I call case (i) > (relevant for single interface MN and two-interface MN where second > interface is sleeping) or on second interface which I call case (ii) > (relevant for two interface MN with both interfaces awake). There are > following effects of this flood: > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > active traffic channel. > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > power wastage. This is because, after receiving these capabilities MN either > rejects the new AR (which is worst), and even if it selcects one why does it > need to receive capabilities of GAARs that do not matter for it. > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > sees. Which means the same information (which could be big enough) is > transmitted on downlink so many times. This takes up considerable fraction > of downlink capacity. > > 4. Limit on capability definition: This requirement restricts the definition > of capabilities to a very small size, otherwise all ARs will only be > transmitting GAAR capabilities to different MNs all the time. This means > capability set cannot be comprehensive and extensible. > > So, IMHO rather than counting who agrees to one statement requirement that > you proposed and who have not, we should first analyse above harmful effects > before deciding either way. > > Br, > Hemant > > > >From: "James Kempf" > >To: "Govind Krishnamurthi" , > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > >Examples of CAR discovery) > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > This seems contradictory to your earlier mails saying that there is > > > no basis for network based CAR discovery. So are you now agreeing > > > that network based CAR discovery has its place? > > > > > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 20:22:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02266 for ; Tue, 26 Mar 2002 20:22:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA02095 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 20:22:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28822; Tue, 26 Mar 2002 20:10:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28772 for ; Tue, 26 Mar 2002 20:10:18 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01965 for ; Tue, 26 Mar 2002 20:10:15 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id CAA09395 for ; Wed, 27 Mar 2002 02:07:26 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 02:10:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, You apparently did not read my recent posting. Cut'n'Paste: No, the requirement is just fine. It does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I think that's the essence of it. Do you oppose this? Why? Do you want to make things more complicated than they have to be? Henrik Hemant wrote: > > Hi James: > > There are serious shortcomings of the solution satisfying this requirement. > They are described below. How can we finalise this requirement unless it is > agreed that these pitfalls do not exist? > > For this, it might be good idea to visualise how the solution satisfying > this requirement looks like and violates basic tenets of engineering design, > namely efficiency. The solution satisfying this requirement is obliged to > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > big chunk of data (= number of GAARs times capability set of each). This > flood will occur either on active traffic connection which I call case (i) > (relevant for single interface MN and two-interface MN where second > interface is sleeping) or on second interface which I call case (ii) > (relevant for two interface MN with both interfaces awake). There are > following effects of this flood: > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > active traffic channel. > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > power wastage. This is because, after receiving these capabilities MN either > rejects the new AR (which is worst), and even if it selcects one why does it > need to receive capabilities of GAARs that do not matter for it. > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > sees. Which means the same information (which could be big enough) is > transmitted on downlink so many times. This takes up considerable fraction > of downlink capacity. > > 4. Limit on capability definition: This requirement restricts the definition > of capabilities to a very small size, otherwise all ARs will only be > transmitting GAAR capabilities to different MNs all the time. This means > capability set cannot be comprehensive and extensible. > > So, IMHO rather than counting who agrees to one statement requirement that > you proposed and who have not, we should first analyse above harmful effects > before deciding either way. > > Br, > Hemant > > > >From: "James Kempf" > >To: "Govind Krishnamurthi" , > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > >Examples of CAR discovery) > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > This seems contradictory to your earlier mails saying that there is > > > no basis for network based CAR discovery. So are you now agreeing > > > that network based CAR discovery has its place? > > > > > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 20:27:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02340 for ; Tue, 26 Mar 2002 20:27:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02015; Tue, 26 Mar 2002 20:22:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01981 for ; Tue, 26 Mar 2002 20:22:24 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02252 for ; Tue, 26 Mar 2002 20:22:21 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id CAA09568; Wed, 27 Mar 2002 02:19:31 +0100 From: "Henrik Levkowetz" To: "Govind Krishnamurthi" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 02:22:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Govind wrote: ...... > > >Govind wrote: > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally about). > > > >Here you seem to assume that one single AR has the full list of GAARs. > >I would argue that a flexible and scalable solution would have the final > >list of GAARs be composed from sublists provided by multiple ARs and the > >MN. > > [Govind] This may be possible. Ok. > > >It may be technically possible for all Currently Active Access Routers to > >transit their GAAR sublist to the MN, who transmit the lot together with > >its own GAAR sublist to one particular AR, who runs some algorithm and > >returns the result to the MN. > > > >But it certainly doesnt't seem either sensible or optimal to me. > > [Govind] WHat do you mean currently active Access routers? The MN is > currently attached just to one AR and we are talking about the GAARs of > this currently attached AR to which the MN may potentially handoff too. No, no, no, you cannot assume that only one of the N possible interfaces the MN may have is in use. At any given time, zero, N or any number in between of the interfaces may be in use, and may provide different lists of GAARs. Additionally, the MN's interfaces scanning for APs may result in GAARs which are not on any of the other lists. > > Second, I agree what you propose is neither sensible not optimal. > But I don't think anyone is suggesting that. To do this we have to > go into solution space. But transmitting the GAARs and their capabilties > to the MN has its bandwidth and power constraints too. > I am not arguing against one another. All I'm saying is we shouldn't > totally reject AR based CAR discovery now. Ok. I'm arguing that we should reject CAR discovery which is not MN centric. The ARs will (must!) have their role in this, but an AR centric scheme does not seem to make sense, and I believe that it would be good to get that established. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 20:27:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02349 for ; Tue, 26 Mar 2002 20:27:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03320 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 20:27:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02015; Tue, 26 Mar 2002 20:22:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01981 for ; Tue, 26 Mar 2002 20:22:24 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02252 for ; Tue, 26 Mar 2002 20:22:21 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id CAA09568; Wed, 27 Mar 2002 02:19:31 +0100 From: "Henrik Levkowetz" To: "Govind Krishnamurthi" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 02:22:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Govind wrote: ...... > > >Govind wrote: > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally about). > > > >Here you seem to assume that one single AR has the full list of GAARs. > >I would argue that a flexible and scalable solution would have the final > >list of GAARs be composed from sublists provided by multiple ARs and the > >MN. > > [Govind] This may be possible. Ok. > > >It may be technically possible for all Currently Active Access Routers to > >transit their GAAR sublist to the MN, who transmit the lot together with > >its own GAAR sublist to one particular AR, who runs some algorithm and > >returns the result to the MN. > > > >But it certainly doesnt't seem either sensible or optimal to me. > > [Govind] WHat do you mean currently active Access routers? The MN is > currently attached just to one AR and we are talking about the GAARs of > this currently attached AR to which the MN may potentially handoff too. No, no, no, you cannot assume that only one of the N possible interfaces the MN may have is in use. At any given time, zero, N or any number in between of the interfaces may be in use, and may provide different lists of GAARs. Additionally, the MN's interfaces scanning for APs may result in GAARs which are not on any of the other lists. > > Second, I agree what you propose is neither sensible not optimal. > But I don't think anyone is suggesting that. To do this we have to > go into solution space. But transmitting the GAARs and their capabilties > to the MN has its bandwidth and power constraints too. > I am not arguing against one another. All I'm saying is we shouldn't > totally reject AR based CAR discovery now. Ok. I'm arguing that we should reject CAR discovery which is not MN centric. The ARs will (must!) have their role in this, but an AR centric scheme does not seem to make sense, and I believe that it would be good to get that established. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 20:31:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02459 for ; Tue, 26 Mar 2002 20:31:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03534; Tue, 26 Mar 2002 20:28:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03480 for ; Tue, 26 Mar 2002 20:28:31 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02390 for ; Tue, 26 Mar 2002 20:28:28 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id CAA09667; Wed, 27 Mar 2002 02:25:36 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 02:28:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant wrote: > > Hi Henrik: > > > -------------------------------------snip------------------------------ > > > > > > An example where such comparison may occur in network is when there is > >only > > > one interface on MN and it can listen only to radio beacons of > >surrounding > > > access points. This is similar to break-before-make handoff case. Here, > >MN > > > cannot receive capabilities of GAARs without letting go the previous > > > connection. Do you think that such cases are not relevant and we should > > > exclude such cases right at the problem statement/requirements stage? > > > >I think that designing for the one access technology case will cripple > >the solution. > > [HC] I do not understand your comment. Are you essentially saying that "This > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > discovery is optimal for this case too". No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery is optimal ... for any case. I'm saying: I think that designing for the one access technology case will cripple the solution. > > IMHO neither requirements nor problem statement should ignore any use cases. > If they do, it should be explicitly stated so in the spec, so that designers > are not misguided to apply solutions to cases for which they are not > designed. Nobody's ignoring any use cases. But if you focus on one sample to the detriment of the rest, it will cripple your solution. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 20:31:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02469 for ; Tue, 26 Mar 2002 20:31:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04204 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 20:31:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03534; Tue, 26 Mar 2002 20:28:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03480 for ; Tue, 26 Mar 2002 20:28:31 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02390 for ; Tue, 26 Mar 2002 20:28:28 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id CAA09667; Wed, 27 Mar 2002 02:25:36 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 02:28:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant wrote: > > Hi Henrik: > > > -------------------------------------snip------------------------------ > > > > > > An example where such comparison may occur in network is when there is > >only > > > one interface on MN and it can listen only to radio beacons of > >surrounding > > > access points. This is similar to break-before-make handoff case. Here, > >MN > > > cannot receive capabilities of GAARs without letting go the previous > > > connection. Do you think that such cases are not relevant and we should > > > exclude such cases right at the problem statement/requirements stage? > > > >I think that designing for the one access technology case will cripple > >the solution. > > [HC] I do not understand your comment. Are you essentially saying that "This > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > discovery is optimal for this case too". No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery is optimal ... for any case. I'm saying: I think that designing for the one access technology case will cripple the solution. > > IMHO neither requirements nor problem statement should ignore any use cases. > If they do, it should be explicitly stated so in the spec, so that designers > are not misguided to apply solutions to cases for which they are not > designed. Nobody's ignoring any use cases. But if you focus on one sample to the detriment of the rest, it will cripple your solution. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Mar 26 21:15:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03468 for ; Tue, 26 Mar 2002 21:15:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11488; Tue, 26 Mar 2002 21:03:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11449 for ; Tue, 26 Mar 2002 21:03:10 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03185 for ; Tue, 26 Mar 2002 21:03:07 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2R22eK13962; Tue, 26 Mar 2002 18:02:40 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn3-231.cisco.com [10.21.64.231]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACK98927; Tue, 26 Mar 2002 18:02:50 -0800 (PST) Message-Id: <4.3.2.7.2.20020326204705.024a5f68@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Mar 2002 21:01:31 -0500 To: "Hemant Chaskar" , seamoby@ietf.org From: "Michael A. Ramalho" Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org At 05:37 PM 3/26/2002 +0000, Hemant Chaskar wrote: >Hi: > >I think the main discussion issue that resulted in this email was: > >What is the cost of scanning APs on other connection (this involves link >establishment, authentication as you said, obtaining IP address, receiving >capabilities). No. The scanning only involves "listening". *IF* you decide that the candidate is worth pursuing, then - and only then - do you waste (the more significant) transmit power to associate/authenticate/etc... So ... if you are on an AP with strong S/N and you hear 4 other candidate APs that have poor S/N ... you will probably do nothing terribly power consuming .... perhaps a re-scan with relatively long inter-scan times. If the S/N is tanking on the link you are using ... then you may want to look harder (scan more often) ... and even try to associate with other APs before the one you are on dies. I see very little extra power being consumed if you connection has relatively high S/N. Also remember that the receiver takes much less power than the transmitter (details vary ... but less than 1/3 of the total power I think is typical ... someone from a WLAN manufacturer, like Flarion, might want to provide a more precise estimate). >Note that, all this work (and associated power) will be wasted if the user >does not like the capabilites at the end of day. The heuristics driving the above decisions is simply an optimization problem that trades off the availability/seamlessness of your connection with the (optimization-based) "cost" of the extra power consumption. Different strokes for different folks .... and thus another reason for the MN to decide. >Please let us know if you think this to be a relevant consideration at all. > >Please ignore my comment about 3 or more APs. ACK Hope this helps, Michael Ramalho >Hemant > > > > >>From: "Michael A. Ramalho" >>To: "James Kempf" , "Hemant Chaskar" >>, >>Subject: Re: [Seamoby] Comments on the requirements draft >>Date: Tue, 26 Mar 2002 11:14:13 -0500 >> >>At 01:59 PM 3/25/2002 -0800, James Kempf wrote: >> >>> > Just to be ultra clear - Luxury of two interfaces is not a generic >>> > assumption for CAR discovery problem formulation. Two-connection WLAN >>>card >>> > is good for 2 APs, but what if there are 3 or 4 or 5 APs. >>> > >> >>This may sound like a stupid statement for some .... but even a single >>WLAN card can scan during periods of (relative) inactivity to search for >>beacons of other APs. >> >>Given this ability/possibility (depends on how the drivers were written), >>one would assume that two cards are more than enough to search >>for the (next) highest signal quality AP it can authenticate (or get >>required QoS) on. Thus while maintaining an existing session >>on one card - you try to authenticate on the next best AP (in some >>sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE >>WLAN card may be possible in the future with "fast-retunable" WLAN >>cards - but it is clearly doable today with two cards. You only need >>to define heuristics for your MNs (e.g., default routes, etc.) to send >>the packets to/from the preferred association. >> >>So ... why exactly doesn't the two WLAN card case handle an >>arbitrary number of potential APs? >> >> >>>Does the MN have different interface cards for each or are they the >>>same? >>> >>> jak >>> >>> >>> >>> >>>_______________________________________________ >>>Seamoby mailing list >>>Seamoby@ietf.org >>>https://www1.ietf.org/mailman/listinfo/seamoby >> >> >>Michael A. Ramalho, Ph.D. >>Office email: mramalho@cisco.com >>Personal email: mar42@cornell.edu >>Office: +1.732.449.5762 >>Cell: +1.732.809.0188 >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Mar 26 21:15:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03478 for ; Tue, 26 Mar 2002 21:15:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14512 for seamoby-archive@odin.ietf.org; Tue, 26 Mar 2002 21:15:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11488; Tue, 26 Mar 2002 21:03:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11449 for ; Tue, 26 Mar 2002 21:03:10 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03185 for ; Tue, 26 Mar 2002 21:03:07 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2R22eK13962; Tue, 26 Mar 2002 18:02:40 -0800 (PST) Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn3-231.cisco.com [10.21.64.231]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACK98927; Tue, 26 Mar 2002 18:02:50 -0800 (PST) Message-Id: <4.3.2.7.2.20020326204705.024a5f68@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Mar 2002 21:01:31 -0500 To: "Hemant Chaskar" , seamoby@ietf.org From: "Michael A. Ramalho" Subject: Re: [Seamoby] Comments on the requirements draft In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org At 05:37 PM 3/26/2002 +0000, Hemant Chaskar wrote: >Hi: > >I think the main discussion issue that resulted in this email was: > >What is the cost of scanning APs on other connection (this involves link >establishment, authentication as you said, obtaining IP address, receiving >capabilities). No. The scanning only involves "listening". *IF* you decide that the candidate is worth pursuing, then - and only then - do you waste (the more significant) transmit power to associate/authenticate/etc... So ... if you are on an AP with strong S/N and you hear 4 other candidate APs that have poor S/N ... you will probably do nothing terribly power consuming .... perhaps a re-scan with relatively long inter-scan times. If the S/N is tanking on the link you are using ... then you may want to look harder (scan more often) ... and even try to associate with other APs before the one you are on dies. I see very little extra power being consumed if you connection has relatively high S/N. Also remember that the receiver takes much less power than the transmitter (details vary ... but less than 1/3 of the total power I think is typical ... someone from a WLAN manufacturer, like Flarion, might want to provide a more precise estimate). >Note that, all this work (and associated power) will be wasted if the user >does not like the capabilites at the end of day. The heuristics driving the above decisions is simply an optimization problem that trades off the availability/seamlessness of your connection with the (optimization-based) "cost" of the extra power consumption. Different strokes for different folks .... and thus another reason for the MN to decide. >Please let us know if you think this to be a relevant consideration at all. > >Please ignore my comment about 3 or more APs. ACK Hope this helps, Michael Ramalho >Hemant > > > > >>From: "Michael A. Ramalho" >>To: "James Kempf" , "Hemant Chaskar" >>, >>Subject: Re: [Seamoby] Comments on the requirements draft >>Date: Tue, 26 Mar 2002 11:14:13 -0500 >> >>At 01:59 PM 3/25/2002 -0800, James Kempf wrote: >> >>> > Just to be ultra clear - Luxury of two interfaces is not a generic >>> > assumption for CAR discovery problem formulation. Two-connection WLAN >>>card >>> > is good for 2 APs, but what if there are 3 or 4 or 5 APs. >>> > >> >>This may sound like a stupid statement for some .... but even a single >>WLAN card can scan during periods of (relative) inactivity to search for >>beacons of other APs. >> >>Given this ability/possibility (depends on how the drivers were written), >>one would assume that two cards are more than enough to search >>for the (next) highest signal quality AP it can authenticate (or get >>required QoS) on. Thus while maintaining an existing session >>on one card - you try to authenticate on the next best AP (in some >>sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE >>WLAN card may be possible in the future with "fast-retunable" WLAN >>cards - but it is clearly doable today with two cards. You only need >>to define heuristics for your MNs (e.g., default routes, etc.) to send >>the packets to/from the preferred association. >> >>So ... why exactly doesn't the two WLAN card case handle an >>arbitrary number of potential APs? >> >> >>>Does the MN have different interface cards for each or are they the >>>same? >>> >>> jak >>> >>> >>> >>> >>>_______________________________________________ >>>Seamoby mailing list >>>Seamoby@ietf.org >>>https://www1.ietf.org/mailman/listinfo/seamoby >> >> >>Michael A. Ramalho, Ph.D. >>Office email: mramalho@cisco.com >>Personal email: mar42@cornell.edu >>Office: +1.732.449.5762 >>Cell: +1.732.809.0188 >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 04:00:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19854 for ; Wed, 27 Mar 2002 04:00:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20782; Wed, 27 Mar 2002 03:57:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20750 for ; Wed, 27 Mar 2002 03:57:03 -0500 (EST) Received: from hotmail.com (oe14.law4.hotmail.com [216.33.148.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19778 for ; Wed, 27 Mar 2002 03:57:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 00:56:33 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:01:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 27 Mar 2002 08:56:33.0257 (UTC) FILETIME=[4B2E6D90:01C1D56D] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, I hope I am not too late for this thread of discussion. My comments are inline. Thanks. Eunsoo ----- Original Message ----- From: "Henrik Levkowetz" To: Sent: Tuesday, March 26, 2002 5:10 PM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR > information, it does not require *on-demand operation*, it expresses exactly > what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > [eunsoo] I think the difference here is whether the AR MUST provide the MN with GAAR information along with capabilities REGARDLESS of what the MN wants. That is, even if the MN does not have CAR discovery stack in its kernel, the AR will send the MN the GAAR information. As Govind pointed out, if the transmitted information is large, we may not be happy if the transmitted information could be reduced. Right, it is about efficiency and thus optimization. Certainly optimization is not a bad thing. James expressed his concern that premature optimization may put more trouble down the road. Right. Also we might want to change the protocol pretty shortly after the spec is set and tried because of its obvious inefficiency, if any. Which is not desirable either. I'd like to suggest we discuss what could be the undesirable side-effects of the optimization. If they are obvious, the issue becomes easier. If not, I am not sure it is good just trashing an obvious optimization idea from the beginning because it is about optimization. I don't think we should not focus on optimization of every details from the beginning. But I think it is good if we can leave a room for optimization if possible. And about being MN-centric. I am not sure whether the MN's expressing its requirements is NOT MN-centric. One may say the AR may not understand the requirements very well. Right. I think we need better implementation in such a case. Regarding how an AR knows which interfaces are available with a MN, certainly that information should be provided by the MN to the AR. Is the job complex? It seems subjective to me. I think we can design at least a not-too-complex way doing it. GAAR->CAR is a filtering operation. Some folks say the MN should do TAR selection and thus the MN should do GAAR->CAR filtering. If some folks say ONLY the MN should be able to do GAAR->CAR->TAR filtering, I am not sure whether it is a technical argument or somewhat philosophical one. Couldn't we open a room for other cases? If not, why not? Let say, a network provider runs a WWAN and a WLAN and she wants to control load on each access network. Thus the network wants to be able to recommend a TAR to the MN. Is it a bad thing? BTW, even the above requirement does not prohibit the network from getting involved in handoff decision or selecting the TAR. It depends on really the handoff mechanism. I understood that the CAR discovery protocol should NOT be bound to any specific mobility management scheme. I think now some folks are trying to put constraints on CAR discovery based on a certain picture of mobility management scheme. Last thing: I think CAR discovery consists of two tasks: GAAR discovery and GAAR->CAR filtering. In a larger picture, we have the following tasks for handoff decision: a. GAAR discovery b. distribution of GAAR information (with capabilities) or accessing the information c. GAAR -> CAR filtering d. distribution of CAR information or accessing the information e. CAR -> TAR filtering It seems that we all agree that CAR->TAR filtering is out of scope of the CAR discovery protoocol. But some folks have an idea about where CAR->TAR filtering should happen and thus they want to pur constraints on "distribution of CAR information of access the information" or other previous steps. I have two questions: what are in scope of the CAR discovery protocol among a, b, c, and d in the above? Then what are the assumptions we agree on about those tasks out of scope of the protocol such as e in the above? Or should we have such agreements? Thanks. Eunsoo 1) Is it undesirable > > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > Henrik > > Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this requirement. > > They are described below. How can we finalise this requirement unless it is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering design, > > namely efficiency. The solution satisfying this requirement is obliged to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case (i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > > power wastage. This is because, after receiving these capabilities MN either > > rejects the new AR (which is worst), and even if it selcects one why does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement that > > you proposed and who have not, we should first analyse above harmful effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 04:00:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19863 for ; Wed, 27 Mar 2002 04:00:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA21874 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 04:00:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20782; Wed, 27 Mar 2002 03:57:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20750 for ; Wed, 27 Mar 2002 03:57:03 -0500 (EST) Received: from hotmail.com (oe14.law4.hotmail.com [216.33.148.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19778 for ; Wed, 27 Mar 2002 03:57:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 00:56:33 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:01:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 27 Mar 2002 08:56:33.0257 (UTC) FILETIME=[4B2E6D90:01C1D56D] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, I hope I am not too late for this thread of discussion. My comments are inline. Thanks. Eunsoo ----- Original Message ----- From: "Henrik Levkowetz" To: Sent: Tuesday, March 26, 2002 5:10 PM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR > information, it does not require *on-demand operation*, it expresses exactly > what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > [eunsoo] I think the difference here is whether the AR MUST provide the MN with GAAR information along with capabilities REGARDLESS of what the MN wants. That is, even if the MN does not have CAR discovery stack in its kernel, the AR will send the MN the GAAR information. As Govind pointed out, if the transmitted information is large, we may not be happy if the transmitted information could be reduced. Right, it is about efficiency and thus optimization. Certainly optimization is not a bad thing. James expressed his concern that premature optimization may put more trouble down the road. Right. Also we might want to change the protocol pretty shortly after the spec is set and tried because of its obvious inefficiency, if any. Which is not desirable either. I'd like to suggest we discuss what could be the undesirable side-effects of the optimization. If they are obvious, the issue becomes easier. If not, I am not sure it is good just trashing an obvious optimization idea from the beginning because it is about optimization. I don't think we should not focus on optimization of every details from the beginning. But I think it is good if we can leave a room for optimization if possible. And about being MN-centric. I am not sure whether the MN's expressing its requirements is NOT MN-centric. One may say the AR may not understand the requirements very well. Right. I think we need better implementation in such a case. Regarding how an AR knows which interfaces are available with a MN, certainly that information should be provided by the MN to the AR. Is the job complex? It seems subjective to me. I think we can design at least a not-too-complex way doing it. GAAR->CAR is a filtering operation. Some folks say the MN should do TAR selection and thus the MN should do GAAR->CAR filtering. If some folks say ONLY the MN should be able to do GAAR->CAR->TAR filtering, I am not sure whether it is a technical argument or somewhat philosophical one. Couldn't we open a room for other cases? If not, why not? Let say, a network provider runs a WWAN and a WLAN and she wants to control load on each access network. Thus the network wants to be able to recommend a TAR to the MN. Is it a bad thing? BTW, even the above requirement does not prohibit the network from getting involved in handoff decision or selecting the TAR. It depends on really the handoff mechanism. I understood that the CAR discovery protocol should NOT be bound to any specific mobility management scheme. I think now some folks are trying to put constraints on CAR discovery based on a certain picture of mobility management scheme. Last thing: I think CAR discovery consists of two tasks: GAAR discovery and GAAR->CAR filtering. In a larger picture, we have the following tasks for handoff decision: a. GAAR discovery b. distribution of GAAR information (with capabilities) or accessing the information c. GAAR -> CAR filtering d. distribution of CAR information or accessing the information e. CAR -> TAR filtering It seems that we all agree that CAR->TAR filtering is out of scope of the CAR discovery protoocol. But some folks have an idea about where CAR->TAR filtering should happen and thus they want to pur constraints on "distribution of CAR information of access the information" or other previous steps. I have two questions: what are in scope of the CAR discovery protocol among a, b, c, and d in the above? Then what are the assumptions we agree on about those tasks out of scope of the protocol such as e in the above? Or should we have such agreements? Thanks. Eunsoo 1) Is it undesirable > > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > Henrik > > Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this requirement. > > They are described below. How can we finalise this requirement unless it is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering design, > > namely efficiency. The solution satisfying this requirement is obliged to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case (i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > > power wastage. This is because, after receiving these capabilities MN either > > rejects the new AR (which is worst), and even if it selcects one why does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement that > > you proposed and who have not, we should first analyse above harmful effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 06:02:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22200 for ; Wed, 27 Mar 2002 06:02:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22445; Wed, 27 Mar 2002 05:56:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22385 for ; Wed, 27 Mar 2002 05:56:17 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22126 for ; Wed, 27 Mar 2002 05:56:15 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 942F022FCF; Wed, 27 Mar 2002 12:55:38 +0200 (EET) Date: Wed, 27 Mar 2002 12:53:41 +0200 (EET) From: Teemu Rinta-aho To: Henrik Levkowetz Cc: Subject: RE: [Seamoby] Examples of CAR discovery In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik, On Wed, 27 Mar 2002, Henrik Levkowetz wrote: > > > > An example where such comparison may occur in network is when there is > > >only > > > > one interface on MN and it can listen only to radio beacons of > > >surrounding > > > > access points. This is similar to break-before-make handoff case. Here, > > >MN > > > > cannot receive capabilities of GAARs without letting go the previous > > > > connection. Do you think that such cases are not relevant and we should > > > > exclude such cases right at the problem statement/requirements stage? > > > > > >I think that designing for the one access technology case will cripple > > >the solution. > > > > [HC] I do not understand your comment. Are you essentially saying that "This > > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > > discovery is optimal for this case too". > > No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery > is optimal ... for any case. I'm saying: > > I think that designing for the one access technology case will cripple > the solution. It is not clear to me what you mean with "one access technology". Do you mean that the case where the MN has only one interface should not be supported, or do you mean the people discussing the requirements assume something about the underlying link-layer technology? BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 06:02:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22210 for ; Wed, 27 Mar 2002 06:02:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23815 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 06:02:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22445; Wed, 27 Mar 2002 05:56:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22385 for ; Wed, 27 Mar 2002 05:56:17 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22126 for ; Wed, 27 Mar 2002 05:56:15 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 942F022FCF; Wed, 27 Mar 2002 12:55:38 +0200 (EET) Date: Wed, 27 Mar 2002 12:53:41 +0200 (EET) From: Teemu Rinta-aho To: Henrik Levkowetz Cc: Subject: RE: [Seamoby] Examples of CAR discovery In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik, On Wed, 27 Mar 2002, Henrik Levkowetz wrote: > > > > An example where such comparison may occur in network is when there is > > >only > > > > one interface on MN and it can listen only to radio beacons of > > >surrounding > > > > access points. This is similar to break-before-make handoff case. Here, > > >MN > > > > cannot receive capabilities of GAARs without letting go the previous > > > > connection. Do you think that such cases are not relevant and we should > > > > exclude such cases right at the problem statement/requirements stage? > > > > > >I think that designing for the one access technology case will cripple > > >the solution. > > > > [HC] I do not understand your comment. Are you essentially saying that "This > > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > > discovery is optimal for this case too". > > No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery > is optimal ... for any case. I'm saying: > > I think that designing for the one access technology case will cripple > the solution. It is not clear to me what you mean with "one access technology". Do you mean that the case where the MN has only one interface should not be supported, or do you mean the people discussing the requirements assume something about the underlying link-layer technology? BR, Teemu -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 06:17:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22301 for ; Wed, 27 Mar 2002 06:17:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26748; Wed, 27 Mar 2002 06:14:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26718 for ; Wed, 27 Mar 2002 06:14:35 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22283 for ; Wed, 27 Mar 2002 06:14:32 -0500 (EST) Received: from chardonnay (ipunplugged.com [192.168.4.5]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA18872; Wed, 27 Mar 2002 12:11:36 +0100 From: "Henrik Levkowetz" To: "Teemu Rinta-aho" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:14:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Teemu wrote: > > > > > An example where such comparison may occur in network is when there is > > > >only > > > > > one interface on MN and it can listen only to radio beacons of > > > >surrounding > > > > > access points. This is similar to break-before-make handoff case. Here, > > > >MN > > > > > cannot receive capabilities of GAARs without letting go the previous > > > > > connection. Do you think that such cases are not relevant and we should > > > > > exclude such cases right at the problem statement/requirements stage? > > > > > > > >I think that designing for the one access technology case will cripple > > > >the solution. > > > > > > [HC] I do not understand your comment. Are you essentially saying that "This > > > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > > > discovery is optimal for this case too". > > > > No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery > > is optimal ... for any case. I'm saying: > > > > I think that designing for the one access technology case will cripple > > the solution. > > It is not clear to me what you mean with "one access technology". Do you > mean that the case where the MN has only one interface should not be > supported, or do you mean the people discussing the requirements assume > something about the underlying link-layer technology? Neither. The "one access technology case" is the case where your mobile node only has one access technology, i.e. only one interface, and will not have more. Designing for this case in particular, instead of designing for the general case with multiple interfaces and technologies, will cripple our solution. Designing for the general case will permit handling this special case, and many many others. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 06:21:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22383 for ; Wed, 27 Mar 2002 06:21:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27924; Wed, 27 Mar 2002 06:19:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27846 for ; Wed, 27 Mar 2002 06:19:01 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22367 for ; Wed, 27 Mar 2002 06:19:00 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 175C222FCF; Wed, 27 Mar 2002 13:18:31 +0200 (EET) Date: Wed, 27 Mar 2002 13:16:33 +0200 (EET) From: Teemu Rinta-aho To: Henrik Levkowetz Cc: Subject: RE: [Seamoby] Examples of CAR discovery In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Wed, 27 Mar 2002, Henrik Levkowetz wrote: > > > No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery > > > is optimal ... for any case. I'm saying: > > > > > > I think that designing for the one access technology case will cripple > > > the solution. > > > > It is not clear to me what you mean with "one access technology". Do you > > mean that the case where the MN has only one interface should not be > > supported, or do you mean the people discussing the requirements assume > > something about the underlying link-layer technology? > > Neither. > > The "one access technology case" is the case where your mobile node only > has one access technology, i.e. only one interface, and will not have more. > > Designing for this case in particular, instead of designing for the general > case with multiple interfaces and technologies, will cripple our solution. > > Designing for the general case will permit handling this special case, > and many many others. OK. Thanks for the clarification. I agree with that. -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 06:21:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22394 for ; Wed, 27 Mar 2002 06:21:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28436 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 06:21:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27924; Wed, 27 Mar 2002 06:19:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27846 for ; Wed, 27 Mar 2002 06:19:01 -0500 (EST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22367 for ; Wed, 27 Mar 2002 06:19:00 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 175C222FCF; Wed, 27 Mar 2002 13:18:31 +0200 (EET) Date: Wed, 27 Mar 2002 13:16:33 +0200 (EET) From: Teemu Rinta-aho To: Henrik Levkowetz Cc: Subject: RE: [Seamoby] Examples of CAR discovery In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org On Wed, 27 Mar 2002, Henrik Levkowetz wrote: > > > No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery > > > is optimal ... for any case. I'm saying: > > > > > > I think that designing for the one access technology case will cripple > > > the solution. > > > > It is not clear to me what you mean with "one access technology". Do you > > mean that the case where the MN has only one interface should not be > > supported, or do you mean the people discussing the requirements assume > > something about the underlying link-layer technology? > > Neither. > > The "one access technology case" is the case where your mobile node only > has one access technology, i.e. only one interface, and will not have more. > > Designing for this case in particular, instead of designing for the general > case with multiple interfaces and technologies, will cripple our solution. > > Designing for the general case will permit handling this special case, > and many many others. OK. Thanks for the clarification. I agree with that. -- Teemu Rinta-aho Tel: +358 9 299 3078 NomadicLab, Ericsson Research Fax: +358 9 299 5055 Oy L M Ericsson Ab Mobile: +358 40 562 3066 FIN-02131 Espoo, Finland E-mail: teemu.rinta-aho@nomadiclab.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 07:26:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22308 for ; Wed, 27 Mar 2002 06:17:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27384 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 06:17:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26748; Wed, 27 Mar 2002 06:14:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26718 for ; Wed, 27 Mar 2002 06:14:35 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22283 for ; Wed, 27 Mar 2002 06:14:32 -0500 (EST) Received: from chardonnay (ipunplugged.com [192.168.4.5]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA18872; Wed, 27 Mar 2002 12:11:36 +0100 From: "Henrik Levkowetz" To: "Teemu Rinta-aho" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:14:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Teemu wrote: > > > > > An example where such comparison may occur in network is when there is > > > >only > > > > > one interface on MN and it can listen only to radio beacons of > > > >surrounding > > > > > access points. This is similar to break-before-make handoff case. Here, > > > >MN > > > > > cannot receive capabilities of GAARs without letting go the previous > > > > > connection. Do you think that such cases are not relevant and we should > > > > > exclude such cases right at the problem statement/requirements stage? > > > > > > > >I think that designing for the one access technology case will cripple > > > >the solution. > > > > > > [HC] I do not understand your comment. Are you essentially saying that "This > > > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > > > discovery is optimal for this case too". > > > > No, i'm not saying this case is irrelevant, or that AR unassisted CAR discovery > > is optimal ... for any case. I'm saying: > > > > I think that designing for the one access technology case will cripple > > the solution. > > It is not clear to me what you mean with "one access technology". Do you > mean that the case where the MN has only one interface should not be > supported, or do you mean the people discussing the requirements assume > something about the underlying link-layer technology? Neither. The "one access technology case" is the case where your mobile node only has one access technology, i.e. only one interface, and will not have more. Designing for this case in particular, instead of designing for the general case with multiple interfaces and technologies, will cripple our solution. Designing for the general case will permit handling this special case, and many many others. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 08:51:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27729 for ; Wed, 27 Mar 2002 08:51:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04166; Wed, 27 Mar 2002 08:46:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04138 for ; Wed, 27 Mar 2002 08:46:37 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27585 for ; Wed, 27 Mar 2002 08:46:31 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RDkWoq024780 for ; Wed, 27 Mar 2002 14:46:32 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 14:46:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:36:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C0741B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Dirk.Trossen@nokia.com, teemu.rinta-aho@nomadiclab.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on the requirements draft Date: Wed, 27 Mar 2002 14:46:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > - CAR/GAAR discovery MUST be scalable. In the future, there > might be geographical locations with several (hundreds) > of overlapping access points, especially when PANs emerge. > This kind of situation might lead into problems when the > ARs behind these APs have to constantly update their > knowledge of their GAARs. > > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where > actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But > even then, > what counts is the number of ARs that have overlapping APs > with APs of > other ARs. I don't quite see that this number would reach > several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. => This is why the model needs to be revised. Why can't you see hundreds of coverage areas ? Is tens better? What do you mean Bluetooth is not large enough? It's large enough for a LAN coverage. Anyhow, hundreds doesn't imply a 100 different technologies. Shops, houses, cellular...etc can all overlap. I don't think 10 or a hundred is the point here, the point is a bookshop installing a WLAN will not go around telling everyone about it, why would they ?? Hesham > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the > lack of identification > and capability knowledge through CAR) not considered as a > CAR, it should still > be possible to handover to this AR? This is indeed true but > not within the scope > of CAR discovery. Since CAR discovery only gives you a set > of CARs (which need to > be identified for that), it should be ok that a CAR > solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR > did not allow the > CAR solution's GAAR identifitication - another reasons > might be that the non-CAR > did not reveal capabilities). However, if the MN (or the > AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) > makes the decision to > handoff to this non-CAR AR, that's fine and still possible. > But this is TAR > selection, which is not within the scope of CAR discovery. > CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's > requirements), which is ONE > input to TAR selection (wherever latter is implemented). > Another input might be > the detection of non-CAR ARs which you might consider in > your TAR selection algorithm > as well. > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time > on CAR or not? > If you have a TAR selection scheme that resides in the MN, > it is fairly > easy to do so. If your signal strength fades for instance > too fast, you just > skip CAR discovery and select one of the AR from which you > receive a current > beacon. But again, this is TAR selection and not within the > scope of the problem. > But if you choose to do CAR (wherever it is implemented), > it will always add > to your handover time since you have to run certain > mechanisms. How this tradeoff > can be determined is not clear to me and looks like an > implementation issue in > the entity that runs the TAR selection (which again use CAR > discovery as an input). > > General thoughts: > > How can an AR recognize its GAARs without the help of the MN > or the link-layer protocols? > > This means that the amount of packets sent over the air necessarily > increases, doesn't it? I mean, if the AR doesn't get the > information about > GAARs from the MN, then it must somehow sense the GAARs > presence through > the APs. But the latter is of course impossible between APs > of different > link layers. > > [DOT] Good question ;-) But is it mentioned somewhere that the > identification of GAARs must not be a combined job between > AR and MN? Or it > might even be entirely based in the MN? Certainly, the > AR-only solution > sounds kind of impossible for me, too. > > Best Regards, > > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 08:51:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27737 for ; Wed, 27 Mar 2002 08:51:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05611 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 08:51:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04166; Wed, 27 Mar 2002 08:46:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04138 for ; Wed, 27 Mar 2002 08:46:37 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27585 for ; Wed, 27 Mar 2002 08:46:31 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RDkWoq024780 for ; Wed, 27 Mar 2002 14:46:32 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 14:46:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:36:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C0741B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Dirk.Trossen@nokia.com, teemu.rinta-aho@nomadiclab.com, seamoby@ietf.org Subject: RE: [Seamoby] Comments on the requirements draft Date: Wed, 27 Mar 2002 14:46:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > - CAR/GAAR discovery MUST be scalable. In the future, there > might be geographical locations with several (hundreds) > of overlapping access points, especially when PANs emerge. > This kind of situation might lead into problems when the > ARs behind these APs have to constantly update their > knowledge of their GAARs. > > [DOT] I certainly agree with scalability, just some comments to > the number of several hundreds of overlapping access points. Even > when I consider PANs, I can hardly think of scenarios where > actually > hundreds of coverage areas overlap. Bluetooth coverage areas are not > large enough, and I doubt that we had so many WLAN APs. But > even then, > what counts is the number of ARs that have overlapping APs > with APs of > other ARs. I don't quite see that this number would reach > several hundreds. > Maybe you could elaborate a bit on the scenarios you have in mind. => This is why the model needs to be revised. Why can't you see hundreds of coverage areas ? Is tens better? What do you mean Bluetooth is not large enough? It's large enough for a LAN coverage. Anyhow, hundreds doesn't imply a 100 different technologies. Shops, houses, cellular...etc can all overlap. I don't think 10 or a hundred is the point here, the point is a bookshop installing a WLAN will not go around telling everyone about it, why would they ?? Hesham > > 3.X INTEROPERABILITY > > - Interoperability MUST exist with non-CAR ARs. > > [DOT] How do you mean this? If a non-CAR is (due to the > lack of identification > and capability knowledge through CAR) not considered as a > CAR, it should still > be possible to handover to this AR? This is indeed true but > not within the scope > of CAR discovery. Since CAR discovery only gives you a set > of CARs (which need to > be identified for that), it should be ok that a CAR > solution does not include > these non-CAR ARs (one reason might be that the non-CAR AR > did not allow the > CAR solution's GAAR identifitication - another reasons > might be that the non-CAR > did not reveal capabilities). However, if the MN (or the > AR) would find any other > means to identify this non-CAR AR, and the MN (or the AR) > makes the decision to > handoff to this non-CAR AR, that's fine and still possible. > But this is TAR > selection, which is not within the scope of CAR discovery. > CAR discovery only > gives you a list of CARs (i.e., ARs that match MN's > requirements), which is ONE > input to TAR selection (wherever latter is implemented). > Another input might be > the detection of non-CAR ARs which you might consider in > your TAR selection algorithm > as well. > > > 3.X PERFORMANCE > > - CAR/GAAR protocol MUST NOT add to handover times in > cases when the connection to the old AR is lost and there > are ongoing communication waiting for network access. In > those cases the MN must get a new AR as fast as possible, > not spending much time on the TAR algorithm. > > [DOT] How do decide whether it is worthwhile to spend time > on CAR or not? > If you have a TAR selection scheme that resides in the MN, > it is fairly > easy to do so. If your signal strength fades for instance > too fast, you just > skip CAR discovery and select one of the AR from which you > receive a current > beacon. But again, this is TAR selection and not within the > scope of the problem. > But if you choose to do CAR (wherever it is implemented), > it will always add > to your handover time since you have to run certain > mechanisms. How this tradeoff > can be determined is not clear to me and looks like an > implementation issue in > the entity that runs the TAR selection (which again use CAR > discovery as an input). > > General thoughts: > > How can an AR recognize its GAARs without the help of the MN > or the link-layer protocols? > > This means that the amount of packets sent over the air necessarily > increases, doesn't it? I mean, if the AR doesn't get the > information about > GAARs from the MN, then it must somehow sense the GAARs > presence through > the APs. But the latter is of course impossible between APs > of different > link layers. > > [DOT] Good question ;-) But is it mentioned somewhere that the > identification of GAARs must not be a combined job between > AR and MN? Or it > might even be entirely based in the MN? Certainly, the > AR-only solution > sounds kind of impossible for me, too. > > Best Regards, > > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 09:22:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29346 for ; Wed, 27 Mar 2002 09:22:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11830; Wed, 27 Mar 2002 09:14:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11797 for ; Wed, 27 Mar 2002 09:14:38 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28858 for ; Wed, 27 Mar 2002 09:14:35 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2REEakY000998 for ; Wed, 27 Mar 2002 15:14:36 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 14:46:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:36:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C07418@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Govind Krishnamurthi , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:46:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > [Govind] That CAR discovery is needed for reverse > translation is quite > > > obvious from requirement 1 of the current requirement > draft. I thought > > > that was the main idea behind the requirement. Anyways, > my previous > > > mail was saying this too. => Again this is assuming a certain scenario (AR discovering GAARs) which will only work in very limited cases. I.e. few GAARs in one operator's domain. > [Govind] First, I don't think that it is a "complicated" protocol > as you suggest. As I pointed out it could just be part of > the MN's profile. => What exactly would this profile say? And what impacts does it have on privacy? > Second, pushing capabilities down to the MN for its decision > has power,bandwidth and time considerations which one may > want to consider. => only as much as an RA would have. Are you saying RAs should not be allowed? > Again, I am not saying that what you say is not an option. => Good. But > saying that the MN MUST be the only one deciding the TAR restricts > the field totally which I think is rather pre-mature. => How does it restrict it? Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 09:22:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29357 for ; Wed, 27 Mar 2002 09:22:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14040 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 09:22:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11830; Wed, 27 Mar 2002 09:14:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11797 for ; Wed, 27 Mar 2002 09:14:38 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28858 for ; Wed, 27 Mar 2002 09:14:35 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2REEakY000998 for ; Wed, 27 Mar 2002 15:14:36 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 14:46:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:36:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C07418@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Govind Krishnamurthi , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:46:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > [Govind] That CAR discovery is needed for reverse > translation is quite > > > obvious from requirement 1 of the current requirement > draft. I thought > > > that was the main idea behind the requirement. Anyways, > my previous > > > mail was saying this too. => Again this is assuming a certain scenario (AR discovering GAARs) which will only work in very limited cases. I.e. few GAARs in one operator's domain. > [Govind] First, I don't think that it is a "complicated" protocol > as you suggest. As I pointed out it could just be part of > the MN's profile. => What exactly would this profile say? And what impacts does it have on privacy? > Second, pushing capabilities down to the MN for its decision > has power,bandwidth and time considerations which one may > want to consider. => only as much as an RA would have. Are you saying RAs should not be allowed? > Again, I am not saying that what you say is not an option. => Good. But > saying that the MN MUST be the only one deciding the TAR restricts > the field totally which I think is rather pre-mature. => How does it restrict it? Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 09:57:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01066 for ; Wed, 27 Mar 2002 09:57:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20869; Wed, 27 Mar 2002 09:49:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20831 for ; Wed, 27 Mar 2002 09:49:12 -0500 (EST) Received: from hotmail.com (f210.law9.hotmail.com [64.4.9.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00611 for ; Wed, 27 Mar 2002 09:49:09 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 06:48:41 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 14:48:40 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Wed, 27 Mar 2002 09:48:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 14:48:41.0012 (UTC) FILETIME=[7C4DFF40:01C1D59E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Michael, >At 05:37 PM 3/26/2002 +0000, Hemant Chaskar wrote: >>Hi: >> >>I think the main discussion issue that resulted in this email was: >> >>What is the cost of scanning APs on other connection (this involves link >>establishment, authentication as you said, obtaining IP address, receiving >>capabilities). > >No. The scanning only involves "listening". *IF* you decide that the >candidate >is worth pursuing, then - and only then - do you waste (the more >significant) >transmit power to associate/authenticate/etc... > >So ... if you are on an AP with strong S/N and you hear 4 other >candidate APs that have poor S/N ... you will probably do nothing >terribly power consuming .... perhaps a re-scan with relatively >long inter-scan times. If the S/N is tanking on the link you are >using ... then you may want to look harder (scan more >often) ... and even try to associate with other APs before the >one you are on dies. [Govind] Michael, I believe the assumption that you are making is that the SIR is the only criteria to attach get the capabilities etc. That might not be the only criteria. We want to make sure that the MN attaches to the right AR and not AP. The capabilities of the AR are not transmitted in the L2 beacon. Though I agree with you that scanning does not imply connecting. I was proposing a similar scheme too. But the only difference being the MN does not connect to the AP based on the SIR alone. > >>Note that, all this work (and associated power) will be wasted if the user >>does not like the capabilites at the end of day. > >The heuristics driving the above decisions is simply an optimization >problem that trades off the availability/seamlessness of your connection >with the (optimization-based) "cost" of the extra power consumption. >Different >strokes for different folks .... and thus another reason for the MN to >decide. [Michael] Exactly, and thats why the MN should be able to decide whether it wants to hear the capabilities or NOT and the statement CAR Discovery MUST inform the MN of GAARs and their capabilities seems to push the capabilities to the MN irrespective of whether the MN wants or not. I agree that if a particular solution needs this sure the requirements shouldn't prevent it. But if a particular solution does not want it then the requirements must be flexible to do that too. Saying that lets pump all the information to the MN and then the MN can decide to use it or not is clearly a waste of time bandwidth and power. Regards, Govind. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 09:57:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01076 for ; Wed, 27 Mar 2002 09:57:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22865 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 09:57:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20869; Wed, 27 Mar 2002 09:49:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20831 for ; Wed, 27 Mar 2002 09:49:12 -0500 (EST) Received: from hotmail.com (f210.law9.hotmail.com [64.4.9.210]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00611 for ; Wed, 27 Mar 2002 09:49:09 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 06:48:41 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 14:48:40 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Wed, 27 Mar 2002 09:48:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 14:48:41.0012 (UTC) FILETIME=[7C4DFF40:01C1D59E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Michael, >At 05:37 PM 3/26/2002 +0000, Hemant Chaskar wrote: >>Hi: >> >>I think the main discussion issue that resulted in this email was: >> >>What is the cost of scanning APs on other connection (this involves link >>establishment, authentication as you said, obtaining IP address, receiving >>capabilities). > >No. The scanning only involves "listening". *IF* you decide that the >candidate >is worth pursuing, then - and only then - do you waste (the more >significant) >transmit power to associate/authenticate/etc... > >So ... if you are on an AP with strong S/N and you hear 4 other >candidate APs that have poor S/N ... you will probably do nothing >terribly power consuming .... perhaps a re-scan with relatively >long inter-scan times. If the S/N is tanking on the link you are >using ... then you may want to look harder (scan more >often) ... and even try to associate with other APs before the >one you are on dies. [Govind] Michael, I believe the assumption that you are making is that the SIR is the only criteria to attach get the capabilities etc. That might not be the only criteria. We want to make sure that the MN attaches to the right AR and not AP. The capabilities of the AR are not transmitted in the L2 beacon. Though I agree with you that scanning does not imply connecting. I was proposing a similar scheme too. But the only difference being the MN does not connect to the AP based on the SIR alone. > >>Note that, all this work (and associated power) will be wasted if the user >>does not like the capabilites at the end of day. > >The heuristics driving the above decisions is simply an optimization >problem that trades off the availability/seamlessness of your connection >with the (optimization-based) "cost" of the extra power consumption. >Different >strokes for different folks .... and thus another reason for the MN to >decide. [Michael] Exactly, and thats why the MN should be able to decide whether it wants to hear the capabilities or NOT and the statement CAR Discovery MUST inform the MN of GAARs and their capabilities seems to push the capabilities to the MN irrespective of whether the MN wants or not. I agree that if a particular solution needs this sure the requirements shouldn't prevent it. But if a particular solution does not want it then the requirements must be flexible to do that too. Saying that lets pump all the information to the MN and then the MN can decide to use it or not is clearly a waste of time bandwidth and power. Regards, Govind. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 10:12:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01741 for ; Wed, 27 Mar 2002 10:12:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25254; Wed, 27 Mar 2002 10:06:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25212 for ; Wed, 27 Mar 2002 10:06:36 -0500 (EST) Received: from hotmail.com (f230.law9.hotmail.com [64.4.9.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01525 for ; Wed, 27 Mar 2002 10:06:33 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 07:06:04 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 15:06:04 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 10:06:04 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 15:06:04.0990 (UTC) FILETIME=[EA9065E0:01C1D5A0] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik, Thanks for your comments. My comments inline. > > > > [Govind] This may be possible. > >Ok. [Govind] Thanks to you too. Essentially the key word is may. > > > > [Govind] WHat do you mean currently active Access routers? The MN is > > currently attached just to one AR and we are talking about the GAARs of > > this currently attached AR to which the MN may potentially handoff too. >No, no, no, you cannot assume that only one of the N possible interfaces >the MN may have is in use. At any given time, zero, N or any number in >between of the interfaces may be in use, and may provide different lists >of GAARs. Additionally, the MN's interfaces scanning for APs may result >in GAARs which are not on any of the other lists. [Govind] Again, I am not making any such assumption. You assume that you will be able to get the GAAR ID directly in each of the interfaces.. For one they may be able to access only the L2 beacon of the respective APs. For example in the 802.11b case, if you need to get the IP address of the GAAR you first need to connect to the AP (authenticate, authorize etc) before soliciting for the router adv. Then you have to get the capabilities. If you have several such AP options then you have to do the same with each before being able to decide. Whether this is ok or not is debatable. Saying that the CAR discovery output MUST be pushed to the MN is just one possible way. There are others possible. I am just asking to not reject other solutions possible, at least not now. > > > > > Second, I agree what you propose is neither sensible not optimal. > > But I don't think anyone is suggesting that. To do this we have to > > go into solution space. But transmitting the GAARs and their capabilties > > to the MN has its bandwidth and power constraints too. > > I am not arguing against one another. All I'm saying is we shouldn't > > totally reject AR based CAR discovery now. > >Ok. > >I'm arguing that we should reject CAR discovery which is not MN centric. >The ARs will (must!) have their role in this, but an AR centric scheme >does not seem to make sense, and I believe that it would be good to get >that established. [Govind] All CAR discovery does is identify "POSSIBLE" ARs for handovers. All CAR discovery has to do is feed into the TAR selection algorithm. Where can you tell me in the above definitions of CAR discovery is it decided that the MN goes some place without its concern? Next what do you mean by MN-centric? Does it mean that the MN's requirements (what ever they may be) are completely adhered to? If so I completely agree. That is what is CAR discovery for. Whether you do it in the network or the MN, by definition CARs are discovered based on a capability - MN requirement match. If you mean that it MUST be done at the MN then it is not true, IMHO If what you are alluding to is MN-centric TAR selection? I agree too. But this this is clearly out of scope. All CAR discovery does is feed into TAR selection. There might be a 100 inputs to take in apart from the CAR discovery output. Why does it have to do with CAR discovery? Cant the requirement be CAR discovery output MUST be made available to TAR selection? This takes care of the TAR selection being available in the MN or network. It depends on the solution and should be discussed at that appropriate time is it not? Thanks for reading my mail patiently. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 10:12:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01755 for ; Wed, 27 Mar 2002 10:12:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26578 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 10:12:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25254; Wed, 27 Mar 2002 10:06:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25212 for ; Wed, 27 Mar 2002 10:06:36 -0500 (EST) Received: from hotmail.com (f230.law9.hotmail.com [64.4.9.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01525 for ; Wed, 27 Mar 2002 10:06:33 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 07:06:04 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 15:06:04 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 10:06:04 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 15:06:04.0990 (UTC) FILETIME=[EA9065E0:01C1D5A0] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik, Thanks for your comments. My comments inline. > > > > [Govind] This may be possible. > >Ok. [Govind] Thanks to you too. Essentially the key word is may. > > > > [Govind] WHat do you mean currently active Access routers? The MN is > > currently attached just to one AR and we are talking about the GAARs of > > this currently attached AR to which the MN may potentially handoff too. >No, no, no, you cannot assume that only one of the N possible interfaces >the MN may have is in use. At any given time, zero, N or any number in >between of the interfaces may be in use, and may provide different lists >of GAARs. Additionally, the MN's interfaces scanning for APs may result >in GAARs which are not on any of the other lists. [Govind] Again, I am not making any such assumption. You assume that you will be able to get the GAAR ID directly in each of the interfaces.. For one they may be able to access only the L2 beacon of the respective APs. For example in the 802.11b case, if you need to get the IP address of the GAAR you first need to connect to the AP (authenticate, authorize etc) before soliciting for the router adv. Then you have to get the capabilities. If you have several such AP options then you have to do the same with each before being able to decide. Whether this is ok or not is debatable. Saying that the CAR discovery output MUST be pushed to the MN is just one possible way. There are others possible. I am just asking to not reject other solutions possible, at least not now. > > > > > Second, I agree what you propose is neither sensible not optimal. > > But I don't think anyone is suggesting that. To do this we have to > > go into solution space. But transmitting the GAARs and their capabilties > > to the MN has its bandwidth and power constraints too. > > I am not arguing against one another. All I'm saying is we shouldn't > > totally reject AR based CAR discovery now. > >Ok. > >I'm arguing that we should reject CAR discovery which is not MN centric. >The ARs will (must!) have their role in this, but an AR centric scheme >does not seem to make sense, and I believe that it would be good to get >that established. [Govind] All CAR discovery does is identify "POSSIBLE" ARs for handovers. All CAR discovery has to do is feed into the TAR selection algorithm. Where can you tell me in the above definitions of CAR discovery is it decided that the MN goes some place without its concern? Next what do you mean by MN-centric? Does it mean that the MN's requirements (what ever they may be) are completely adhered to? If so I completely agree. That is what is CAR discovery for. Whether you do it in the network or the MN, by definition CARs are discovered based on a capability - MN requirement match. If you mean that it MUST be done at the MN then it is not true, IMHO If what you are alluding to is MN-centric TAR selection? I agree too. But this this is clearly out of scope. All CAR discovery does is feed into TAR selection. There might be a 100 inputs to take in apart from the CAR discovery output. Why does it have to do with CAR discovery? Cant the requirement be CAR discovery output MUST be made available to TAR selection? This takes care of the TAR selection being available in the MN or network. It depends on the solution and should be discussed at that appropriate time is it not? Thanks for reading my mail patiently. Regards, Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 10:32:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02534 for ; Wed, 27 Mar 2002 10:32:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01754 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 10:32:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00415; Wed, 27 Mar 2002 10:27:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00375 for ; Wed, 27 Mar 2002 10:27:03 -0500 (EST) Received: from hotmail.com (f73.law9.hotmail.com [64.4.9.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02355 for ; Wed, 27 Mar 2002 10:27:00 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 07:26:21 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 15:26:20 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 10:26:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 15:26:21.0223 (UTC) FILETIME=[BF7ED370:01C1D5A3] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > > [Govind] That CAR discovery is needed for reverse > > translation is quite > > > > obvious from requirement 1 of the current requirement > > draft. I thought > > > > that was the main idea behind the requirement. Anyways, > > my previous > > > > mail was saying this too. > >=> Again this is assuming a certain scenario (AR discovering >GAARs) which will only work in very limited cases. I.e. >few GAARs in one operator's domain. [Govind] Hesham, either you are not getting all my mails or you are selectively answering them. I responded this to James, who specially was talking about an L2 - L3 mapping when the MN passes it on to the network is not expressed in the requirements. I was pointing out that it was taken care of already. If you read the rest of this thread you will see that he agrees too. I don't think it is impossible to use a network based scheme to do inter-domain CAR discovery. But again this goes into solution space and I don't want to go into it now. Having said that if you have a chance please read the other mails to you which has explicitly talked about your concerns about this not reflecting the case you illustrated to me. I look forward to hearing from on that. > > > [Govind] First, I don't think that it is a "complicated" protocol > > as you suggest. As I pointed out it could just be part of > > the MN's profile. > >=> What exactly would this profile say? And what impacts >does it have on privacy? > [Govind] The MN makes available to the network whatever it needs to for handover decision thats all (this is the part required by CAR discovery. This profile might make available other things, ofcourse.) Privacy is an important issue and has to be tackled of course. But that doesn't mean we can't do it. Second, profile was just an example to illustrate to James. There might be other ways of doing it. Therefore right, we will look at this when the complete protocol is presented each one of us. We should address this issue then and not now. Otherwise this discussiong goes too much into solution space. Precluding me from doing so right now implies that there is no way of doing CAR discovery in the network which is I think a little premature now. > > Second, pushing capabilities down to the MN for its decision > > has power,bandwidth and time considerations which one may > > want to consider. > >=> only as much as an RA would have. Are you saying >RAs should not be allowed? [Govind] Ofcourse not, if you intend to do CAR discovery that way by all means you should be allowed to... (which again gets me to the mail to you which talks about this matter.. please take a look at it and let me know your comments). But there are performance tradeoffs when you do this, because you the RA does not contain the capabilities that might be required by the MN. The capabilities have to be sent over to the MN. This has to be done for each AP the MN wants to check. This does conserve power, bandwidth and in a low bandwidth environment, it does take time too depending on how many capabilities are to be sent. Again, I am not preventing you to do it. If the requirement does not allow you to do this I agree we should re-word it. But it should allow me to do my way of implementing things too if I choose to. All I am asking is that, then we decide based on the protocol. There are performance tradeoffs to each scheme. > > > Again, I am not saying that what you say is not an option. > >=> Good. [Govind] Thanks. > >But > > saying that the MN MUST be the only one deciding the TAR restricts > > the field totally which I think is rather pre-mature. > >=> How does it restrict it? [Govind] The requirement as James proposed it says that CAR discovery implies that the GAARs and the capabilities MUST be sent to the MN. I don't think this is true and necessary. All CAR discovery must do (where ever it resides) MUST make available its output to TAR selection (whereever that resides). That way we are satisfying everyone. Hope you understand my concern. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 10:52:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03486 for ; Wed, 27 Mar 2002 10:52:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05741; Wed, 27 Mar 2002 10:48:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05699 for ; Wed, 27 Mar 2002 10:48:46 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03335 for ; Wed, 27 Mar 2002 10:48:42 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFp4113036 for ; Wed, 27 Mar 2002 09:51:04 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 09:48:35 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 09:48:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:48:23 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVLDOT1gkMgUHmTfitUl25Q6PmPgAd3zFA To: , X-OriginalArrivalTime: 27 Mar 2002 15:48:24.0548 (UTC) FILETIME=[D4423240:01C1D5A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA05700 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi all, just to have another opinion on record. Firstly, I disagree with keeping the requirement in the current wording. Hemant already pointed out the major flaw of this requirement, namely the pushing of unnecessary information to the MN. James comment about "keeping it simple" neglects a simple fact. It is not about making it more complicated (how, just by adding "if required"???), it is about avoiding unnecessary flooding and therefore wasting power of the MN for receiving information it does not need or, even worse, does not want. Secondly, I even stronger disagree with REPLACING requirement 3.4 with this requirement, even in a re-worded manner. Requirement 3.4 deals with a different problem, namely the expression of MN requirements. Even though some people apparently think that this involves complicated AAA transactions (let's simply see what the solutions will bring), it just actually says that you need ANY means to express what the MN's requirements are. This is even important in an MN-based case, which could be realized in a simple user interface or something else. The proposed requirement though deals with information provision. Even if you get the information at the MN, you still need means to express your requirements so that you can do the match from GAARs to CARs. Regards, Dirk -----Original Message----- From: ext Henrik Levkowetz [mailto:henrik@levkowetz.com] Sent: Tuesday, March 26, 2002 8:10 PM To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Hemant, You apparently did not read my recent posting. Cut'n'Paste: No, the requirement is just fine. It does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I think that's the essence of it. Do you oppose this? Why? Do you want to make things more complicated than they have to be? Henrik Hemant wrote: > > Hi James: > > There are serious shortcomings of the solution satisfying this requirement. > They are described below. How can we finalise this requirement unless it is > agreed that these pitfalls do not exist? > > For this, it might be good idea to visualise how the solution satisfying > this requirement looks like and violates basic tenets of engineering design, > namely efficiency. The solution satisfying this requirement is obliged to > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > big chunk of data (= number of GAARs times capability set of each). This > flood will occur either on active traffic connection which I call case (i) > (relevant for single interface MN and two-interface MN where second > interface is sleeping) or on second interface which I call case (ii) > (relevant for two interface MN with both interfaces awake). There are > following effects of this flood: > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > active traffic channel. > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > power wastage. This is because, after receiving these capabilities MN either > rejects the new AR (which is worst), and even if it selcects one why does it > need to receive capabilities of GAARs that do not matter for it. > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > sees. Which means the same information (which could be big enough) is > transmitted on downlink so many times. This takes up considerable fraction > of downlink capacity. > > 4. Limit on capability definition: This requirement restricts the definition > of capabilities to a very small size, otherwise all ARs will only be > transmitting GAAR capabilities to different MNs all the time. This means > capability set cannot be comprehensive and extensible. > > So, IMHO rather than counting who agrees to one statement requirement that > you proposed and who have not, we should first analyse above harmful effects > before deciding either way. > > Br, > Hemant > > > >From: "James Kempf" > >To: "Govind Krishnamurthi" , > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > >Examples of CAR discovery) > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > This seems contradictory to your earlier mails saying that there is > > > no basis for network based CAR discovery. So are you now agreeing > > > that network based CAR discovery has its place? > > > > > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 10:58:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03922 for ; Wed, 27 Mar 2002 10:58:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07205; Wed, 27 Mar 2002 10:55:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07171 for ; Wed, 27 Mar 2002 10:55:09 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03637 for ; Wed, 27 Mar 2002 10:54:57 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFvO113604 for ; Wed, 27 Mar 2002 09:57:24 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 09:54:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 09:54:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:54:16 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVH/mHqG+vvWt2Q/KckuVlLobcOQAhz5dw To: , , X-OriginalArrivalTime: 27 Mar 2002 15:54:18.0339 (UTC) FILETIME=[A7226B30:01C1D5A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07172 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Anybody else out there have an opinion on this? Should we include this requirement instead of requirement 3.4, which has the AR in control? [DOT] Can you explain to me where requirement 3.4 states that AR is in control? You should realize that the expression of requirements to do the job of CAR discovery is simply necessary to do the matching. Even if the MN is doing the matching, you still needs means to express requirements. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 10:58:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03933 for ; Wed, 27 Mar 2002 10:58:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08242 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 10:58:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07205; Wed, 27 Mar 2002 10:55:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07171 for ; Wed, 27 Mar 2002 10:55:09 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03637 for ; Wed, 27 Mar 2002 10:54:57 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFvO113604 for ; Wed, 27 Mar 2002 09:57:24 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 09:54:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 09:54:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:54:16 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVH/mHqG+vvWt2Q/KckuVlLobcOQAhz5dw To: , , X-OriginalArrivalTime: 27 Mar 2002 15:54:18.0339 (UTC) FILETIME=[A7226B30:01C1D5A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07172 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Anybody else out there have an opinion on this? Should we include this requirement instead of requirement 3.4, which has the AR in control? [DOT] Can you explain to me where requirement 3.4 states that AR is in control? You should realize that the expression of requirements to do the job of CAR discovery is simply necessary to do the matching. Even if the MN is doing the matching, you still needs means to express requirements. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 10:59:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03974 for ; Wed, 27 Mar 2002 10:59:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07546; Wed, 27 Mar 2002 10:56:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07513 for ; Wed, 27 Mar 2002 10:56:26 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03783 for ; Wed, 27 Mar 2002 10:56:23 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFwn113810 for ; Wed, 27 Mar 2002 09:58:49 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 09:56:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 09:55:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:55:54 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVLDOT1gkMgUHmTfitUl25Q6PmPgAe4FRg To: , X-OriginalArrivalTime: 27 Mar 2002 15:55:55.0903 (UTC) FILETIME=[E14980F0:01C1D5A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07514 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Henrik, I think that's the essence of it. Do you oppose this? Why? Do you want to make things more complicated than they have to be? [DOT] Avoiding flooding of MN with unnecessary information might complicate the design but might also be a worthwhile goal of a protocol design? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 10:59:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03982 for ; Wed, 27 Mar 2002 10:59:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08421 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 10:59:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07546; Wed, 27 Mar 2002 10:56:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07513 for ; Wed, 27 Mar 2002 10:56:26 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03783 for ; Wed, 27 Mar 2002 10:56:23 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFwn113810 for ; Wed, 27 Mar 2002 09:58:49 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 09:56:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 09:55:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:55:54 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVLDOT1gkMgUHmTfitUl25Q6PmPgAe4FRg To: , X-OriginalArrivalTime: 27 Mar 2002 15:55:55.0903 (UTC) FILETIME=[E14980F0:01C1D5A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07514 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Henrik, I think that's the essence of it. Do you oppose this? Why? Do you want to make things more complicated than they have to be? [DOT] Avoiding flooding of MN with unnecessary information might complicate the design but might also be a worthwhile goal of a protocol design? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:14:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04485 for ; Wed, 27 Mar 2002 11:14:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09480; Wed, 27 Mar 2002 11:03:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09450 for ; Wed, 27 Mar 2002 11:03:29 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04092 for ; Wed, 27 Mar 2002 11:03:25 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RG5q114194 for ; Wed, 27 Mar 2002 10:05:52 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:03:26 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:03:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 11:03:23 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVGFY/PqQkXLpAQTCODm6CHsnFTQAj7WAQ To: , , X-OriginalArrivalTime: 27 Mar 2002 16:03:24.0299 (UTC) FILETIME=[EC8D4DB0:01C1D5A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA09451 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Right, so the AR hands over the list of GAAR and the MN figures out where it wants to go. What could be simpler? [DOT] A simple solution is desirable but not if it floods my MN. A requirement is not necessarily only about simplicity, it should take certain constraints into account. Distributing information that is not necessary is a major constraint for me, in particular in wireless environments. This is even more important since we haven't fully understood yet what capabilities actually might be. What is the amount of data we're talking about here? It heavily depends on the format we'll choose. Closing the door for solutions that allow the MN to say what information it actually wants looks very premature to me in this stage. If we later decide that the final solution will send the entire information, we can still do this (it simply means that the MN requests ALL information, i.e., the list of ALL GAARs plus full capabilities), if it doesn't matter in terms of bandwidth and power constraints. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:14:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04494 for ; Wed, 27 Mar 2002 11:14:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12750 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:14:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09480; Wed, 27 Mar 2002 11:03:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09450 for ; Wed, 27 Mar 2002 11:03:29 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04092 for ; Wed, 27 Mar 2002 11:03:25 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RG5q114194 for ; Wed, 27 Mar 2002 10:05:52 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:03:26 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:03:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 11:03:23 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVGFY/PqQkXLpAQTCODm6CHsnFTQAj7WAQ To: , , X-OriginalArrivalTime: 27 Mar 2002 16:03:24.0299 (UTC) FILETIME=[EC8D4DB0:01C1D5A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA09451 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Right, so the AR hands over the list of GAAR and the MN figures out where it wants to go. What could be simpler? [DOT] A simple solution is desirable but not if it floods my MN. A requirement is not necessarily only about simplicity, it should take certain constraints into account. Distributing information that is not necessary is a major constraint for me, in particular in wireless environments. This is even more important since we haven't fully understood yet what capabilities actually might be. What is the amount of data we're talking about here? It heavily depends on the format we'll choose. Closing the door for solutions that allow the MN to say what information it actually wants looks very premature to me in this stage. If we later decide that the final solution will send the entire information, we can still do this (it simply means that the MN requests ALL information, i.e., the list of ALL GAARs plus full capabilities), if it doesn't matter in terms of bandwidth and power constraints. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:14:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04513 for ; Wed, 27 Mar 2002 11:14:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10377; Wed, 27 Mar 2002 11:06:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10329 for ; Wed, 27 Mar 2002 11:06:45 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04180 for ; Wed, 27 Mar 2002 11:06:41 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RG93114617 for ; Wed, 27 Mar 2002 10:09:03 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:06:37 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:05:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 11:05:28 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVFF43Akqc2sE8QNm5GNh8iPdYgQAlJwxQ To: , , X-OriginalArrivalTime: 27 Mar 2002 16:05:35.0946 (UTC) FILETIME=[3B050AA0:01C1D5A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA10332 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, On second thought, let's keep it simple. Premature optimization often has unintended consequences. [DOT] Premature non-optimization can be even worse, in particular in this sense in which the actual data (and the amount) we're talking about is not yet understood. So demanding the transmission of ALL data might have very ugly consequences. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:14:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04540 for ; Wed, 27 Mar 2002 11:14:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11936; Wed, 27 Mar 2002 11:11:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11903 for ; Wed, 27 Mar 2002 11:11:49 -0500 (EST) Received: from hotmail.com (f143.law7.hotmail.com [216.33.237.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04371 for ; Wed, 27 Mar 2002 11:11:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:11:12 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:11:12 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 16:11:12 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:11:12.0687 (UTC) FILETIME=[03BBA3F0:01C1D5AA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik: I agree that you cannot focus on one case only, but then you cannot ignore any too. The current requirement of blasting MN blindly with volume of capability data does ingore implication on certain cases. Further this requirement is a MUST one and does not say whether it is applicable to only some cases or all cases. Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 02:28:25 +0100 > >Hemant wrote: > > > > Hi Henrik: > > > > > > -------------------------------------snip------------------------------ > > > > > > > > An example where such comparison may occur in network is when there >is > > >only > > > > one interface on MN and it can listen only to radio beacons of > > >surrounding > > > > access points. This is similar to break-before-make handoff case. >Here, > > >MN > > > > cannot receive capabilities of GAARs without letting go the previous > > > > connection. Do you think that such cases are not relevant and we >should > > > > exclude such cases right at the problem statement/requirements >stage? > > > > > >I think that designing for the one access technology case will cripple > > >the solution. > > > > [HC] I do not understand your comment. Are you essentially saying that >"This > > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > > discovery is optimal for this case too". > >No, i'm not saying this case is irrelevant, or that AR unassisted CAR >discovery >is optimal ... for any case. I'm saying: > >I think that designing for the one access technology case will cripple >the solution. > > > > > IMHO neither requirements nor problem statement should ignore any use >cases. > > If they do, it should be explicitly stated so in the spec, so that >designers > > are not misguided to apply solutions to cases for which they are not > > designed. > >Nobody's ignoring any use cases. But if you focus on one sample to the >detriment of the rest, it will cripple your solution. > > Regards, > Henrik > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:14:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04538 for ; Wed, 27 Mar 2002 11:14:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11005; Wed, 27 Mar 2002 11:08:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10917 for ; Wed, 27 Mar 2002 11:08:32 -0500 (EST) Received: from hotmail.com (f44.law7.hotmail.com [216.33.237.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04242 for ; Wed, 27 Mar 2002 11:08:28 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:07:56 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:07:56 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:07:56 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:07:56.0773 (UTC) FILETIME=[8EF58950:01C1D5A9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hernik: I did read your comment and responded as follows in my earlier email. Cut'n'Paste: ------------------------------- If we honestly think that the requirement does not oblige AR to blast all GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do we need to hide this fact? We can come up with something else, if you do not like on-demand extension. I think without such extension the solution satisfying this requirement may have serious shortcomings that I described in my other email to James. -------------------------------- BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 02:09:44 +0100 > >Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR >information, it does not require *on-demand operation*, it expresses >exactly >what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > I think that's the essence of it. Do you oppose this? Why? Do you >want to make things more complicated than they have to be? > > Henrik > >Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this >requirement. > > They are described below. How can we finalise this requirement unless it >is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering >design, > > namely efficiency. The solution satisfying this requirement is obliged >to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might >be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case >(i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic >over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood >causes > > power wastage. This is because, after receiving these capabilities MN >either > > rejects the new AR (which is worst), and even if it selcects one why >does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable >fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the >definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement >that > > you proposed and who have not, we should first analyse above harmful >effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we >are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR >discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant >of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham >has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:14:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04566 for ; Wed, 27 Mar 2002 11:14:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12903 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:14:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11005; Wed, 27 Mar 2002 11:08:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10917 for ; Wed, 27 Mar 2002 11:08:32 -0500 (EST) Received: from hotmail.com (f44.law7.hotmail.com [216.33.237.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04242 for ; Wed, 27 Mar 2002 11:08:28 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:07:56 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:07:56 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:07:56 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:07:56.0773 (UTC) FILETIME=[8EF58950:01C1D5A9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hernik: I did read your comment and responded as follows in my earlier email. Cut'n'Paste: ------------------------------- If we honestly think that the requirement does not oblige AR to blast all GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do we need to hide this fact? We can come up with something else, if you do not like on-demand extension. I think without such extension the solution satisfying this requirement may have serious shortcomings that I described in my other email to James. -------------------------------- BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 02:09:44 +0100 > >Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR >information, it does not require *on-demand operation*, it expresses >exactly >what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > I think that's the essence of it. Do you oppose this? Why? Do you >want to make things more complicated than they have to be? > > Henrik > >Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this >requirement. > > They are described below. How can we finalise this requirement unless it >is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering >design, > > namely efficiency. The solution satisfying this requirement is obliged >to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might >be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case >(i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic >over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood >causes > > power wastage. This is because, after receiving these capabilities MN >either > > rejects the new AR (which is worst), and even if it selcects one why >does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable >fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the >definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement >that > > you proposed and who have not, we should first analyse above harmful >effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we >are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR >discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant >of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham >has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:14:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04550 for ; Wed, 27 Mar 2002 11:14:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12880 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:14:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11936; Wed, 27 Mar 2002 11:11:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11903 for ; Wed, 27 Mar 2002 11:11:49 -0500 (EST) Received: from hotmail.com (f143.law7.hotmail.com [216.33.237.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04371 for ; Wed, 27 Mar 2002 11:11:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:11:12 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:11:12 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 16:11:12 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:11:12.0687 (UTC) FILETIME=[03BBA3F0:01C1D5AA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik: I agree that you cannot focus on one case only, but then you cannot ignore any too. The current requirement of blasting MN blindly with volume of capability data does ingore implication on certain cases. Further this requirement is a MUST one and does not say whether it is applicable to only some cases or all cases. Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 02:28:25 +0100 > >Hemant wrote: > > > > Hi Henrik: > > > > > > -------------------------------------snip------------------------------ > > > > > > > > An example where such comparison may occur in network is when there >is > > >only > > > > one interface on MN and it can listen only to radio beacons of > > >surrounding > > > > access points. This is similar to break-before-make handoff case. >Here, > > >MN > > > > cannot receive capabilities of GAARs without letting go the previous > > > > connection. Do you think that such cases are not relevant and we >should > > > > exclude such cases right at the problem statement/requirements >stage? > > > > > >I think that designing for the one access technology case will cripple > > >the solution. > > > > [HC] I do not understand your comment. Are you essentially saying that >"This > > case is irrelevant for CAR discovery" or "Completely AR unassisted CAR > > discovery is optimal for this case too". > >No, i'm not saying this case is irrelevant, or that AR unassisted CAR >discovery >is optimal ... for any case. I'm saying: > >I think that designing for the one access technology case will cripple >the solution. > > > > > IMHO neither requirements nor problem statement should ignore any use >cases. > > If they do, it should be explicitly stated so in the spec, so that >designers > > are not misguided to apply solutions to cases for which they are not > > designed. > >Nobody's ignoring any use cases. But if you focus on one sample to the >detriment of the rest, it will cripple your solution. > > Regards, > Henrik > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:20:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04917 for ; Wed, 27 Mar 2002 11:20:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13452; Wed, 27 Mar 2002 11:16:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13418 for ; Wed, 27 Mar 2002 11:16:35 -0500 (EST) Received: from hotmail.com (f206.law7.hotmail.com [216.33.237.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04717 for ; Wed, 27 Mar 2002 11:16:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:16:03 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:16:03 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: mramalho@cisco.com, seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Wed, 27 Mar 2002 16:16:03 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:16:03.0664 (UTC) FILETIME=[B12B3500:01C1D5AA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: We are not at all talking about scanning for strongest SNR. The assumption is that interface will not take further steps unless strong SNR is seen. There is not doubt about that. After that however, the question is does it need to blindly go into steps of acquiring IP connectivity and getting capabilities to see if access router can offer the desired service. Hemant >From: "Michael A. Ramalho" >To: "Hemant Chaskar" , seamoby@ietf.org >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Tue, 26 Mar 2002 21:01:31 -0500 > >At 05:37 PM 3/26/2002 +0000, Hemant Chaskar wrote: >>Hi: >> >>I think the main discussion issue that resulted in this email was: >> >>What is the cost of scanning APs on other connection (this involves link >>establishment, authentication as you said, obtaining IP address, receiving >>capabilities). > >No. The scanning only involves "listening". *IF* you decide that the >candidate >is worth pursuing, then - and only then - do you waste (the more >significant) >transmit power to associate/authenticate/etc... > >So ... if you are on an AP with strong S/N and you hear 4 other >candidate APs that have poor S/N ... you will probably do nothing >terribly power consuming .... perhaps a re-scan with relatively >long inter-scan times. If the S/N is tanking on the link you are >using ... then you may want to look harder (scan more >often) ... and even try to associate with other APs before the >one you are on dies. > >I see very little extra power being consumed if you connection >has relatively high S/N. Also remember that the receiver takes much >less power than the transmitter (details vary ... but less than 1/3 of >the total power I think is typical ... someone from a WLAN >manufacturer, like Flarion, might want to provide a more >precise estimate). > >>Note that, all this work (and associated power) will be wasted if the user >>does not like the capabilites at the end of day. > >The heuristics driving the above decisions is simply an optimization >problem that trades off the availability/seamlessness of your connection >with the (optimization-based) "cost" of the extra power consumption. >Different >strokes for different folks .... and thus another reason for the MN to >decide. > >>Please let us know if you think this to be a relevant consideration at >>all. >> >>Please ignore my comment about 3 or more APs. > >ACK > >Hope this helps, > >Michael Ramalho > > >>Hemant >> >> >> >> >>>From: "Michael A. Ramalho" >>>To: "James Kempf" , "Hemant Chaskar" >>>, >>>Subject: Re: [Seamoby] Comments on the requirements draft >>>Date: Tue, 26 Mar 2002 11:14:13 -0500 >>> >>>At 01:59 PM 3/25/2002 -0800, James Kempf wrote: >>> >>>> > Just to be ultra clear - Luxury of two interfaces is not a generic >>>> > assumption for CAR discovery problem formulation. Two-connection WLAN >>>>card >>>> > is good for 2 APs, but what if there are 3 or 4 or 5 APs. >>>> > >>> >>>This may sound like a stupid statement for some .... but even a single >>>WLAN card can scan during periods of (relative) inactivity to search for >>>beacons of other APs. >>> >>>Given this ability/possibility (depends on how the drivers were written), >>>one would assume that two cards are more than enough to search >>>for the (next) highest signal quality AP it can authenticate (or get >>>required QoS) on. Thus while maintaining an existing session >>>on one card - you try to authenticate on the next best AP (in some >>>sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE >>>WLAN card may be possible in the future with "fast-retunable" WLAN >>>cards - but it is clearly doable today with two cards. You only need >>>to define heuristics for your MNs (e.g., default routes, etc.) to send >>>the packets to/from the preferred association. >>> >>>So ... why exactly doesn't the two WLAN card case handle an >>>arbitrary number of potential APs? >>> >>> >>>>Does the MN have different interface cards for each or are they the >>>>same? >>>> >>>> jak >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Seamoby mailing list >>>>Seamoby@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/seamoby >>> >>> >>>Michael A. Ramalho, Ph.D. >>>Office email: mramalho@cisco.com >>>Personal email: mar42@cornell.edu >>>Office: +1.732.449.5762 >>>Cell: +1.732.809.0188 >>> >>> >>>_______________________________________________ >>>Seamoby mailing list >>>Seamoby@ietf.org >>>https://www1.ietf.org/mailman/listinfo/seamoby >> >> >>_________________________________________________________________ >>Join the world's largest e-mail service with MSN Hotmail. >>http://www.hotmail.com >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:20:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04927 for ; Wed, 27 Mar 2002 11:20:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14701 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:20:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13452; Wed, 27 Mar 2002 11:16:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13418 for ; Wed, 27 Mar 2002 11:16:35 -0500 (EST) Received: from hotmail.com (f206.law7.hotmail.com [216.33.237.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04717 for ; Wed, 27 Mar 2002 11:16:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:16:03 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:16:03 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: mramalho@cisco.com, seamoby@ietf.org Subject: Re: [Seamoby] Comments on the requirements draft Date: Wed, 27 Mar 2002 16:16:03 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:16:03.0664 (UTC) FILETIME=[B12B3500:01C1D5AA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: We are not at all talking about scanning for strongest SNR. The assumption is that interface will not take further steps unless strong SNR is seen. There is not doubt about that. After that however, the question is does it need to blindly go into steps of acquiring IP connectivity and getting capabilities to see if access router can offer the desired service. Hemant >From: "Michael A. Ramalho" >To: "Hemant Chaskar" , seamoby@ietf.org >Subject: Re: [Seamoby] Comments on the requirements draft >Date: Tue, 26 Mar 2002 21:01:31 -0500 > >At 05:37 PM 3/26/2002 +0000, Hemant Chaskar wrote: >>Hi: >> >>I think the main discussion issue that resulted in this email was: >> >>What is the cost of scanning APs on other connection (this involves link >>establishment, authentication as you said, obtaining IP address, receiving >>capabilities). > >No. The scanning only involves "listening". *IF* you decide that the >candidate >is worth pursuing, then - and only then - do you waste (the more >significant) >transmit power to associate/authenticate/etc... > >So ... if you are on an AP with strong S/N and you hear 4 other >candidate APs that have poor S/N ... you will probably do nothing >terribly power consuming .... perhaps a re-scan with relatively >long inter-scan times. If the S/N is tanking on the link you are >using ... then you may want to look harder (scan more >often) ... and even try to associate with other APs before the >one you are on dies. > >I see very little extra power being consumed if you connection >has relatively high S/N. Also remember that the receiver takes much >less power than the transmitter (details vary ... but less than 1/3 of >the total power I think is typical ... someone from a WLAN >manufacturer, like Flarion, might want to provide a more >precise estimate). > >>Note that, all this work (and associated power) will be wasted if the user >>does not like the capabilites at the end of day. > >The heuristics driving the above decisions is simply an optimization >problem that trades off the availability/seamlessness of your connection >with the (optimization-based) "cost" of the extra power consumption. >Different >strokes for different folks .... and thus another reason for the MN to >decide. > >>Please let us know if you think this to be a relevant consideration at >>all. >> >>Please ignore my comment about 3 or more APs. > >ACK > >Hope this helps, > >Michael Ramalho > > >>Hemant >> >> >> >> >>>From: "Michael A. Ramalho" >>>To: "James Kempf" , "Hemant Chaskar" >>>, >>>Subject: Re: [Seamoby] Comments on the requirements draft >>>Date: Tue, 26 Mar 2002 11:14:13 -0500 >>> >>>At 01:59 PM 3/25/2002 -0800, James Kempf wrote: >>> >>>> > Just to be ultra clear - Luxury of two interfaces is not a generic >>>> > assumption for CAR discovery problem formulation. Two-connection WLAN >>>>card >>>> > is good for 2 APs, but what if there are 3 or 4 or 5 APs. >>>> > >>> >>>This may sound like a stupid statement for some .... but even a single >>>WLAN card can scan during periods of (relative) inactivity to search for >>>beacons of other APs. >>> >>>Given this ability/possibility (depends on how the drivers were written), >>>one would assume that two cards are more than enough to search >>>for the (next) highest signal quality AP it can authenticate (or get >>>required QoS) on. Thus while maintaining an existing session >>>on one card - you try to authenticate on the next best AP (in some >>>sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE >>>WLAN card may be possible in the future with "fast-retunable" WLAN >>>cards - but it is clearly doable today with two cards. You only need >>>to define heuristics for your MNs (e.g., default routes, etc.) to send >>>the packets to/from the preferred association. >>> >>>So ... why exactly doesn't the two WLAN card case handle an >>>arbitrary number of potential APs? >>> >>> >>>>Does the MN have different interface cards for each or are they the >>>>same? >>>> >>>> jak >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Seamoby mailing list >>>>Seamoby@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/seamoby >>> >>> >>>Michael A. Ramalho, Ph.D. >>>Office email: mramalho@cisco.com >>>Personal email: mar42@cornell.edu >>>Office: +1.732.449.5762 >>>Cell: +1.732.809.0188 >>> >>> >>>_______________________________________________ >>>Seamoby mailing list >>>Seamoby@ietf.org >>>https://www1.ietf.org/mailman/listinfo/seamoby >> >> >>_________________________________________________________________ >>Join the world's largest e-mail service with MSN Hotmail. >>http://www.hotmail.com >> >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:28:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02527 for ; Wed, 27 Mar 2002 10:32:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00415; Wed, 27 Mar 2002 10:27:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00375 for ; Wed, 27 Mar 2002 10:27:03 -0500 (EST) Received: from hotmail.com (f73.law9.hotmail.com [64.4.9.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02355 for ; Wed, 27 Mar 2002 10:27:00 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 07:26:21 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 15:26:20 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 10:26:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 15:26:21.0223 (UTC) FILETIME=[BF7ED370:01C1D5A3] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > > [Govind] That CAR discovery is needed for reverse > > translation is quite > > > > obvious from requirement 1 of the current requirement > > draft. I thought > > > > that was the main idea behind the requirement. Anyways, > > my previous > > > > mail was saying this too. > >=> Again this is assuming a certain scenario (AR discovering >GAARs) which will only work in very limited cases. I.e. >few GAARs in one operator's domain. [Govind] Hesham, either you are not getting all my mails or you are selectively answering them. I responded this to James, who specially was talking about an L2 - L3 mapping when the MN passes it on to the network is not expressed in the requirements. I was pointing out that it was taken care of already. If you read the rest of this thread you will see that he agrees too. I don't think it is impossible to use a network based scheme to do inter-domain CAR discovery. But again this goes into solution space and I don't want to go into it now. Having said that if you have a chance please read the other mails to you which has explicitly talked about your concerns about this not reflecting the case you illustrated to me. I look forward to hearing from on that. > > > [Govind] First, I don't think that it is a "complicated" protocol > > as you suggest. As I pointed out it could just be part of > > the MN's profile. > >=> What exactly would this profile say? And what impacts >does it have on privacy? > [Govind] The MN makes available to the network whatever it needs to for handover decision thats all (this is the part required by CAR discovery. This profile might make available other things, ofcourse.) Privacy is an important issue and has to be tackled of course. But that doesn't mean we can't do it. Second, profile was just an example to illustrate to James. There might be other ways of doing it. Therefore right, we will look at this when the complete protocol is presented each one of us. We should address this issue then and not now. Otherwise this discussiong goes too much into solution space. Precluding me from doing so right now implies that there is no way of doing CAR discovery in the network which is I think a little premature now. > > Second, pushing capabilities down to the MN for its decision > > has power,bandwidth and time considerations which one may > > want to consider. > >=> only as much as an RA would have. Are you saying >RAs should not be allowed? [Govind] Ofcourse not, if you intend to do CAR discovery that way by all means you should be allowed to... (which again gets me to the mail to you which talks about this matter.. please take a look at it and let me know your comments). But there are performance tradeoffs when you do this, because you the RA does not contain the capabilities that might be required by the MN. The capabilities have to be sent over to the MN. This has to be done for each AP the MN wants to check. This does conserve power, bandwidth and in a low bandwidth environment, it does take time too depending on how many capabilities are to be sent. Again, I am not preventing you to do it. If the requirement does not allow you to do this I agree we should re-word it. But it should allow me to do my way of implementing things too if I choose to. All I am asking is that, then we decide based on the protocol. There are performance tradeoffs to each scheme. > > > Again, I am not saying that what you say is not an option. > >=> Good. [Govind] Thanks. > >But > > saying that the MN MUST be the only one deciding the TAR restricts > > the field totally which I think is rather pre-mature. > >=> How does it restrict it? [Govind] The requirement as James proposed it says that CAR discovery implies that the GAARs and the capabilities MUST be sent to the MN. I don't think this is true and necessary. All CAR discovery must do (where ever it resides) MUST make available its output to TAR selection (whereever that resides). That way we are satisfying everyone. Hope you understand my concern. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:28:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05397 for ; Wed, 27 Mar 2002 11:28:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15080; Wed, 27 Mar 2002 11:21:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15044 for ; Wed, 27 Mar 2002 11:21:43 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04964 for ; Wed, 27 Mar 2002 11:21:39 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 11:21:11 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC59@ftmail> From: George Tsirtsis To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:21:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org So, is there anyone that seriously thinks that "blasting GAAR IDs and all of their capabilities to MN" is a good idea? If not (which I hope so) then the requirements document should not imply otherwise. George -----Original Message----- From: Hemant Chaskar [mailto:hchaskar@hotmail.com] Sent: Wednesday, March 27, 2002 4:08 PM To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Hi Hernik: I did read your comment and responded as follows in my earlier email. Cut'n'Paste: ------------------------------- If we honestly think that the requirement does not oblige AR to blast all GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do we need to hide this fact? We can come up with something else, if you do not like on-demand extension. I think without such extension the solution satisfying this requirement may have serious shortcomings that I described in my other email to James. -------------------------------- BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 02:09:44 +0100 > >Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR >information, it does not require *on-demand operation*, it expresses >exactly >what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > I think that's the essence of it. Do you oppose this? Why? Do you >want to make things more complicated than they have to be? > > Henrik > >Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this >requirement. > > They are described below. How can we finalise this requirement unless it >is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering >design, > > namely efficiency. The solution satisfying this requirement is obliged >to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might >be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case >(i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic >over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood >causes > > power wastage. This is because, after receiving these capabilities MN >either > > rejects the new AR (which is worst), and even if it selcects one why >does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable >fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the >definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement >that > > you proposed and who have not, we should first analyse above harmful >effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we >are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR >discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant >of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham >has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:28:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05408 for ; Wed, 27 Mar 2002 11:28:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16998 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:28:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15080; Wed, 27 Mar 2002 11:21:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15044 for ; Wed, 27 Mar 2002 11:21:43 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04964 for ; Wed, 27 Mar 2002 11:21:39 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 11:21:11 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC59@ftmail> From: George Tsirtsis To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:21:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org So, is there anyone that seriously thinks that "blasting GAAR IDs and all of their capabilities to MN" is a good idea? If not (which I hope so) then the requirements document should not imply otherwise. George -----Original Message----- From: Hemant Chaskar [mailto:hchaskar@hotmail.com] Sent: Wednesday, March 27, 2002 4:08 PM To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Hi Hernik: I did read your comment and responded as follows in my earlier email. Cut'n'Paste: ------------------------------- If we honestly think that the requirement does not oblige AR to blast all GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do we need to hide this fact? We can come up with something else, if you do not like on-demand extension. I think without such extension the solution satisfying this requirement may have serious shortcomings that I described in my other email to James. -------------------------------- BR, Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 02:09:44 +0100 > >Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR >information, it does not require *on-demand operation*, it expresses >exactly >what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > I think that's the essence of it. Do you oppose this? Why? Do you >want to make things more complicated than they have to be? > > Henrik > >Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this >requirement. > > They are described below. How can we finalise this requirement unless it >is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering >design, > > namely efficiency. The solution satisfying this requirement is obliged >to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might >be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case >(i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic >over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood >causes > > power wastage. This is because, after receiving these capabilities MN >either > > rejects the new AR (which is worst), and even if it selcects one why >does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable >fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the >definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement >that > > you proposed and who have not, we should first analyse above harmful >effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we >are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR >discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant >of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham >has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:28:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05432 for ; Wed, 27 Mar 2002 11:28:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15240; Wed, 27 Mar 2002 11:22:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15197 for ; Wed, 27 Mar 2002 11:22:11 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04969 for ; Wed, 27 Mar 2002 11:22:07 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RGLcI05319; Wed, 27 Mar 2002 08:21:38 -0800 (PST) Message-ID: <003201c1d5ab$3fce8eb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 08:20:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Like I said, premature optimization is always a bad idea. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Wednesday, March 27, 2002 12:40 AM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi James: > > There are serious shortcomings of the solution satisfying this requirement. > They are described below. How can we finalise this requirement unless it is > agreed that these pitfalls do not exist? > > For this, it might be good idea to visualise how the solution satisfying > this requirement looks like and violates basic tenets of engineering design, > namely efficiency. The solution satisfying this requirement is obliged to > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > big chunk of data (= number of GAARs times capability set of each). This > flood will occur either on active traffic connection which I call case (i) > (relevant for single interface MN and two-interface MN where second > interface is sleeping) or on second interface which I call case (ii) > (relevant for two interface MN with both interfaces awake). There are > following effects of this flood: > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > active traffic channel. > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > power wastage. This is because, after receiving these capabilities MN either > rejects the new AR (which is worst), and even if it selcects one why does it > need to receive capabilities of GAARs that do not matter for it. > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > sees. Which means the same information (which could be big enough) is > transmitted on downlink so many times. This takes up considerable fraction > of downlink capacity. > > 4. Limit on capability definition: This requirement restricts the definition > of capabilities to a very small size, otherwise all ARs will only be > transmitting GAAR capabilities to different MNs all the time. This means > capability set cannot be comprehensive and extensible. > > So, IMHO rather than counting who agrees to one statement requirement that > you proposed and who have not, we should first analyse above harmful effects > before deciding either way. > > Br, > Hemant > > > >From: "James Kempf" > >To: "Govind Krishnamurthi" , > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > >Examples of CAR discovery) > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > This seems contradictory to your earlier mails saying that there is > > > no basis for network based CAR discovery. So are you now agreeing > > > that network based CAR discovery has its place? > > > > > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:28:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05446 for ; Wed, 27 Mar 2002 11:28:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17088 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:28:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15240; Wed, 27 Mar 2002 11:22:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15197 for ; Wed, 27 Mar 2002 11:22:11 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04969 for ; Wed, 27 Mar 2002 11:22:07 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RGLcI05319; Wed, 27 Mar 2002 08:21:38 -0800 (PST) Message-ID: <003201c1d5ab$3fce8eb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 08:20:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, Like I said, premature optimization is always a bad idea. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Wednesday, March 27, 2002 12:40 AM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi James: > > There are serious shortcomings of the solution satisfying this requirement. > They are described below. How can we finalise this requirement unless it is > agreed that these pitfalls do not exist? > > For this, it might be good idea to visualise how the solution satisfying > this requirement looks like and violates basic tenets of engineering design, > namely efficiency. The solution satisfying this requirement is obliged to > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > big chunk of data (= number of GAARs times capability set of each). This > flood will occur either on active traffic connection which I call case (i) > (relevant for single interface MN and two-interface MN where second > interface is sleeping) or on second interface which I call case (ii) > (relevant for two interface MN with both interfaces awake). There are > following effects of this flood: > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > active traffic channel. > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > power wastage. This is because, after receiving these capabilities MN either > rejects the new AR (which is worst), and even if it selcects one why does it > need to receive capabilities of GAARs that do not matter for it. > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > sees. Which means the same information (which could be big enough) is > transmitted on downlink so many times. This takes up considerable fraction > of downlink capacity. > > 4. Limit on capability definition: This requirement restricts the definition > of capabilities to a very small size, otherwise all ARs will only be > transmitting GAAR capabilities to different MNs all the time. This means > capability set cannot be comprehensive and extensible. > > So, IMHO rather than counting who agrees to one statement requirement that > you proposed and who have not, we should first analyse above harmful effects > before deciding either way. > > Br, > Hemant > > > >From: "James Kempf" > >To: "Govind Krishnamurthi" , > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > >Examples of CAR discovery) > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > This seems contradictory to your earlier mails saying that there is > > > no basis for network based CAR discovery. So are you now agreeing > > > that network based CAR discovery has its place? > > > > > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:29:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05473 for ; Wed, 27 Mar 2002 11:29:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15680; Wed, 27 Mar 2002 11:23:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15640 for ; Wed, 27 Mar 2002 11:23:47 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05037 for ; Wed, 27 Mar 2002 11:23:43 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RGNEI05346; Wed, 27 Mar 2002 08:23:14 -0800 (PST) Message-ID: <003c01c1d5ab$78e67e60$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 08:21:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Of course it is CAR discovery. The MN takes the GAARs and figures out which are CARs. Then it performs TAR. What you seem to want is for the AR to do the CAR selection. As I've pointed out numerous times, the AR can't possibly know a priori what the MN's current interface configuration is at any day and time. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Tuesday, March 26, 2002 4:53 PM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > [Govind] First what you are calling as CAR discovery is not CAR discovery. > What you are saying is GAAR + associated capabilities discovery > not CAR discovery therefore part of CAR discovery. CAR discovery matches the > requirements of the MN with the capabilities of the GAARs. > > Having said that, if the purpose of the sending this information to > the MN is to run the TAR selection algorithm there, then it would be > prudent to filter out some of the GAARs (which don't satisfy the MN's > requirements) and send only the remaining to the MN. That would reduce > the bandwidth as well as power. > > Having said that, I disagree with this requirement which first forces a > particular TAR selection aspect onto CAR discovery which I feel is totally > not required. A better requirement is CAR discovery output MUST > be made available to the TAR selection algorithm whereever it resides. > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant >of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > [Govind] I don't agree to the fact that MN must alone do the discovery. > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > [Govind] Well I'm against it and I know others who have objected to this > too. > > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > [Govind] I agree that the requirement 3.4 may look biased toward a AR > solution and we can re-word it. But to swing the pendulum to the other > extreme which prohibits anything other than a MN based discovery is > not correct. > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:29:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05482 for ; Wed, 27 Mar 2002 11:29:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17350 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:29:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15680; Wed, 27 Mar 2002 11:23:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15640 for ; Wed, 27 Mar 2002 11:23:47 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05037 for ; Wed, 27 Mar 2002 11:23:43 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RGNEI05346; Wed, 27 Mar 2002 08:23:14 -0800 (PST) Message-ID: <003c01c1d5ab$78e67e60$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 08:21:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Of course it is CAR discovery. The MN takes the GAARs and figures out which are CARs. Then it performs TAR. What you seem to want is for the AR to do the CAR selection. As I've pointed out numerous times, the AR can't possibly know a priori what the MN's current interface configuration is at any day and time. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Tuesday, March 26, 2002 4:53 PM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > [Govind] First what you are calling as CAR discovery is not CAR discovery. > What you are saying is GAAR + associated capabilities discovery > not CAR discovery therefore part of CAR discovery. CAR discovery matches the > requirements of the MN with the capabilities of the GAARs. > > Having said that, if the purpose of the sending this information to > the MN is to run the TAR selection algorithm there, then it would be > prudent to filter out some of the GAARs (which don't satisfy the MN's > requirements) and send only the remaining to the MN. That would reduce > the bandwidth as well as power. > > Having said that, I disagree with this requirement which first forces a > particular TAR selection aspect onto CAR discovery which I feel is totally > not required. A better requirement is CAR discovery output MUST > be made available to the TAR selection algorithm whereever it resides. > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant >of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > [Govind] I don't agree to the fact that MN must alone do the discovery. > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > [Govind] Well I'm against it and I know others who have objected to this > too. > > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > [Govind] I agree that the requirement 3.4 may look biased toward a AR > solution and we can re-word it. But to swing the pendulum to the other > extreme which prohibits anything other than a MN based discovery is > not correct. > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:30:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05641 for ; Wed, 27 Mar 2002 11:30:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16815; Wed, 27 Mar 2002 11:28:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16729 for ; Wed, 27 Mar 2002 11:27:56 -0500 (EST) Received: from hotmail.com (f243.law9.hotmail.com [64.4.9.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05351 for ; Wed, 27 Mar 2002 11:27:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:27:25 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:27:24 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: G.Tsirtsis@flarion.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 11:27:24 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:27:25.0047 (UTC) FILETIME=[474E0070:01C1D5AC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Thanks George! Thats I have been arguing against for what seems eternity. Thanks, Govind. > >So, is there anyone that seriously thinks that "blasting GAAR IDs and all >of >their capabilities to MN" is a good idea? If not (which I hope so) then the >requirements document should not imply otherwise. > >George > >-----Original Message----- >From: Hemant Chaskar [mailto:hchaskar@hotmail.com] >Sent: Wednesday, March 27, 2002 4:08 PM >To: seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) > > >Hi Hernik: > >I did read your comment and responded as follows in my earlier email. >Cut'n'Paste: > >------------------------------- >If we honestly think that the requirement does not oblige AR to blast all >GAAR IDs and all of their capabilities to MN, why not say so clearly. Why >do > >we need to hide this fact? We can come up with something else, if you do >not > >like on-demand extension. I think without such extension the solution >satisfying this requirement may have serious shortcomings that I described >in my other email to James. >-------------------------------- > >BR, >Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless >it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution >satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might > >be a > > > big chunk of data (= number of GAARs times capability set of each). >This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that >it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This >means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there >is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is >clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include >this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:30:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05648 for ; Wed, 27 Mar 2002 11:30:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17636 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:30:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16815; Wed, 27 Mar 2002 11:28:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16729 for ; Wed, 27 Mar 2002 11:27:56 -0500 (EST) Received: from hotmail.com (f243.law9.hotmail.com [64.4.9.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05351 for ; Wed, 27 Mar 2002 11:27:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:27:25 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:27:24 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: G.Tsirtsis@flarion.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 11:27:24 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:27:25.0047 (UTC) FILETIME=[474E0070:01C1D5AC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Thanks George! Thats I have been arguing against for what seems eternity. Thanks, Govind. > >So, is there anyone that seriously thinks that "blasting GAAR IDs and all >of >their capabilities to MN" is a good idea? If not (which I hope so) then the >requirements document should not imply otherwise. > >George > >-----Original Message----- >From: Hemant Chaskar [mailto:hchaskar@hotmail.com] >Sent: Wednesday, March 27, 2002 4:08 PM >To: seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) > > >Hi Hernik: > >I did read your comment and responded as follows in my earlier email. >Cut'n'Paste: > >------------------------------- >If we honestly think that the requirement does not oblige AR to blast all >GAAR IDs and all of their capabilities to MN, why not say so clearly. Why >do > >we need to hide this fact? We can come up with something else, if you do >not > >like on-demand extension. I think without such extension the solution >satisfying this requirement may have serious shortcomings that I described >in my other email to James. >-------------------------------- > >BR, >Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless >it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution >satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might > >be a > > > big chunk of data (= number of GAARs times capability set of each). >This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that >it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This >means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there >is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is >clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include >this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:30:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05690 for ; Wed, 27 Mar 2002 11:30:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16909; Wed, 27 Mar 2002 11:28:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16873 for ; Wed, 27 Mar 2002 11:28:11 -0500 (EST) Received: from hotmail.com (f54.law7.hotmail.com [216.33.237.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05366 for ; Wed, 27 Mar 2002 11:28:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:27:38 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:27:38 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:27:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:27:38.0896 (UTC) FILETIME=[4F8F3100:01C1D5AC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi George: I think this blind blasting is a bad idea, and hence, requirement should not imply it. The current requirement (as seen from the plain statement text) may imply this. Hence, it needs some extension. That is what I am saying. Hemant >From: George Tsirtsis >To: 'Hemant Chaskar' , seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 11:21:10 -0500 > >So, is there anyone that seriously thinks that "blasting GAAR IDs and all >of >their capabilities to MN" is a good idea? If not (which I hope so) then the >requirements document should not imply otherwise. > >George > >-----Original Message----- >From: Hemant Chaskar [mailto:hchaskar@hotmail.com] >Sent: Wednesday, March 27, 2002 4:08 PM >To: seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) > > >Hi Hernik: > >I did read your comment and responded as follows in my earlier email. >Cut'n'Paste: > >------------------------------- >If we honestly think that the requirement does not oblige AR to blast all >GAAR IDs and all of their capabilities to MN, why not say so clearly. Why >do > >we need to hide this fact? We can come up with something else, if you do >not > >like on-demand extension. I think without such extension the solution >satisfying this requirement may have serious shortcomings that I described >in my other email to James. >-------------------------------- > >BR, >Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless >it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution >satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might > >be a > > > big chunk of data (= number of GAARs times capability set of each). >This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that >it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This >means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there >is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is >clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include >this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:30:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05700 for ; Wed, 27 Mar 2002 11:30:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17706 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:30:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16909; Wed, 27 Mar 2002 11:28:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16873 for ; Wed, 27 Mar 2002 11:28:11 -0500 (EST) Received: from hotmail.com (f54.law7.hotmail.com [216.33.237.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05366 for ; Wed, 27 Mar 2002 11:28:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:27:38 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:27:38 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:27:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:27:38.0896 (UTC) FILETIME=[4F8F3100:01C1D5AC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi George: I think this blind blasting is a bad idea, and hence, requirement should not imply it. The current requirement (as seen from the plain statement text) may imply this. Hence, it needs some extension. That is what I am saying. Hemant >From: George Tsirtsis >To: 'Hemant Chaskar' , seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 11:21:10 -0500 > >So, is there anyone that seriously thinks that "blasting GAAR IDs and all >of >their capabilities to MN" is a good idea? If not (which I hope so) then the >requirements document should not imply otherwise. > >George > >-----Original Message----- >From: Hemant Chaskar [mailto:hchaskar@hotmail.com] >Sent: Wednesday, March 27, 2002 4:08 PM >To: seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) > > >Hi Hernik: > >I did read your comment and responded as follows in my earlier email. >Cut'n'Paste: > >------------------------------- >If we honestly think that the requirement does not oblige AR to blast all >GAAR IDs and all of their capabilities to MN, why not say so clearly. Why >do > >we need to hide this fact? We can come up with something else, if you do >not > >like on-demand extension. I think without such extension the solution >satisfying this requirement may have serious shortcomings that I described >in my other email to James. >-------------------------------- > >BR, >Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless >it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution >satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might > >be a > > > big chunk of data (= number of GAARs times capability set of each). >This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that >it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This >means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there >is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is >clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include >this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:31:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05766 for ; Wed, 27 Mar 2002 11:31:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17071; Wed, 27 Mar 2002 11:28:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17033 for ; Wed, 27 Mar 2002 11:28:32 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05429 for ; Wed, 27 Mar 2002 11:28:30 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGUv117056 for ; Wed, 27 Mar 2002 10:30:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:28:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:27:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:27:36 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVq5n4bxKQaSulSeCN+muVeGszvQAAA+pw To: , , X-OriginalArrivalTime: 27 Mar 2002 16:27:37.0313 (UTC) FILETIME=[4E9DA510:01C1D5AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA17035 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Like I said, premature optimization is always a bad idea. [DOT] So it is not premature to enable transfer of data of which we don't know what it is about and how much it is? The "optimization" you're refering to restricts possible flooding, in particular since we are at a premature state of knowing what information is to be transferred. Hence, what I want to avoid is having a premature decision of transfering a bunch of data that might be worthless in large parts. I don't understand why this is a bad idea? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:31:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05779 for ; Wed, 27 Mar 2002 11:31:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17884 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:31:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17071; Wed, 27 Mar 2002 11:28:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17033 for ; Wed, 27 Mar 2002 11:28:32 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05429 for ; Wed, 27 Mar 2002 11:28:30 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGUv117056 for ; Wed, 27 Mar 2002 10:30:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:28:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:27:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:27:36 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVq5n4bxKQaSulSeCN+muVeGszvQAAA+pw To: , , X-OriginalArrivalTime: 27 Mar 2002 16:27:37.0313 (UTC) FILETIME=[4E9DA510:01C1D5AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA17035 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Like I said, premature optimization is always a bad idea. [DOT] So it is not premature to enable transfer of data of which we don't know what it is about and how much it is? The "optimization" you're refering to restricts possible flooding, in particular since we are at a premature state of knowing what information is to be transferred. Hence, what I want to avoid is having a premature decision of transfering a bunch of data that might be worthless in large parts. I don't understand why this is a bad idea? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:31:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05796 for ; Wed, 27 Mar 2002 11:31:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17191; Wed, 27 Mar 2002 11:28:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17151 for ; Wed, 27 Mar 2002 11:28:49 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05460 for ; Wed, 27 Mar 2002 11:28:47 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGSnkY020858 for ; Wed, 27 Mar 2002 17:28:49 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:28:22 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:18:14 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB8C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:28:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > [Govind] First, I don't think that it is a > "complicated" protocol > > > as you suggest. As I pointed out it could just be part of > > > the MN's profile. > > > >=> What exactly would this profile say? And what impacts > >does it have on privacy? > > > > [Govind] > The MN makes available to the network whatever it needs to > for handover > decision thats all (this is the part required by CAR discovery. This > profile might make available other things, ofcourse.) > Privacy is an important issue and has to be tackled of > course. But that > doesn't mean we can't do it. => I haven't seen an answert to my question yet. What would the profile say??? Second, profile was just an example > to illustrate to James. There might be other ways of doing it. > Therefore right, we will look at this when the complete protocol is > presented each one of us. We should address this issue then and not > now. Otherwise this discussiong goes too much into solution space. > Precluding me from doing so right now implies that there is no way > of doing CAR discovery in the network which is I think a > little premature > now. > => No. You're avoiding a question that several people have raised by saying let's do it later. The problem here is that people are trying to say to you that you're making it too complicated. So I think you need to show an example of this profile. I'm sorry. but your answer above is only confirming my concerns. > > > Second, pushing capabilities down to the MN for its decision > > > has power,bandwidth and time considerations which one may > > > want to consider. > > > >=> only as much as an RA would have. Are you saying > >RAs should not be allowed? > > [Govind] Ofcourse not, if you intend to do CAR discovery that way > by all means you should be allowed to... (which again gets me to the > mail to you which talks about this matter.. please take a look at it > and let me know your comments). But there are performance > tradeoffs when > you do this, because you the RA does not contain the > capabilities that might > be required by the MN. The capabilities have to be sent over > to the MN. This has to be done for each AP the MN wants to check. > This does conserve power, bandwidth and in a low bandwidth > environment, it does take time too depending on how many > capabilities => We've discussed this in MPLS also. You only need an option in the RA. How frequently do you think the capabilities change? Depending on the link layer, the AR can also send the RA only at the time of handover, so I don't think the power conservation argument applies here. > are to be sent. Again, I am not preventing you to do it. If the > requirement does not allow you to do this I agree we should > re-word it. => That's all I've been asking for during the last 2 months. Can we just do it?! > But it should allow me to do my way of implementing things > too if I choose > to. => It's not about your way or my way, it's about placing reasonable requirements. If enough people are concerned, then you need to justify why the requirements should implicitly exclude certain scenarios. To quote Steve Deering in the meeting: ' I don't think I'm crazy if I say that there is a bias towards network controlled handovers'. All I am asking is that, then we decide based on the > protocol. There are > performance tradeoffs to each scheme. => I don't agree with the performance argument. As I continue to say, the RA can be sent 'on demand' if your L2 allows it. For ones that don't, BW is not a major issue. > > > >=> How does it restrict it? > > [Govind] The requirement as James proposed it says that CAR > discovery > implies that the GAARs and the capabilities MUST be sent to the MN. > I don't think this is true and necessary. All CAR discovery must > do (where ever it resides) MUST make available its output > to TAR selection > (whereever that resides). => Govind, sorry, but this is 'lawyer talk'. What do you mean 'wherever it resides' ???? It's either in the MN or the AR, there are no mysteries here. Be specific, each case requires different requirements. Or put differently, the MN case requires less requirements. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:31:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05805 for ; Wed, 27 Mar 2002 11:31:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17918 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:31:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17191; Wed, 27 Mar 2002 11:28:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17151 for ; Wed, 27 Mar 2002 11:28:49 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05460 for ; Wed, 27 Mar 2002 11:28:47 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGSnkY020858 for ; Wed, 27 Mar 2002 17:28:49 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:28:22 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:18:14 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB8C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:28:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > [Govind] First, I don't think that it is a > "complicated" protocol > > > as you suggest. As I pointed out it could just be part of > > > the MN's profile. > > > >=> What exactly would this profile say? And what impacts > >does it have on privacy? > > > > [Govind] > The MN makes available to the network whatever it needs to > for handover > decision thats all (this is the part required by CAR discovery. This > profile might make available other things, ofcourse.) > Privacy is an important issue and has to be tackled of > course. But that > doesn't mean we can't do it. => I haven't seen an answert to my question yet. What would the profile say??? Second, profile was just an example > to illustrate to James. There might be other ways of doing it. > Therefore right, we will look at this when the complete protocol is > presented each one of us. We should address this issue then and not > now. Otherwise this discussiong goes too much into solution space. > Precluding me from doing so right now implies that there is no way > of doing CAR discovery in the network which is I think a > little premature > now. > => No. You're avoiding a question that several people have raised by saying let's do it later. The problem here is that people are trying to say to you that you're making it too complicated. So I think you need to show an example of this profile. I'm sorry. but your answer above is only confirming my concerns. > > > Second, pushing capabilities down to the MN for its decision > > > has power,bandwidth and time considerations which one may > > > want to consider. > > > >=> only as much as an RA would have. Are you saying > >RAs should not be allowed? > > [Govind] Ofcourse not, if you intend to do CAR discovery that way > by all means you should be allowed to... (which again gets me to the > mail to you which talks about this matter.. please take a look at it > and let me know your comments). But there are performance > tradeoffs when > you do this, because you the RA does not contain the > capabilities that might > be required by the MN. The capabilities have to be sent over > to the MN. This has to be done for each AP the MN wants to check. > This does conserve power, bandwidth and in a low bandwidth > environment, it does take time too depending on how many > capabilities => We've discussed this in MPLS also. You only need an option in the RA. How frequently do you think the capabilities change? Depending on the link layer, the AR can also send the RA only at the time of handover, so I don't think the power conservation argument applies here. > are to be sent. Again, I am not preventing you to do it. If the > requirement does not allow you to do this I agree we should > re-word it. => That's all I've been asking for during the last 2 months. Can we just do it?! > But it should allow me to do my way of implementing things > too if I choose > to. => It's not about your way or my way, it's about placing reasonable requirements. If enough people are concerned, then you need to justify why the requirements should implicitly exclude certain scenarios. To quote Steve Deering in the meeting: ' I don't think I'm crazy if I say that there is a bias towards network controlled handovers'. All I am asking is that, then we decide based on the > protocol. There are > performance tradeoffs to each scheme. => I don't agree with the performance argument. As I continue to say, the RA can be sent 'on demand' if your L2 allows it. For ones that don't, BW is not a major issue. > > > >=> How does it restrict it? > > [Govind] The requirement as James proposed it says that CAR > discovery > implies that the GAARs and the capabilities MUST be sent to the MN. > I don't think this is true and necessary. All CAR discovery must > do (where ever it resides) MUST make available its output > to TAR selection > (whereever that resides). => Govind, sorry, but this is 'lawyer talk'. What do you mean 'wherever it resides' ???? It's either in the MN or the AR, there are no mysteries here. Be specific, each case requires different requirements. Or put differently, the MN case requires less requirements. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:31:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05843 for ; Wed, 27 Mar 2002 11:31:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16205; Wed, 27 Mar 2002 11:25:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16167 for ; Wed, 27 Mar 2002 11:25:56 -0500 (EST) Received: from hotmail.com (f43.law7.hotmail.com [216.33.237.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05245 for ; Wed, 27 Mar 2002 11:25:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:25:24 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:25:24 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@ipunplugged.com, teemu.rinta-aho@nomadiclab.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 16:25:24 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:25:24.0525 (UTC) FILETIME=[FF77CDD0:01C1D5AB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: ------------------snip--------------------------- >Neither. > >The "one access technology case" is the case where your mobile node only >has one access technology, i.e. only one interface, and will not have more. > >Designing for this case in particular, instead of designing for the general >case with multiple interfaces and technologies, will cripple our solution. > >Designing for the general case will permit handling this special case, >and many many others. [HC] I totally agree with your statement that we should list requirements for general case. But that is not what is happening here. Here requirements seem to be being formulated around a specific case of "two interface, both awake, no power constraint" case, without considering their impact on other cases. BR, Hemant > > Regards, > Henrik > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:31:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05852 for ; Wed, 27 Mar 2002 11:31:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18043 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:31:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16205; Wed, 27 Mar 2002 11:25:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16167 for ; Wed, 27 Mar 2002 11:25:56 -0500 (EST) Received: from hotmail.com (f43.law7.hotmail.com [216.33.237.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05245 for ; Wed, 27 Mar 2002 11:25:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:25:24 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:25:24 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@ipunplugged.com, teemu.rinta-aho@nomadiclab.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 16:25:24 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:25:24.0525 (UTC) FILETIME=[FF77CDD0:01C1D5AB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Henrik: ------------------snip--------------------------- >Neither. > >The "one access technology case" is the case where your mobile node only >has one access technology, i.e. only one interface, and will not have more. > >Designing for this case in particular, instead of designing for the general >case with multiple interfaces and technologies, will cripple our solution. > >Designing for the general case will permit handling this special case, >and many many others. [HC] I totally agree with your statement that we should list requirements for general case. But that is not what is happening here. Here requirements seem to be being formulated around a specific case of "two interface, both awake, no power constraint" case, without considering their impact on other cases. BR, Hemant > > Regards, > Henrik > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:35:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06078 for ; Wed, 27 Mar 2002 11:35:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18308; Wed, 27 Mar 2002 11:32:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18273 for ; Wed, 27 Mar 2002 11:32:39 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05917 for ; Wed, 27 Mar 2002 11:32:37 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGWcoq017037 for ; Wed, 27 Mar 2002 17:32:38 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:32:37 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:32:37 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB8D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:32:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA18274 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit What is iths blöasting that people keep bringing up? an extra option in an RA is blasting ???? What is the alternative: The magic AR that knows everything ?????????????? Seriously, let's keep it simple or this whole protocol will start collapsing the moment anyone starts deploying it. Of course if deployment is not a concern then I'll just og back to sleep! Hesham > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Wednesday, March 27, 2002 5:21 PM > To: 'Hemant Chaskar'; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (wa s: Examples of CAR discovery) > > > So, is there anyone that seriously thinks that "blasting > GAAR IDs and all of > their capabilities to MN" is a good idea? If not (which I > hope so) then the > requirements document should not imply otherwise. > > George > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 4:08 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > I did read your comment and responded as follows in my > earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige > AR to blast all > GAAR IDs and all of their capabilities to MN, why not say > so clearly. Why do > > we need to hide this fact? We can come up with something > else, if you do not > > like on-demand extension. I think without such extension > the solution > satisfying this requirement may have serious shortcomings > that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it > expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? > Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this > requirement unless it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the > solution satisfying > > > this requirement looks like and violates basic tenets > of engineering > >design, > > > namely efficiency. The solution satisfying this > requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR > sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability > set of each). This > > > flood will occur either on active traffic connection > which I call case > >(i) > > > (relevant for single interface MN and two-interface MN > where second > > > interface is sleeping) or on second interface which I > call case (ii) > > > (relevant for two interface MN with both interfaces > awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes > disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), > receiving this flood > >causes > > > power wastage. This is because, after receiving these > capabilities MN > >either > > > rejects the new AR (which is worst), and even if it > selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > every MN that it > > > sees. Which means the same information (which could be > big enough) is > > > transmitted on downlink so many times. This takes up > considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement > restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs > will only be > > > transmitting GAAR capabilities to different MNs all the > time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one > statement requirement > >that > > > you proposed and who have not, we should first analyse > above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list > of GAARs and > > > > > their capabilities to the MN (maybe only pass on > those which satisfy > > > > > the MN requirements, which is what CAR discovery > was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > Let me repeat the > > > >requirement I would like to see (and Henrik apparently > agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails > saying that there is > > > > > no basis for network based CAR discovery. So are > you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. > The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN > decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN > may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved > somehow, but that's a > > > >protocol design, not a requirement, choice. The > requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this > reqirement worded > > > >just this way. Nothing about "as the MN expresses its > preferences" or > > > >"by the CAR discovery module" or anything else. And I > believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should > we include this > > > >requirement instead of requirement 3.4, which has the > AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:35:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06101 for ; Wed, 27 Mar 2002 11:35:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19228 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:35:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18308; Wed, 27 Mar 2002 11:32:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18273 for ; Wed, 27 Mar 2002 11:32:39 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05917 for ; Wed, 27 Mar 2002 11:32:37 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGWcoq017037 for ; Wed, 27 Mar 2002 17:32:38 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:32:37 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:32:37 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB8D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:32:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA18274 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit What is iths blöasting that people keep bringing up? an extra option in an RA is blasting ???? What is the alternative: The magic AR that knows everything ?????????????? Seriously, let's keep it simple or this whole protocol will start collapsing the moment anyone starts deploying it. Of course if deployment is not a concern then I'll just og back to sleep! Hesham > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Wednesday, March 27, 2002 5:21 PM > To: 'Hemant Chaskar'; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (wa s: Examples of CAR discovery) > > > So, is there anyone that seriously thinks that "blasting > GAAR IDs and all of > their capabilities to MN" is a good idea? If not (which I > hope so) then the > requirements document should not imply otherwise. > > George > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 4:08 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > I did read your comment and responded as follows in my > earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige > AR to blast all > GAAR IDs and all of their capabilities to MN, why not say > so clearly. Why do > > we need to hide this fact? We can come up with something > else, if you do not > > like on-demand extension. I think without such extension > the solution > satisfying this requirement may have serious shortcomings > that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it > expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? > Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this > requirement unless it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the > solution satisfying > > > this requirement looks like and violates basic tenets > of engineering > >design, > > > namely efficiency. The solution satisfying this > requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR > sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability > set of each). This > > > flood will occur either on active traffic connection > which I call case > >(i) > > > (relevant for single interface MN and two-interface MN > where second > > > interface is sleeping) or on second interface which I > call case (ii) > > > (relevant for two interface MN with both interfaces > awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes > disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), > receiving this flood > >causes > > > power wastage. This is because, after receiving these > capabilities MN > >either > > > rejects the new AR (which is worst), and even if it > selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > every MN that it > > > sees. Which means the same information (which could be > big enough) is > > > transmitted on downlink so many times. This takes up > considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement > restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs > will only be > > > transmitting GAAR capabilities to different MNs all the > time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one > statement requirement > >that > > > you proposed and who have not, we should first analyse > above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list > of GAARs and > > > > > their capabilities to the MN (maybe only pass on > those which satisfy > > > > > the MN requirements, which is what CAR discovery > was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > Let me repeat the > > > >requirement I would like to see (and Henrik apparently > agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails > saying that there is > > > > > no basis for network based CAR discovery. So are > you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. > The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN > decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN > may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved > somehow, but that's a > > > >protocol design, not a requirement, choice. The > requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this > reqirement worded > > > >just this way. Nothing about "as the MN expresses its > preferences" or > > > >"by the CAR discovery module" or anything else. And I > believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should > we include this > > > >requirement instead of requirement 3.4, which has the > AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:36:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06296 for ; Wed, 27 Mar 2002 11:36:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18833; Wed, 27 Mar 2002 11:34:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18737 for ; Wed, 27 Mar 2002 11:34:12 -0500 (EST) Received: from hotmail.com (f225.law9.hotmail.com [64.4.9.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06020 for ; Wed, 27 Mar 2002 11:34:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:33:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:33:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 11:33:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:33:42.0508 (UTC) FILETIME=[2849FAC0:01C1D5AD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >Govind, > >Of course it is CAR discovery. The MN takes the GAARs and figures out >which are CARs. Then it performs TAR. [Govind]All the GAARs and their capabilities is NOT CARs. I totally disagree. Second, it is your opinion that this is the way to do it. Not mine. > >What you seem to want is for the AR to do the CAR selection. As I've >pointed out numerous times, the AR can't possibly know a priori what the >MN's current interface configuration is at any day and time. [Govind] I have pointed out several times too about why it does not matter, as in the TAR selection process the reachability information from the MN will be there to take care of what you point out as the only difficulty. Right now I am saying that the AR should be allowed to do CAR discovery. I don't know what you mean by CAR selection. You seem to indicate that AR CANNOT DO IT. Which is clearly a technically unsubstantiated opinion till now, IMHO. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:36:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06304 for ; Wed, 27 Mar 2002 11:36:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19612 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:36:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18833; Wed, 27 Mar 2002 11:34:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18737 for ; Wed, 27 Mar 2002 11:34:12 -0500 (EST) Received: from hotmail.com (f225.law9.hotmail.com [64.4.9.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06020 for ; Wed, 27 Mar 2002 11:34:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:33:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:33:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 11:33:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:33:42.0508 (UTC) FILETIME=[2849FAC0:01C1D5AD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >Govind, > >Of course it is CAR discovery. The MN takes the GAARs and figures out >which are CARs. Then it performs TAR. [Govind]All the GAARs and their capabilities is NOT CARs. I totally disagree. Second, it is your opinion that this is the way to do it. Not mine. > >What you seem to want is for the AR to do the CAR selection. As I've >pointed out numerous times, the AR can't possibly know a priori what the >MN's current interface configuration is at any day and time. [Govind] I have pointed out several times too about why it does not matter, as in the TAR selection process the reachability information from the MN will be there to take care of what you point out as the only difficulty. Right now I am saying that the AR should be allowed to do CAR discovery. I don't know what you mean by CAR selection. You seem to indicate that AR CANNOT DO IT. Which is clearly a technically unsubstantiated opinion till now, IMHO. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:39:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06562 for ; Wed, 27 Mar 2002 11:39:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19345; Wed, 27 Mar 2002 11:35:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19311 for ; Wed, 27 Mar 2002 11:35:47 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06123 for ; Wed, 27 Mar 2002 11:35:44 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA26375; Wed, 27 Mar 2002 17:32:44 +0100 From: "Henrik Levkowetz" To: , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:35:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, We seem not to be communicating here. You snipped out the part of my posting where I point out that this requirement does *not* imply that the MN needs to bee flooded, and then you point out that to avoid flooding might be worthwile. The point I was trying to make here was: This requirement does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I am starting to wonder why people protest and debate this requirement so much, even when it seems to allow for all variations that people have advocated, exactly as it stands? Henrik > > Hi Henrik, > > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > [DOT] Avoiding flooding of MN with unnecessary information might complicate > the design but might also be a worthwhile goal of a protocol design? > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:39:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06578 for ; Wed, 27 Mar 2002 11:39:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20513 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:39:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19345; Wed, 27 Mar 2002 11:35:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19311 for ; Wed, 27 Mar 2002 11:35:47 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06123 for ; Wed, 27 Mar 2002 11:35:44 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA26375; Wed, 27 Mar 2002 17:32:44 +0100 From: "Henrik Levkowetz" To: , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:35:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, We seem not to be communicating here. You snipped out the part of my posting where I point out that this requirement does *not* imply that the MN needs to bee flooded, and then you point out that to avoid flooding might be worthwile. The point I was trying to make here was: This requirement does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I am starting to wonder why people protest and debate this requirement so much, even when it seems to allow for all variations that people have advocated, exactly as it stands? Henrik > > Hi Henrik, > > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > [DOT] Avoiding flooding of MN with unnecessary information might complicate > the design but might also be a worthwhile goal of a protocol design? > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:40:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06660 for ; Wed, 27 Mar 2002 11:40:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18621; Wed, 27 Mar 2002 11:33:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18575 for ; Wed, 27 Mar 2002 11:33:44 -0500 (EST) Received: from hotmail.com (f216.law7.hotmail.com [216.33.237.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05968 for ; Wed, 27 Mar 2002 11:33:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:33:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:33:14 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:33:14 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:33:14.0843 (UTC) FILETIME=[17CCA2B0:01C1D5AD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James: And formulating a generic requirement without studying its performance impact on all possible cases is even worse, IMHO. I explicitly make my "disagreement" known over this requirement in its current form, in case you are counting votes. It needs some extension. At least this one: "The impact of this on power, wireless bandwidth and mobile terminal's interface capabilities MUST be considered". BR, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 08:20:02 -0800 > >Hemant, > >Like I said, premature optimization is always a bad idea. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: >Sent: Wednesday, March 27, 2002 12:40 AM >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this >requirement. > > They are described below. How can we finalise this requirement unless >it is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution >satisfying > > this requirement looks like and violates basic tenets of engineering >design, > > namely efficiency. The solution satisfying this requirement is obliged >to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might be a > > big chunk of data (= number of GAARs times capability set of each). >This > > flood will occur either on active traffic connection which I call case >(i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood >causes > > power wastage. This is because, after receiving these capabilities MN >either > > rejects the new AR (which is worst), and even if it selcects one why >does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that >it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable >fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the >definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This >means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement >that > > you proposed and who have not, we should first analyse above harmful >effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we >are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR >discovery. > > > > This seems contradictory to your earlier mails saying that there >is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant >of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is >clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham >has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include >this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:40:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06669 for ; Wed, 27 Mar 2002 11:40:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20759 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:40:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18621; Wed, 27 Mar 2002 11:33:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18575 for ; Wed, 27 Mar 2002 11:33:44 -0500 (EST) Received: from hotmail.com (f216.law7.hotmail.com [216.33.237.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05968 for ; Wed, 27 Mar 2002 11:33:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:33:14 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:33:14 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:33:14 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:33:14.0843 (UTC) FILETIME=[17CCA2B0:01C1D5AD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James: And formulating a generic requirement without studying its performance impact on all possible cases is even worse, IMHO. I explicitly make my "disagreement" known over this requirement in its current form, in case you are counting votes. It needs some extension. At least this one: "The impact of this on power, wireless bandwidth and mobile terminal's interface capabilities MUST be considered". BR, Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 08:20:02 -0800 > >Hemant, > >Like I said, premature optimization is always a bad idea. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: >Sent: Wednesday, March 27, 2002 12:40 AM >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this >requirement. > > They are described below. How can we finalise this requirement unless >it is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution >satisfying > > this requirement looks like and violates basic tenets of engineering >design, > > namely efficiency. The solution satisfying this requirement is obliged >to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might be a > > big chunk of data (= number of GAARs times capability set of each). >This > > flood will occur either on active traffic connection which I call case >(i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood >causes > > power wastage. This is because, after receiving these capabilities MN >either > > rejects the new AR (which is worst), and even if it selcects one why >does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that >it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable >fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the >definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This >means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement >that > > you proposed and who have not, we should first analyse above harmful >effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we >are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR >discovery. > > > > This seems contradictory to your earlier mails saying that there >is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant >of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is >clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham >has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include >this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:40:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06754 for ; Wed, 27 Mar 2002 11:40:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20127; Wed, 27 Mar 2002 11:38:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20092 for ; Wed, 27 Mar 2002 11:38:15 -0500 (EST) Received: from hotmail.com (f112.law7.hotmail.com [216.33.237.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06483 for ; Wed, 27 Mar 2002 11:38:14 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:37:46 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:37:45 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:37:45 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:37:46.0114 (UTC) FILETIME=[B97D4E20:01C1D5AD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: No RA is not what blasting is about. What this requirement is saying is to send to MN a volume of data = Number of GAARs times capability set of each. Number of GAARs itself could be large and capability set could be very large too. It might contain policies, supported IP protocols, any application specific functionality support and this set could be extensible. Sending this volume of data to MN without any regard to whether it wants it or not is what I call blasting. Hemant >From: "Hesham Soliman (ERA)" >To: "'George Tsirtsis'" , "'Hemant Chaskar'" >, seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 17:32:30 +0100 > >What is iths blöasting that people keep >bringing up? an extra option in an RA is blasting ???? >What is the alternative: The magic AR that knows >everything ?????????????? > >Seriously, let's keep it simple or this whole >protocol will start collapsing the moment >anyone starts deploying it. Of course if deployment >is not a concern then I'll just og back to sleep! > >Hesham > > > -----Original Message----- > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > Sent: Wednesday, March 27, 2002 5:21 PM > > To: 'Hemant Chaskar'; seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (wa s: Examples of CAR discovery) > > > > > > So, is there anyone that seriously thinks that "blasting > > GAAR IDs and all of > > their capabilities to MN" is a good idea? If not (which I > > hope so) then the > > requirements document should not imply otherwise. > > > > George > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Wednesday, March 27, 2002 4:08 PM > > To: seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (was: Examples of CAR discovery) > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my > > earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige > > AR to blast all > > GAAR IDs and all of their capabilities to MN, why not say > > so clearly. Why do > > > > we need to hide this fact? We can come up with something > > else, if you do not > > > > like on-demand extension. I think without such extension > > the solution > > satisfying this requirement may have serious shortcomings > > that I described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it > > expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? > > Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this > > requirement unless it > > > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the > > solution satisfying > > > > this requirement looks like and violates basic tenets > > of engineering > > >design, > > > > namely efficiency. The solution satisfying this > > requirement is obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR > > sees MN. This might > > >be a > > > > big chunk of data (= number of GAARs times capability > > set of each). This > > > > flood will occur either on active traffic connection > > which I call case > > >(i) > > > > (relevant for single interface MN and two-interface MN > > where second > > > > interface is sleeping) or on second interface which I > > call case (ii) > > > > (relevant for two interface MN with both interfaces > > awake). There are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > disruption in traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > receiving this flood > > >causes > > > > power wastage. This is because, after receiving these > > capabilities MN > > >either > > > > rejects the new AR (which is worst), and even if it > > selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > every MN that it > > > > sees. Which means the same information (which could be > > big enough) is > > > > transmitted on downlink so many times. This takes up > > considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement > > restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs > > will only be > > > > transmitting GAAR capabilities to different MNs all the > > time. This means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one > > statement requirement > > >that > > > > you proposed and who have not, we should first analyse > > above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list > > of GAARs and > > > > > > their capabilities to the MN (maybe only pass on > > those which satisfy > > > > > > the MN requirements, which is what CAR discovery > > was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > Let me repeat the > > > > >requirement I would like to see (and Henrik apparently > > agrees) so we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails > > saying that there is > > > > > > no basis for network based CAR discovery. So are > > you now agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > The protocol allows > > > > >the MN to discover the GAAR and capabilities, the MN > > decides which one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN > > may use a variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved > > somehow, but that's a > > > > >protocol design, not a requirement, choice. The > > requirement is clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this > > reqirement worded > > > > >just this way. Nothing about "as the MN expresses its > > preferences" or > > > > >"by the CAR discovery module" or anything else. And I > > believe Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should > > we include this > > > > >requirement instead of requirement 3.4, which has the > > AR in control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:40:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06764 for ; Wed, 27 Mar 2002 11:40:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20945 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:40:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20127; Wed, 27 Mar 2002 11:38:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20092 for ; Wed, 27 Mar 2002 11:38:15 -0500 (EST) Received: from hotmail.com (f112.law7.hotmail.com [216.33.237.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06483 for ; Wed, 27 Mar 2002 11:38:14 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:37:46 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:37:45 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 16:37:45 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:37:46.0114 (UTC) FILETIME=[B97D4E20:01C1D5AD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: No RA is not what blasting is about. What this requirement is saying is to send to MN a volume of data = Number of GAARs times capability set of each. Number of GAARs itself could be large and capability set could be very large too. It might contain policies, supported IP protocols, any application specific functionality support and this set could be extensible. Sending this volume of data to MN without any regard to whether it wants it or not is what I call blasting. Hemant >From: "Hesham Soliman (ERA)" >To: "'George Tsirtsis'" , "'Hemant Chaskar'" >, seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 17:32:30 +0100 > >What is iths blöasting that people keep >bringing up? an extra option in an RA is blasting ???? >What is the alternative: The magic AR that knows >everything ?????????????? > >Seriously, let's keep it simple or this whole >protocol will start collapsing the moment >anyone starts deploying it. Of course if deployment >is not a concern then I'll just og back to sleep! > >Hesham > > > -----Original Message----- > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > Sent: Wednesday, March 27, 2002 5:21 PM > > To: 'Hemant Chaskar'; seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (wa s: Examples of CAR discovery) > > > > > > So, is there anyone that seriously thinks that "blasting > > GAAR IDs and all of > > their capabilities to MN" is a good idea? If not (which I > > hope so) then the > > requirements document should not imply otherwise. > > > > George > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Wednesday, March 27, 2002 4:08 PM > > To: seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (was: Examples of CAR discovery) > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my > > earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige > > AR to blast all > > GAAR IDs and all of their capabilities to MN, why not say > > so clearly. Why do > > > > we need to hide this fact? We can come up with something > > else, if you do not > > > > like on-demand extension. I think without such extension > > the solution > > satisfying this requirement may have serious shortcomings > > that I described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it > > expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? > > Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this > > requirement unless it > > > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the > > solution satisfying > > > > this requirement looks like and violates basic tenets > > of engineering > > >design, > > > > namely efficiency. The solution satisfying this > > requirement is obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR > > sees MN. This might > > >be a > > > > big chunk of data (= number of GAARs times capability > > set of each). This > > > > flood will occur either on active traffic connection > > which I call case > > >(i) > > > > (relevant for single interface MN and two-interface MN > > where second > > > > interface is sleeping) or on second interface which I > > call case (ii) > > > > (relevant for two interface MN with both interfaces > > awake). There are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > disruption in traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > receiving this flood > > >causes > > > > power wastage. This is because, after receiving these > > capabilities MN > > >either > > > > rejects the new AR (which is worst), and even if it > > selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > every MN that it > > > > sees. Which means the same information (which could be > > big enough) is > > > > transmitted on downlink so many times. This takes up > > considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement > > restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs > > will only be > > > > transmitting GAAR capabilities to different MNs all the > > time. This means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one > > statement requirement > > >that > > > > you proposed and who have not, we should first analyse > > above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list > > of GAARs and > > > > > > their capabilities to the MN (maybe only pass on > > those which satisfy > > > > > > the MN requirements, which is what CAR discovery > > was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > Let me repeat the > > > > >requirement I would like to see (and Henrik apparently > > agrees) so we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails > > saying that there is > > > > > > no basis for network based CAR discovery. So are > > you now agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > The protocol allows > > > > >the MN to discover the GAAR and capabilities, the MN > > decides which one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN > > may use a variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved > > somehow, but that's a > > > > >protocol design, not a requirement, choice. The > > requirement is clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this > > reqirement worded > > > > >just this way. Nothing about "as the MN expresses its > > preferences" or > > > > >"by the CAR discovery module" or anything else. And I > > believe Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should > > we include this > > > > >requirement instead of requirement 3.4, which has the > > AR in control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03494 for ; Wed, 27 Mar 2002 10:52:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06533 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 10:52:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05741; Wed, 27 Mar 2002 10:48:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05699 for ; Wed, 27 Mar 2002 10:48:46 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03335 for ; Wed, 27 Mar 2002 10:48:42 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFp4113036 for ; Wed, 27 Mar 2002 09:51:04 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 09:48:35 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 09:48:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:48:23 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVLDOT1gkMgUHmTfitUl25Q6PmPgAd3zFA To: , X-OriginalArrivalTime: 27 Mar 2002 15:48:24.0548 (UTC) FILETIME=[D4423240:01C1D5A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA05700 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi all, just to have another opinion on record. Firstly, I disagree with keeping the requirement in the current wording. Hemant already pointed out the major flaw of this requirement, namely the pushing of unnecessary information to the MN. James comment about "keeping it simple" neglects a simple fact. It is not about making it more complicated (how, just by adding "if required"???), it is about avoiding unnecessary flooding and therefore wasting power of the MN for receiving information it does not need or, even worse, does not want. Secondly, I even stronger disagree with REPLACING requirement 3.4 with this requirement, even in a re-worded manner. Requirement 3.4 deals with a different problem, namely the expression of MN requirements. Even though some people apparently think that this involves complicated AAA transactions (let's simply see what the solutions will bring), it just actually says that you need ANY means to express what the MN's requirements are. This is even important in an MN-based case, which could be realized in a simple user interface or something else. The proposed requirement though deals with information provision. Even if you get the information at the MN, you still need means to express your requirements so that you can do the match from GAARs to CARs. Regards, Dirk -----Original Message----- From: ext Henrik Levkowetz [mailto:henrik@levkowetz.com] Sent: Tuesday, March 26, 2002 8:10 PM To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Hemant, You apparently did not read my recent posting. Cut'n'Paste: No, the requirement is just fine. It does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I think that's the essence of it. Do you oppose this? Why? Do you want to make things more complicated than they have to be? Henrik Hemant wrote: > > Hi James: > > There are serious shortcomings of the solution satisfying this requirement. > They are described below. How can we finalise this requirement unless it is > agreed that these pitfalls do not exist? > > For this, it might be good idea to visualise how the solution satisfying > this requirement looks like and violates basic tenets of engineering design, > namely efficiency. The solution satisfying this requirement is obliged to > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > big chunk of data (= number of GAARs times capability set of each). This > flood will occur either on active traffic connection which I call case (i) > (relevant for single interface MN and two-interface MN where second > interface is sleeping) or on second interface which I call case (ii) > (relevant for two interface MN with both interfaces awake). There are > following effects of this flood: > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > active traffic channel. > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > power wastage. This is because, after receiving these capabilities MN either > rejects the new AR (which is worst), and even if it selcects one why does it > need to receive capabilities of GAARs that do not matter for it. > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > sees. Which means the same information (which could be big enough) is > transmitted on downlink so many times. This takes up considerable fraction > of downlink capacity. > > 4. Limit on capability definition: This requirement restricts the definition > of capabilities to a very small size, otherwise all ARs will only be > transmitting GAAR capabilities to different MNs all the time. This means > capability set cannot be comprehensive and extensible. > > So, IMHO rather than counting who agrees to one statement requirement that > you proposed and who have not, we should first analyse above harmful effects > before deciding either way. > > Br, > Hemant > > > >From: "James Kempf" > >To: "Govind Krishnamurthi" , > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > >Examples of CAR discovery) > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > >, > > > So now you agree that the AR can hand over the list of GAARs and > > > their capabilities to the MN (maybe only pass on those which satisfy > > > the MN requirements, which is what CAR discovery was originally > >about). > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > >requirement I would like to see (and Henrik apparently agrees) so we are > >clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > This seems contradictory to your earlier mails saying that there is > > > no basis for network based CAR discovery. So are you now agreeing > > > that network based CAR discovery has its place? > > > > > > >Please see the requirement above. No contradiction. The protocol allows > >the MN to discover the GAAR and capabilities, the MN decides which one > >it wants. > >Nothing about the AR in control of anything. The MN may use a variant of > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > >protocol design, not a requirement, choice. The requirement is clearly > >that the MN does the discovery. > > > >We now have two working group members who want this reqirement worded > >just this way. Nothing about "as the MN expresses its preferences" or > >"by the CAR discovery module" or anything else. And I believe Hesham has > >also expressed a preference for this requirement. > > > >Anybody else out there have an opinion on this? Should we include this > >requirement instead of requirement 3.4, which has the AR in control? > > > > jak > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:43:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06901 for ; Wed, 27 Mar 2002 11:43:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19925; Wed, 27 Mar 2002 11:37:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19891 for ; Wed, 27 Mar 2002 11:37:42 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06389 for ; Wed, 27 Mar 2002 11:37:40 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGe4118381 for ; Wed, 27 Mar 2002 10:40:04 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:37:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:36:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:36:45 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Thread-Index: AcHVrQzuhgNqT6ayRXGySvNvNRbJlAAABnbQ To: , , , X-OriginalArrivalTime: 27 Mar 2002 16:36:47.0043 (UTC) FILETIME=[9647C930:01C1D5AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA19892 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, What is iths blöasting that people keep bringing up? an extra option in an RA is blasting ???? What is the alternative: The magic AR that knows everything ?????????????? [DOT] Maybe, you should just read the requirement text and the mails that have been brought up in this context. We are not talking about an option in RAs, we are talking about the information that is stated in the requirement to be transfered. This is more than having an option. Maybe, you don't care about transferring unnecessary information to the MN, maybe others do. The discussion did not imply that the 'magic AR knows everything'. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:43:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06910 for ; Wed, 27 Mar 2002 11:43:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21640 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:43:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19925; Wed, 27 Mar 2002 11:37:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19891 for ; Wed, 27 Mar 2002 11:37:42 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06389 for ; Wed, 27 Mar 2002 11:37:40 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGe4118381 for ; Wed, 27 Mar 2002 10:40:04 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:37:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:36:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:36:45 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Thread-Index: AcHVrQzuhgNqT6ayRXGySvNvNRbJlAAABnbQ To: , , , X-OriginalArrivalTime: 27 Mar 2002 16:36:47.0043 (UTC) FILETIME=[9647C930:01C1D5AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA19892 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, What is iths blöasting that people keep bringing up? an extra option in an RA is blasting ???? What is the alternative: The magic AR that knows everything ?????????????? [DOT] Maybe, you should just read the requirement text and the mails that have been brought up in this context. We are not talking about an option in RAs, we are talking about the information that is stated in the requirement to be transfered. This is more than having an option. Maybe, you don't care about transferring unnecessary information to the MN, maybe others do. The discussion did not imply that the 'magic AR knows everything'. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:44:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07009 for ; Wed, 27 Mar 2002 11:44:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20178; Wed, 27 Mar 2002 11:38:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20121 for ; Wed, 27 Mar 2002 11:38:17 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06486 for ; Wed, 27 Mar 2002 11:38:15 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGcHoq019186 for ; Wed, 27 Mar 2002 17:38:17 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:38:16 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:28:09 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB8F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Govind Krishnamurthi , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:38:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org , > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those > which satisfy > > the MN requirements, which is what CAR discovery was originally > about). > > > > No, that it sends all, along with the capabilities. Let me > repeat the > requirement I would like to see (and Henrik apparently > agrees) so we are > clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. => Agreed. > > > > Which first implies that the network is taking care of > CAR discovery. > > This seems contradictory to your earlier mails saying > that there is > > no basis for network based CAR discovery. So are you now agreeing > > that network based CAR discovery has its place? > > > > Please see the requirement above. No contradiction. The > protocol allows > the MN to discover the GAAR and capabilities, the MN > decides which one > it wants. > Nothing about the AR in control of anything. The MN may use > a variant of > IPv6 neighbor discovery, the AR may be involved somehow, > but that's a > protocol design, not a requirement, choice. The requirement > is clearly > that the MN does the discovery. > > We now have two working group members who want this > reqirement worded > just this way. Nothing about "as the MN expresses its > preferences" or > "by the CAR discovery module" or anything else. And I > believe Hesham has > also expressed a preference for this requirement. => Agreed 200%. I know more people too that want this :) > > Anybody else out there have an opinion on this? Should we > include this > requirement instead of requirement 3.4, which has the AR in control? => Yep! Hesham > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:44:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07018 for ; Wed, 27 Mar 2002 11:44:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22024 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:44:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20178; Wed, 27 Mar 2002 11:38:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20121 for ; Wed, 27 Mar 2002 11:38:17 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06486 for ; Wed, 27 Mar 2002 11:38:15 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGcHoq019186 for ; Wed, 27 Mar 2002 17:38:17 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:38:16 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:28:09 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB8F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Govind Krishnamurthi , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:38:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org , > > So now you agree that the AR can hand over the list of GAARs and > > their capabilities to the MN (maybe only pass on those > which satisfy > > the MN requirements, which is what CAR discovery was originally > about). > > > > No, that it sends all, along with the capabilities. Let me > repeat the > requirement I would like to see (and Henrik apparently > agrees) so we are > clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. => Agreed. > > > > Which first implies that the network is taking care of > CAR discovery. > > This seems contradictory to your earlier mails saying > that there is > > no basis for network based CAR discovery. So are you now agreeing > > that network based CAR discovery has its place? > > > > Please see the requirement above. No contradiction. The > protocol allows > the MN to discover the GAAR and capabilities, the MN > decides which one > it wants. > Nothing about the AR in control of anything. The MN may use > a variant of > IPv6 neighbor discovery, the AR may be involved somehow, > but that's a > protocol design, not a requirement, choice. The requirement > is clearly > that the MN does the discovery. > > We now have two working group members who want this > reqirement worded > just this way. Nothing about "as the MN expresses its > preferences" or > "by the CAR discovery module" or anything else. And I > believe Hesham has > also expressed a preference for this requirement. => Agreed 200%. I know more people too that want this :) > > Anybody else out there have an opinion on this? Should we > include this > requirement instead of requirement 3.4, which has the AR in control? => Yep! Hesham > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:45:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07107 for ; Wed, 27 Mar 2002 11:45:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21099; Wed, 27 Mar 2002 11:41:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21054 for ; Wed, 27 Mar 2002 11:41:24 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06800 for ; Wed, 27 Mar 2002 11:41:22 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 11:40:54 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5A@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:40:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA21055 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham relax :-) The "extra option" on the RA may or may not be a problem. We will only know if this is a problem AFTER we know what "capabilities" mean i.e.: how much data can be in there for the list of GAARs. That does make me nervous, doesn't you? The problem of course starts from the fact that one AR is supposed to provide this list of GAARs + capabilities to the MN (which could be a lot of info). In a MN centric approach the MN knows which the GAARs are and gets their capabilities directly from them...much better IMO. George -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 4:33 PM To: 'George Tsirtsis'; 'Hemant Chaskar'; seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) What is iths blöasting that people keep bringing up? an extra option in an RA is blasting ???? What is the alternative: The magic AR that knows everything ?????????????? Seriously, let's keep it simple or this whole protocol will start collapsing the moment anyone starts deploying it. Of course if deployment is not a concern then I'll just og back to sleep! Hesham > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Wednesday, March 27, 2002 5:21 PM > To: 'Hemant Chaskar'; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (wa s: Examples of CAR discovery) > > > So, is there anyone that seriously thinks that "blasting > GAAR IDs and all of > their capabilities to MN" is a good idea? If not (which I > hope so) then the > requirements document should not imply otherwise. > > George > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 4:08 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > I did read your comment and responded as follows in my > earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige > AR to blast all > GAAR IDs and all of their capabilities to MN, why not say > so clearly. Why do > > we need to hide this fact? We can come up with something > else, if you do not > > like on-demand extension. I think without such extension > the solution > satisfying this requirement may have serious shortcomings > that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it > expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? > Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this > requirement unless it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the > solution satisfying > > > this requirement looks like and violates basic tenets > of engineering > >design, > > > namely efficiency. The solution satisfying this > requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR > sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability > set of each). This > > > flood will occur either on active traffic connection > which I call case > >(i) > > > (relevant for single interface MN and two-interface MN > where second > > > interface is sleeping) or on second interface which I > call case (ii) > > > (relevant for two interface MN with both interfaces > awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes > disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), > receiving this flood > >causes > > > power wastage. This is because, after receiving these > capabilities MN > >either > > > rejects the new AR (which is worst), and even if it > selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > every MN that it > > > sees. Which means the same information (which could be > big enough) is > > > transmitted on downlink so many times. This takes up > considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement > restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs > will only be > > > transmitting GAAR capabilities to different MNs all the > time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one > statement requirement > >that > > > you proposed and who have not, we should first analyse > above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list > of GAARs and > > > > > their capabilities to the MN (maybe only pass on > those which satisfy > > > > > the MN requirements, which is what CAR discovery > was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > Let me repeat the > > > >requirement I would like to see (and Henrik apparently > agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails > saying that there is > > > > > no basis for network based CAR discovery. So are > you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. > The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN > decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN > may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved > somehow, but that's a > > > >protocol design, not a requirement, choice. The > requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this > reqirement worded > > > >just this way. Nothing about "as the MN expresses its > preferences" or > > > >"by the CAR discovery module" or anything else. And I > believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should > we include this > > > >requirement instead of requirement 3.4, which has the > AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:45:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07116 for ; Wed, 27 Mar 2002 11:45:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22304 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:45:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21099; Wed, 27 Mar 2002 11:41:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21054 for ; Wed, 27 Mar 2002 11:41:24 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06800 for ; Wed, 27 Mar 2002 11:41:22 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 11:40:54 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5A@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:40:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA21055 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham relax :-) The "extra option" on the RA may or may not be a problem. We will only know if this is a problem AFTER we know what "capabilities" mean i.e.: how much data can be in there for the list of GAARs. That does make me nervous, doesn't you? The problem of course starts from the fact that one AR is supposed to provide this list of GAARs + capabilities to the MN (which could be a lot of info). In a MN centric approach the MN knows which the GAARs are and gets their capabilities directly from them...much better IMO. George -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 4:33 PM To: 'George Tsirtsis'; 'Hemant Chaskar'; seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) What is iths blöasting that people keep bringing up? an extra option in an RA is blasting ???? What is the alternative: The magic AR that knows everything ?????????????? Seriously, let's keep it simple or this whole protocol will start collapsing the moment anyone starts deploying it. Of course if deployment is not a concern then I'll just og back to sleep! Hesham > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Wednesday, March 27, 2002 5:21 PM > To: 'Hemant Chaskar'; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (wa s: Examples of CAR discovery) > > > So, is there anyone that seriously thinks that "blasting > GAAR IDs and all of > their capabilities to MN" is a good idea? If not (which I > hope so) then the > requirements document should not imply otherwise. > > George > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 4:08 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > I did read your comment and responded as follows in my > earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige > AR to blast all > GAAR IDs and all of their capabilities to MN, why not say > so clearly. Why do > > we need to hide this fact? We can come up with something > else, if you do not > > like on-demand extension. I think without such extension > the solution > satisfying this requirement may have serious shortcomings > that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it > expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? > Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this > requirement unless it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the > solution satisfying > > > this requirement looks like and violates basic tenets > of engineering > >design, > > > namely efficiency. The solution satisfying this > requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR > sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability > set of each). This > > > flood will occur either on active traffic connection > which I call case > >(i) > > > (relevant for single interface MN and two-interface MN > where second > > > interface is sleeping) or on second interface which I > call case (ii) > > > (relevant for two interface MN with both interfaces > awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes > disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), > receiving this flood > >causes > > > power wastage. This is because, after receiving these > capabilities MN > >either > > > rejects the new AR (which is worst), and even if it > selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > every MN that it > > > sees. Which means the same information (which could be > big enough) is > > > transmitted on downlink so many times. This takes up > considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement > restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs > will only be > > > transmitting GAAR capabilities to different MNs all the > time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one > statement requirement > >that > > > you proposed and who have not, we should first analyse > above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list > of GAARs and > > > > > their capabilities to the MN (maybe only pass on > those which satisfy > > > > > the MN requirements, which is what CAR discovery > was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > Let me repeat the > > > >requirement I would like to see (and Henrik apparently > agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails > saying that there is > > > > > no basis for network based CAR discovery. So are > you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. > The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN > decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN > may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved > somehow, but that's a > > > >protocol design, not a requirement, choice. The > requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this > reqirement worded > > > >just this way. Nothing about "as the MN expresses its > preferences" or > > > >"by the CAR discovery module" or anything else. And I > believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should > we include this > > > >requirement instead of requirement 3.4, which has the > AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:47:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07254 for ; Wed, 27 Mar 2002 11:47:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21989; Wed, 27 Mar 2002 11:44:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21909 for ; Wed, 27 Mar 2002 11:44:18 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06952 for ; Wed, 27 Mar 2002 11:44:09 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA26585; Wed, 27 Mar 2002 17:40:58 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:43:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hemant, The requirement as first proposed does not imply that *all* GAAR information must be sent. The requirement as first proposed also does not require that a filtering mechanism must be part of the solution. The revised requirement requires a filtering mechanism. I do not believe we know that this is the right way to go yet. Therefore I do not believe that it is good to add this restriction. Henrik > > > Hi Hernik: > > I did read your comment and responded as follows in my earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige AR to blast all > GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do > we need to hide this fact? We can come up with something else, if you do not > like on-demand extension. I think without such extension the solution > satisfying this requirement may have serious shortcomings that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless it > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability set of each). This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:47:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07262 for ; Wed, 27 Mar 2002 11:47:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22929 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:47:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21989; Wed, 27 Mar 2002 11:44:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21909 for ; Wed, 27 Mar 2002 11:44:18 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06952 for ; Wed, 27 Mar 2002 11:44:09 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA26585; Wed, 27 Mar 2002 17:40:58 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:43:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hemant, The requirement as first proposed does not imply that *all* GAAR information must be sent. The requirement as first proposed also does not require that a filtering mechanism must be part of the solution. The revised requirement requires a filtering mechanism. I do not believe we know that this is the right way to go yet. Therefore I do not believe that it is good to add this restriction. Henrik > > > Hi Hernik: > > I did read your comment and responded as follows in my earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige AR to blast all > GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do > we need to hide this fact? We can come up with something else, if you do not > like on-demand extension. I think without such extension the solution > satisfying this requirement may have serious shortcomings that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless it > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability set of each). This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:49:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07400 for ; Wed, 27 Mar 2002 11:49:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21756; Wed, 27 Mar 2002 11:43:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21716 for ; Wed, 27 Mar 2002 11:43:41 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06931 for ; Wed, 27 Mar 2002 11:43:39 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGhfkY025799 for ; Wed, 27 Mar 2002 17:43:41 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:43:39 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:43:39 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB91@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , "Hesham Soliman (ERA)" , G.Tsirtsis@flarion.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:43:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA21717 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit > > What is iths blöasting that people keep > bringing up? an extra option in an RA is blasting ???? > What is the alternative: The magic AR that knows > everything ?????????????? > > [DOT] Maybe, you should just read the requirement text and the > mails that have been brought up in this context. We are not > talking about an option in RAs, we are talking about the information > that is stated in the requirement to be transfered. => I think I know what you're talking about. Or I'm trying at least. I'm giving you an example of a way to carry the information to the MN. Perhaps this is too radical?? Is carrying this information to the MN too radical ? If so, I need to hear a technical reason. All I've seen is mere speculation. I discussed this already with Govind in MPLS and after the meeting I thought it was agreed on. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:49:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07409 for ; Wed, 27 Mar 2002 11:49:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23851 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:49:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21756; Wed, 27 Mar 2002 11:43:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21716 for ; Wed, 27 Mar 2002 11:43:41 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06931 for ; Wed, 27 Mar 2002 11:43:39 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGhfkY025799 for ; Wed, 27 Mar 2002 17:43:41 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:43:39 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:43:39 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB91@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , "Hesham Soliman (ERA)" , G.Tsirtsis@flarion.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:43:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA21717 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit > > What is iths blöasting that people keep > bringing up? an extra option in an RA is blasting ???? > What is the alternative: The magic AR that knows > everything ?????????????? > > [DOT] Maybe, you should just read the requirement text and the > mails that have been brought up in this context. We are not > talking about an option in RAs, we are talking about the information > that is stated in the requirement to be transfered. => I think I know what you're talking about. Or I'm trying at least. I'm giving you an example of a way to carry the information to the MN. Perhaps this is too radical?? Is carrying this information to the MN too radical ? If so, I need to hear a technical reason. All I've seen is mere speculation. I discussed this already with Govind in MPLS and after the meeting I thought it was agreed on. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:50:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07446 for ; Wed, 27 Mar 2002 11:50:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22639; Wed, 27 Mar 2002 11:46:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22585 for ; Wed, 27 Mar 2002 11:46:12 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07216 for ; Wed, 27 Mar 2002 11:46:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGmW119522 for ; Wed, 27 Mar 2002 10:48:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:46:06 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:45:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:45:02 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVrXSgvf3IK5/GQDiODAkM9VKZIQAAFpLg To: , X-OriginalArrivalTime: 27 Mar 2002 16:45:03.0456 (UTC) FILETIME=[BE2A6600:01C1D5AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22586 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, We seem not to be communicating here. You snipped out the part of my posting where I point out that this requirement does *not* imply that the MN needs to bee flooded, and then you point out that to avoid flooding might be worthwile. The point I was trying to make here was: This requirement does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I am starting to wonder why people protest and debate this requirement so much, even when it seems to allow for all variations that people have advocated, exactly as it stands? Henrik [DOT] apart from the greetings I left the mail now unchanged. What I don't understand is, if we are so much in line that it is not required to send ALL GAAR information, why is it so controversial to state this explicitly? Apparently, the current text is controversial among a set of people to the extent that it might be interpreted that you have to send ALL GAARs+capa to the MN. Because of this controversial interpretation, the requirement should be changed in a way that it is not anymore. So if we agreed that not ALL GAAR information needs to be transferred, we would make a step forward. But I still see a disagreement even in this discussion. But if we agreed, we should put that in a wording that reflects it properly and makes the requirement non-controversial in its understanding to someone who wants to design the protocol. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:50:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07457 for ; Wed, 27 Mar 2002 11:50:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24072 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:50:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22639; Wed, 27 Mar 2002 11:46:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22585 for ; Wed, 27 Mar 2002 11:46:12 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07216 for ; Wed, 27 Mar 2002 11:46:10 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGmW119522 for ; Wed, 27 Mar 2002 10:48:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:46:06 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:45:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:45:02 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVrXSgvf3IK5/GQDiODAkM9VKZIQAAFpLg To: , X-OriginalArrivalTime: 27 Mar 2002 16:45:03.0456 (UTC) FILETIME=[BE2A6600:01C1D5AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22586 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, We seem not to be communicating here. You snipped out the part of my posting where I point out that this requirement does *not* imply that the MN needs to bee flooded, and then you point out that to avoid flooding might be worthwile. The point I was trying to make here was: This requirement does not require *all* GAAR information, it does not require *on-demand operation*, it expresses exactly what we are in a position to say about the matter now: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. I am starting to wonder why people protest and debate this requirement so much, even when it seems to allow for all variations that people have advocated, exactly as it stands? Henrik [DOT] apart from the greetings I left the mail now unchanged. What I don't understand is, if we are so much in line that it is not required to send ALL GAAR information, why is it so controversial to state this explicitly? Apparently, the current text is controversial among a set of people to the extent that it might be interpreted that you have to send ALL GAARs+capa to the MN. Because of this controversial interpretation, the requirement should be changed in a way that it is not anymore. So if we agreed that not ALL GAAR information needs to be transferred, we would make a step forward. But I still see a disagreement even in this discussion. But if we agreed, we should put that in a wording that reflects it properly and makes the requirement non-controversial in its understanding to someone who wants to design the protocol. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:52:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07639 for ; Wed, 27 Mar 2002 11:52:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22532; Wed, 27 Mar 2002 11:46:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22494 for ; Wed, 27 Mar 2002 11:45:59 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07211 for ; Wed, 27 Mar 2002 11:45:56 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGjwkY026441 for ; Wed, 27 Mar 2002 17:45:59 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:45:55 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:35:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB92@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:45:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22496 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Hemant, > No RA is not what blasting is about. What this requirement > is saying is to > send to MN a volume of data = Number of GAARs times > capability set of each. > Number of GAARs itself could be large and capability set > could be very large > too. It might contain policies, supported IP protocols, any > application > specific functionality support and this set could be extensible. => This is all based on an assumption: The scope of the GAAR discovery will scale to a very large number of GAARs. I don't think this is realistic, and after Steve's presentation I thought the entire WG agreed with this. Why are we trying to reverse this concensus? > > Sending this volume of data to MN without any regard to > whether it wants it > or not is what I call blasting. => See above. Hesham > > Hemant > > >From: "Hesham Soliman (ERA)" > >To: "'George Tsirtsis'" , > "'Hemant Chaskar'" > >, seamoby@ietf.org > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement (wa > >s: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 17:32:30 +0100 > > > >What is iths blöasting that people keep > >bringing up? an extra option in an RA is blasting ???? > >What is the alternative: The magic AR that knows > >everything ?????????????? > > > >Seriously, let's keep it simple or this whole > >protocol will start collapsing the moment > >anyone starts deploying it. Of course if deployment > >is not a concern then I'll just og back to sleep! > > > >Hesham > > > > > -----Original Message----- > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (wa s: Examples of CAR discovery) > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > GAAR IDs and all of > > > their capabilities to MN" is a good idea? If not (which I > > > hope so) then the > > > requirements document should not imply otherwise. > > > > > > George > > > > > > -----Original Message----- > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > To: seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (was: Examples of CAR discovery) > > > > > > > > > Hi Hernik: > > > > > > I did read your comment and responded as follows in my > > > earlier email. > > > Cut'n'Paste: > > > > > > ------------------------------- > > > If we honestly think that the requirement does not oblige > > > AR to blast all > > > GAAR IDs and all of their capabilities to MN, why not say > > > so clearly. Why do > > > > > > we need to hide this fact? We can come up with something > > > else, if you do not > > > > > > like on-demand extension. I think without such extension > > > the solution > > > satisfying this requirement may have serious shortcomings > > > that I described > > > in my other email to James. > > > -------------------------------- > > > > > > BR, > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > >Hemant, > > > > > > > > You apparently did not read my recent posting. > Cut'n'Paste: > > > > > > > > No, the requirement is just fine. It does not > require *all* GAAR > > > >information, it does not require *on-demand operation*, it > > > expresses > > > >exactly > > > >what we are in a position to say about the matter now: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > Why? Do you > > > >want to make things more complicated than they have to be? > > > > > > > > Henrik > > > > > > > >Hemant wrote: > > > > > > > > > > Hi James: > > > > > > > > > > There are serious shortcomings of the solution > satisfying this > > > >requirement. > > > > > They are described below. How can we finalise this > > > requirement unless it > > > > > > >is > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > For this, it might be good idea to visualise how the > > > solution satisfying > > > > > this requirement looks like and violates basic tenets > > > of engineering > > > >design, > > > > > namely efficiency. The solution satisfying this > > > requirement is obliged > > > >to > > > > > blast GAAR IDs and their capabilities on MN when AR > > > sees MN. This might > > > >be a > > > > > big chunk of data (= number of GAARs times capability > > > set of each). This > > > > > flood will occur either on active traffic connection > > > which I call case > > > >(i) > > > > > (relevant for single interface MN and two-interface MN > > > where second > > > > > interface is sleeping) or on second interface which I > > > call case (ii) > > > > > (relevant for two interface MN with both interfaces > > > awake). There are > > > > > following effects of this flood: > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > disruption in traffic > > > >over > > > > > active traffic channel. > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > receiving this flood > > > >causes > > > > > power wastage. This is because, after receiving these > > > capabilities MN > > > >either > > > > > rejects the new AR (which is worst), and even if it > > > selcects one why > > > >does it > > > > > need to receive capabilities of GAARs that do not > matter for it. > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > every MN that it > > > > > sees. Which means the same information (which could be > > > big enough) is > > > > > transmitted on downlink so many times. This takes up > > > considerable > > > >fraction > > > > > of downlink capacity. > > > > > > > > > > 4. Limit on capability definition: This requirement > > > restricts the > > > >definition > > > > > of capabilities to a very small size, otherwise all ARs > > > will only be > > > > > transmitting GAAR capabilities to different MNs all the > > > time. This means > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > statement requirement > > > >that > > > > > you proposed and who have not, we should first analyse > > > above harmful > > > >effects > > > > > before deciding either way. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: > > > > > >Examples of CAR discovery) > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > >, > > > > > > > So now you agree that the AR can hand over the list > > > of GAARs and > > > > > > > their capabilities to the MN (maybe only pass on > > > those which satisfy > > > > > > > the MN requirements, which is what CAR discovery > > > was originally > > > > > >about). > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > Let me repeat the > > > > > >requirement I would like to see (and Henrik apparently > > > agrees) so we > > > >are > > > > > >clear on this: > > > > > > > > > > > > The CAR discovery protocol MUST provide the > MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > Which first implies that the network is > taking care of CAR > > > >discovery. > > > > > > > This seems contradictory to your earlier mails > > > saying that there is > > > > > > > no basis for network based CAR discovery. So are > > > you now agreeing > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > The protocol allows > > > > > >the MN to discover the GAAR and capabilities, the MN > > > decides which one > > > > > >it wants. > > > > > >Nothing about the AR in control of anything. The MN > > > may use a variant > > > >of > > > > > >IPv6 neighbor discovery, the AR may be involved > > > somehow, but that's a > > > > > >protocol design, not a requirement, choice. The > > > requirement is clearly > > > > > >that the MN does the discovery. > > > > > > > > > > > >We now have two working group members who want this > > > reqirement worded > > > > > >just this way. Nothing about "as the MN expresses its > > > preferences" or > > > > > >"by the CAR discovery module" or anything else. And I > > > believe Hesham > > > >has > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > we include this > > > > > >requirement instead of requirement 3.4, which has the > > > AR in control? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Seamoby mailing list > > > > > >Seamoby@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print > your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:52:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07648 for ; Wed, 27 Mar 2002 11:52:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24784 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:52:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22532; Wed, 27 Mar 2002 11:46:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22494 for ; Wed, 27 Mar 2002 11:45:59 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07211 for ; Wed, 27 Mar 2002 11:45:56 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGjwkY026441 for ; Wed, 27 Mar 2002 17:45:59 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 17:45:55 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:35:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB92@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:45:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22496 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Hemant, > No RA is not what blasting is about. What this requirement > is saying is to > send to MN a volume of data = Number of GAARs times > capability set of each. > Number of GAARs itself could be large and capability set > could be very large > too. It might contain policies, supported IP protocols, any > application > specific functionality support and this set could be extensible. => This is all based on an assumption: The scope of the GAAR discovery will scale to a very large number of GAARs. I don't think this is realistic, and after Steve's presentation I thought the entire WG agreed with this. Why are we trying to reverse this concensus? > > Sending this volume of data to MN without any regard to > whether it wants it > or not is what I call blasting. => See above. Hesham > > Hemant > > >From: "Hesham Soliman (ERA)" > >To: "'George Tsirtsis'" , > "'Hemant Chaskar'" > >, seamoby@ietf.org > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement (wa > >s: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 17:32:30 +0100 > > > >What is iths blöasting that people keep > >bringing up? an extra option in an RA is blasting ???? > >What is the alternative: The magic AR that knows > >everything ?????????????? > > > >Seriously, let's keep it simple or this whole > >protocol will start collapsing the moment > >anyone starts deploying it. Of course if deployment > >is not a concern then I'll just og back to sleep! > > > >Hesham > > > > > -----Original Message----- > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (wa s: Examples of CAR discovery) > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > GAAR IDs and all of > > > their capabilities to MN" is a good idea? If not (which I > > > hope so) then the > > > requirements document should not imply otherwise. > > > > > > George > > > > > > -----Original Message----- > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > To: seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (was: Examples of CAR discovery) > > > > > > > > > Hi Hernik: > > > > > > I did read your comment and responded as follows in my > > > earlier email. > > > Cut'n'Paste: > > > > > > ------------------------------- > > > If we honestly think that the requirement does not oblige > > > AR to blast all > > > GAAR IDs and all of their capabilities to MN, why not say > > > so clearly. Why do > > > > > > we need to hide this fact? We can come up with something > > > else, if you do not > > > > > > like on-demand extension. I think without such extension > > > the solution > > > satisfying this requirement may have serious shortcomings > > > that I described > > > in my other email to James. > > > -------------------------------- > > > > > > BR, > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > >Hemant, > > > > > > > > You apparently did not read my recent posting. > Cut'n'Paste: > > > > > > > > No, the requirement is just fine. It does not > require *all* GAAR > > > >information, it does not require *on-demand operation*, it > > > expresses > > > >exactly > > > >what we are in a position to say about the matter now: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > Why? Do you > > > >want to make things more complicated than they have to be? > > > > > > > > Henrik > > > > > > > >Hemant wrote: > > > > > > > > > > Hi James: > > > > > > > > > > There are serious shortcomings of the solution > satisfying this > > > >requirement. > > > > > They are described below. How can we finalise this > > > requirement unless it > > > > > > >is > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > For this, it might be good idea to visualise how the > > > solution satisfying > > > > > this requirement looks like and violates basic tenets > > > of engineering > > > >design, > > > > > namely efficiency. The solution satisfying this > > > requirement is obliged > > > >to > > > > > blast GAAR IDs and their capabilities on MN when AR > > > sees MN. This might > > > >be a > > > > > big chunk of data (= number of GAARs times capability > > > set of each). This > > > > > flood will occur either on active traffic connection > > > which I call case > > > >(i) > > > > > (relevant for single interface MN and two-interface MN > > > where second > > > > > interface is sleeping) or on second interface which I > > > call case (ii) > > > > > (relevant for two interface MN with both interfaces > > > awake). There are > > > > > following effects of this flood: > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > disruption in traffic > > > >over > > > > > active traffic channel. > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > receiving this flood > > > >causes > > > > > power wastage. This is because, after receiving these > > > capabilities MN > > > >either > > > > > rejects the new AR (which is worst), and even if it > > > selcects one why > > > >does it > > > > > need to receive capabilities of GAARs that do not > matter for it. > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > every MN that it > > > > > sees. Which means the same information (which could be > > > big enough) is > > > > > transmitted on downlink so many times. This takes up > > > considerable > > > >fraction > > > > > of downlink capacity. > > > > > > > > > > 4. Limit on capability definition: This requirement > > > restricts the > > > >definition > > > > > of capabilities to a very small size, otherwise all ARs > > > will only be > > > > > transmitting GAAR capabilities to different MNs all the > > > time. This means > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > statement requirement > > > >that > > > > > you proposed and who have not, we should first analyse > > > above harmful > > > >effects > > > > > before deciding either way. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: > > > > > >Examples of CAR discovery) > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > >, > > > > > > > So now you agree that the AR can hand over the list > > > of GAARs and > > > > > > > their capabilities to the MN (maybe only pass on > > > those which satisfy > > > > > > > the MN requirements, which is what CAR discovery > > > was originally > > > > > >about). > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > Let me repeat the > > > > > >requirement I would like to see (and Henrik apparently > > > agrees) so we > > > >are > > > > > >clear on this: > > > > > > > > > > > > The CAR discovery protocol MUST provide the > MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > Which first implies that the network is > taking care of CAR > > > >discovery. > > > > > > > This seems contradictory to your earlier mails > > > saying that there is > > > > > > > no basis for network based CAR discovery. So are > > > you now agreeing > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > The protocol allows > > > > > >the MN to discover the GAAR and capabilities, the MN > > > decides which one > > > > > >it wants. > > > > > >Nothing about the AR in control of anything. The MN > > > may use a variant > > > >of > > > > > >IPv6 neighbor discovery, the AR may be involved > > > somehow, but that's a > > > > > >protocol design, not a requirement, choice. The > > > requirement is clearly > > > > > >that the MN does the discovery. > > > > > > > > > > > >We now have two working group members who want this > > > reqirement worded > > > > > >just this way. Nothing about "as the MN expresses its > > > preferences" or > > > > > >"by the CAR discovery module" or anything else. And I > > > believe Hesham > > > >has > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > we include this > > > > > >requirement instead of requirement 3.4, which has the > > > AR in control? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Seamoby mailing list > > > > > >Seamoby@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print > your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:52:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07669 for ; Wed, 27 Mar 2002 11:52:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22807; Wed, 27 Mar 2002 11:46:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22781 for ; Wed, 27 Mar 2002 11:46:39 -0500 (EST) Received: from hotmail.com (f31.law9.hotmail.com [64.4.9.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07226 for ; Wed, 27 Mar 2002 11:46:36 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:46:08 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:46:08 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 11:46:08 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:46:08.0901 (UTC) FILETIME=[E52C8350:01C1D5AE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >=> I haven't seen an answert to my question yet. >What would the profile say??? > [Govind] Profile could have information regarding cost preferences, Personal preferences with types of network. Types of encryption algorithms that the MN would prefer etc. >Second, profile was just an example > > to illustrate to James. There might be other ways of doing it. > > Therefore right, we will look at this when the complete protocol is > > presented each one of us. We should address this issue then and not > > now. Otherwise this discussiong goes too much into solution space. > > Precluding me from doing so right now implies that there is no way > > of doing CAR discovery in the network which is I think a > > little premature > > now. > > > >=> No. You're avoiding a question that several people >have raised by saying let's do it later. The problem >here is that people are trying to say to you >that you're making it too complicated. >So I think you need to show an example of this >profile. I'm sorry. but your answer above is >only confirming my concerns. [Govind] Hesham, my only intention was to not divert the attention of this thread into a matter which is clearly solution space. If you want we can take it offline and I can attempt to convince you. > > > > > Second, pushing capabilities down to the MN for its decision > > > > has power,bandwidth and time considerations which one may > > > > want to consider. > > > > > >=> only as much as an RA would have. Are you saying > > >RAs should not be allowed? > > > > [Govind] Ofcourse not, if you intend to do CAR discovery that way > > by all means you should be allowed to... (which again gets me to the > > mail to you which talks about this matter.. please take a look at it > > and let me know your comments). But there are performance > > tradeoffs when > > you do this, because you the RA does not contain the > > capabilities that might > > be required by the MN. The capabilities have to be sent over > > to the MN. This has to be done for each AP the MN wants to check. > > This does conserve power, bandwidth and in a low bandwidth > > environment, it does take time too depending on how many > > capabilities > >=> We've discussed this in MPLS also. You only need an >option in the RA. How frequently do you think >the capabilities change? >Depending on the link layer, the AR can also send >the RA only at the time of handover, so I don't >think the power conservation argument applies >here. [Govind] Depends on the type of capability and how much granularity you want to support in the changes. DO you have any idea of the capabilities when making such a statement? Of course if the MN gets blasted with capabilities and information about ALL GAARS and the MN has to process it does cost machine cycles. I am suprised you dont view it as an expense which can be avoided (if you choose to.. I am not saying that you should :)) > > > are to be sent. Again, I am not preventing you to do it. If the > > requirement does not allow you to do this I agree we should > > re-word it. > >=> That's all I've been asking for during the last >2 months. Can we just do it?! [Govind] I am trying my best to do that. Please excuse me as this email exchanges is taking up a lot of my time. But I apologize and I will send out a reworded requirement soon. > > > But it should allow me to do my way of implementing things > > too if I choose > > to. > >=> It's not about your way or my way, it's about >placing reasonable requirements. If enough people >are concerned, then you need to justify why >the requirements should implicitly exclude >certain scenarios. To quote Steve Deering in the meeting: >' I don't think I'm crazy if I say that there is >a bias towards network controlled handovers'. [Govind] Exactly, and MN being blasted with GAARs and capabilities without giving it an option not to want it is clearly "Crazy" too in my opinion. > > > >All I am asking is that, then we decide based on the > > protocol. There are > > performance tradeoffs to each scheme. > >=> I don't agree with the performance argument. >As I continue to say, the RA can be sent >'on demand' if your L2 allows it. >For ones that don't, BW is not a major issue. > [Govind] I don't agree with you. > > > > > >=> How does it restrict it? > > > > [Govind] The requirement as James proposed it says that CAR > > discovery > > implies that the GAARs and the capabilities MUST be sent to the MN. > > I don't think this is true and necessary. All CAR discovery must > > do (where ever it resides) MUST make available its output > > to TAR selection > > (whereever that resides). > >=> Govind, sorry, but this is 'lawyer talk'. What >do you mean 'wherever it resides' ???? >It's either in the MN or the AR, there are no >mysteries here. Be specific, each case requires >different requirements. Or put differently, >the MN case requires less requirements. > [Govind] Hesham it is clearly not lawyer talk. TAR selection can be in the network or MN or both. CAR discovery should be able to feed its output to TAR selection. Whats difficult in that? For example in the methodology you illustrated, The MN gets the capabilities and identities of the GAARs and makes its decision. Here CAR discovery and the TAR selection process lies in the MN. Regarding the requirements I will reword what is available and send it out in the next couple of days. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:52:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07678 for ; Wed, 27 Mar 2002 11:52:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24873 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:52:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22807; Wed, 27 Mar 2002 11:46:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22781 for ; Wed, 27 Mar 2002 11:46:39 -0500 (EST) Received: from hotmail.com (f31.law9.hotmail.com [64.4.9.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07226 for ; Wed, 27 Mar 2002 11:46:36 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:46:08 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:46:08 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 11:46:08 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:46:08.0901 (UTC) FILETIME=[E52C8350:01C1D5AE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >=> I haven't seen an answert to my question yet. >What would the profile say??? > [Govind] Profile could have information regarding cost preferences, Personal preferences with types of network. Types of encryption algorithms that the MN would prefer etc. >Second, profile was just an example > > to illustrate to James. There might be other ways of doing it. > > Therefore right, we will look at this when the complete protocol is > > presented each one of us. We should address this issue then and not > > now. Otherwise this discussiong goes too much into solution space. > > Precluding me from doing so right now implies that there is no way > > of doing CAR discovery in the network which is I think a > > little premature > > now. > > > >=> No. You're avoiding a question that several people >have raised by saying let's do it later. The problem >here is that people are trying to say to you >that you're making it too complicated. >So I think you need to show an example of this >profile. I'm sorry. but your answer above is >only confirming my concerns. [Govind] Hesham, my only intention was to not divert the attention of this thread into a matter which is clearly solution space. If you want we can take it offline and I can attempt to convince you. > > > > > Second, pushing capabilities down to the MN for its decision > > > > has power,bandwidth and time considerations which one may > > > > want to consider. > > > > > >=> only as much as an RA would have. Are you saying > > >RAs should not be allowed? > > > > [Govind] Ofcourse not, if you intend to do CAR discovery that way > > by all means you should be allowed to... (which again gets me to the > > mail to you which talks about this matter.. please take a look at it > > and let me know your comments). But there are performance > > tradeoffs when > > you do this, because you the RA does not contain the > > capabilities that might > > be required by the MN. The capabilities have to be sent over > > to the MN. This has to be done for each AP the MN wants to check. > > This does conserve power, bandwidth and in a low bandwidth > > environment, it does take time too depending on how many > > capabilities > >=> We've discussed this in MPLS also. You only need an >option in the RA. How frequently do you think >the capabilities change? >Depending on the link layer, the AR can also send >the RA only at the time of handover, so I don't >think the power conservation argument applies >here. [Govind] Depends on the type of capability and how much granularity you want to support in the changes. DO you have any idea of the capabilities when making such a statement? Of course if the MN gets blasted with capabilities and information about ALL GAARS and the MN has to process it does cost machine cycles. I am suprised you dont view it as an expense which can be avoided (if you choose to.. I am not saying that you should :)) > > > are to be sent. Again, I am not preventing you to do it. If the > > requirement does not allow you to do this I agree we should > > re-word it. > >=> That's all I've been asking for during the last >2 months. Can we just do it?! [Govind] I am trying my best to do that. Please excuse me as this email exchanges is taking up a lot of my time. But I apologize and I will send out a reworded requirement soon. > > > But it should allow me to do my way of implementing things > > too if I choose > > to. > >=> It's not about your way or my way, it's about >placing reasonable requirements. If enough people >are concerned, then you need to justify why >the requirements should implicitly exclude >certain scenarios. To quote Steve Deering in the meeting: >' I don't think I'm crazy if I say that there is >a bias towards network controlled handovers'. [Govind] Exactly, and MN being blasted with GAARs and capabilities without giving it an option not to want it is clearly "Crazy" too in my opinion. > > > >All I am asking is that, then we decide based on the > > protocol. There are > > performance tradeoffs to each scheme. > >=> I don't agree with the performance argument. >As I continue to say, the RA can be sent >'on demand' if your L2 allows it. >For ones that don't, BW is not a major issue. > [Govind] I don't agree with you. > > > > > >=> How does it restrict it? > > > > [Govind] The requirement as James proposed it says that CAR > > discovery > > implies that the GAARs and the capabilities MUST be sent to the MN. > > I don't think this is true and necessary. All CAR discovery must > > do (where ever it resides) MUST make available its output > > to TAR selection > > (whereever that resides). > >=> Govind, sorry, but this is 'lawyer talk'. What >do you mean 'wherever it resides' ???? >It's either in the MN or the AR, there are no >mysteries here. Be specific, each case requires >different requirements. Or put differently, >the MN case requires less requirements. > [Govind] Hesham it is clearly not lawyer talk. TAR selection can be in the network or MN or both. CAR discovery should be able to feed its output to TAR selection. Whats difficult in that? For example in the methodology you illustrated, The MN gets the capabilities and identities of the GAARs and makes its decision. Here CAR discovery and the TAR selection process lies in the MN. Regarding the requirements I will reword what is available and send it out in the next couple of days. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:53:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07753 for ; Wed, 27 Mar 2002 11:53:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23180; Wed, 27 Mar 2002 11:47:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23153 for ; Wed, 27 Mar 2002 11:47:47 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07314 for ; Wed, 27 Mar 2002 11:47:44 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA26693; Wed, 27 Mar 2002 17:44:41 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:47:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Oh, this is interesting. I advocate solving the general case, and you interpret that as another particular case. Well, anyway, I advocate solving the general case, in case that did not come across clearly. Best regards, Henrik > > Hi Henrik: > > ------------------snip--------------------------- > > >Neither. > > > >The "one access technology case" is the case where your mobile node only > >has one access technology, i.e. only one interface, and will not have more. > > > >Designing for this case in particular, instead of designing for the general > >case with multiple interfaces and technologies, will cripple our solution. > > > >Designing for the general case will permit handling this special case, > >and many many others. > > > [HC] I totally agree with your statement that we should list requirements > for general case. But that is not what is happening here. Here requirements > seem to be being formulated around a specific case of "two interface, both > awake, no power constraint" case, without considering their impact on other > cases. > > BR, > Hemant > > > > > > Regards, > > Henrik > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:53:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07764 for ; Wed, 27 Mar 2002 11:53:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25106 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:53:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23180; Wed, 27 Mar 2002 11:47:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23153 for ; Wed, 27 Mar 2002 11:47:47 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07314 for ; Wed, 27 Mar 2002 11:47:44 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA26693; Wed, 27 Mar 2002 17:44:41 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:47:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Oh, this is interesting. I advocate solving the general case, and you interpret that as another particular case. Well, anyway, I advocate solving the general case, in case that did not come across clearly. Best regards, Henrik > > Hi Henrik: > > ------------------snip--------------------------- > > >Neither. > > > >The "one access technology case" is the case where your mobile node only > >has one access technology, i.e. only one interface, and will not have more. > > > >Designing for this case in particular, instead of designing for the general > >case with multiple interfaces and technologies, will cripple our solution. > > > >Designing for the general case will permit handling this special case, > >and many many others. > > > [HC] I totally agree with your statement that we should list requirements > for general case. But that is not what is happening here. Here requirements > seem to be being formulated around a specific case of "two interface, both > awake, no power constraint" case, without considering their impact on other > cases. > > BR, > Hemant > > > > > > Regards, > > Henrik > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:54:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07788 for ; Wed, 27 Mar 2002 11:54:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23376; Wed, 27 Mar 2002 11:48:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23343 for ; Wed, 27 Mar 2002 11:48:22 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07342 for ; Wed, 27 Mar 2002 11:48:20 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGmMoq022338 for ; Wed, 27 Mar 2002 17:48:22 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:48:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:38:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB93@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:48:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > The "extra option" on the RA may or may not be a problem. > We will only know > if this is a problem AFTER we know what "capabilities" mean > i.e.: how much > data can be in there for the list of GAARs. That does make > me nervous, > doesn't you? => I agree, but only if you assume that GAAR discovery will cover a very large number of GAARs. This is where I think that the assumptions are flawed. If we limit the AR-based discovery to one operator's network and one access tech, then we are most likely to end up with one or two GAARs. Right ? > > The problem of course starts from the fact that one AR is > supposed to > provide this list of GAARs + capabilities to the MN (which > could be a lot of > info). In a MN centric approach the MN knows which the > GAARs are and gets > their capabilities directly from them...much better IMO. => Can't agree more. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:54:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07796 for ; Wed, 27 Mar 2002 11:54:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25274 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:54:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23376; Wed, 27 Mar 2002 11:48:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23343 for ; Wed, 27 Mar 2002 11:48:22 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07342 for ; Wed, 27 Mar 2002 11:48:20 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGmMoq022338 for ; Wed, 27 Mar 2002 17:48:22 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:48:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:38:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB93@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:48:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > The "extra option" on the RA may or may not be a problem. > We will only know > if this is a problem AFTER we know what "capabilities" mean > i.e.: how much > data can be in there for the list of GAARs. That does make > me nervous, > doesn't you? => I agree, but only if you assume that GAAR discovery will cover a very large number of GAARs. This is where I think that the assumptions are flawed. If we limit the AR-based discovery to one operator's network and one access tech, then we are most likely to end up with one or two GAARs. Right ? > > The problem of course starts from the fact that one AR is > supposed to > provide this list of GAARs + capabilities to the MN (which > could be a lot of > info). In a MN centric approach the MN knows which the > GAARs are and gets > their capabilities directly from them...much better IMO. => Can't agree more. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:55:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07926 for ; Wed, 27 Mar 2002 11:55:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23938; Wed, 27 Mar 2002 11:50:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23908 for ; Wed, 27 Mar 2002 11:50:04 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07430 for ; Wed, 27 Mar 2002 11:49:57 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGqP120110 for ; Wed, 27 Mar 2002 10:52:25 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:49:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:48:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:48:51 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Thread-Index: AcHVrpcf6SrseifgQKmy3UzRU2QGogAAGdmQ To: , , , X-OriginalArrivalTime: 27 Mar 2002 16:48:52.0243 (UTC) FILETIME=[46888630:01C1D5AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23909 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, > > What is iths blöasting that people keep > bringing up? an extra option in an RA is blasting ???? > What is the alternative: The magic AR that knows > everything ?????????????? > > [DOT] Maybe, you should just read the requirement text and the > mails that have been brought up in this context. We are not > talking about an option in RAs, we are talking about the information > that is stated in the requirement to be transfered. => I think I know what you're talking about. Or I'm trying at least. I'm giving you an example of a way to carry the information to the MN. Perhaps this is too radical?? Is carrying this information to the MN too radical ? If so, I need to hear a technical reason. All I've seen is mere speculation. [DOT] It is not HOW it is transferred, it is WHAT and HOW MUCH. Since we don't yet how much it is we're talking about here (independent of how you actually transport it), concerns have been expressed to provide this unknown amount of data to the MN, even if it is not necessary. I do think that this is a technical reason. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:55:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07936 for ; Wed, 27 Mar 2002 11:55:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25756 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:55:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23938; Wed, 27 Mar 2002 11:50:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23908 for ; Wed, 27 Mar 2002 11:50:04 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07430 for ; Wed, 27 Mar 2002 11:49:57 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGqP120110 for ; Wed, 27 Mar 2002 10:52:25 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:49:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:48:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:48:51 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Thread-Index: AcHVrpcf6SrseifgQKmy3UzRU2QGogAAGdmQ To: , , , X-OriginalArrivalTime: 27 Mar 2002 16:48:52.0243 (UTC) FILETIME=[46888630:01C1D5AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23909 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, > > What is iths blöasting that people keep > bringing up? an extra option in an RA is blasting ???? > What is the alternative: The magic AR that knows > everything ?????????????? > > [DOT] Maybe, you should just read the requirement text and the > mails that have been brought up in this context. We are not > talking about an option in RAs, we are talking about the information > that is stated in the requirement to be transfered. => I think I know what you're talking about. Or I'm trying at least. I'm giving you an example of a way to carry the information to the MN. Perhaps this is too radical?? Is carrying this information to the MN too radical ? If so, I need to hear a technical reason. All I've seen is mere speculation. [DOT] It is not HOW it is transferred, it is WHAT and HOW MUCH. Since we don't yet how much it is we're talking about here (independent of how you actually transport it), concerns have been expressed to provide this unknown amount of data to the MN, even if it is not necessary. I do think that this is a technical reason. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:58:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08144 for ; Wed, 27 Mar 2002 11:58:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24812; Wed, 27 Mar 2002 11:52:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24765 for ; Wed, 27 Mar 2002 11:52:39 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07636 for ; Wed, 27 Mar 2002 11:52:37 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGqdkY028442 for ; Wed, 27 Mar 2002 17:52:39 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:52:38 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:42:31 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB94@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:52:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, I won't answer all the mails below, since you ended it with: > >=> Govind, sorry, but this is 'lawyer talk'. What > >do you mean 'wherever it resides' ???? > >It's either in the MN or the AR, there are no > >mysteries here. Be specific, each case requires > >different requirements. Or put differently, > >the MN case requires less requirements. > > > > [Govind] Hesham it is clearly not lawyer talk. TAR selection can > be in the network or MN or both. CAR discovery should be able to > feed its output to TAR selection. Whats difficult in that? > > For example in the methodology you illustrated, > The MN gets the capabilities and identities of the GAARs > and makes its > decision. Here CAR discovery and the TAR selection process > lies in the > MN. Regarding the requirements I will reword what is > available and send > it out in the next couple of days. => I'll let you come up with the new text, but my curent concerns on the requirement is: - The scope of AR-based CAR should be limited to one operator's domain and one access technology. - The MN-based one is naturally limited by the number of ARs it can hear. FWIW, I don't think that passing preferences to the AR is a good idea or will ever scale. Hesham > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:58:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08167 for ; Wed, 27 Mar 2002 11:58:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26706 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:58:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24812; Wed, 27 Mar 2002 11:52:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24765 for ; Wed, 27 Mar 2002 11:52:39 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07636 for ; Wed, 27 Mar 2002 11:52:37 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGqdkY028442 for ; Wed, 27 Mar 2002 17:52:39 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:52:38 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:42:31 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB94@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:52:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, I won't answer all the mails below, since you ended it with: > >=> Govind, sorry, but this is 'lawyer talk'. What > >do you mean 'wherever it resides' ???? > >It's either in the MN or the AR, there are no > >mysteries here. Be specific, each case requires > >different requirements. Or put differently, > >the MN case requires less requirements. > > > > [Govind] Hesham it is clearly not lawyer talk. TAR selection can > be in the network or MN or both. CAR discovery should be able to > feed its output to TAR selection. Whats difficult in that? > > For example in the methodology you illustrated, > The MN gets the capabilities and identities of the GAARs > and makes its > decision. Here CAR discovery and the TAR selection process > lies in the > MN. Regarding the requirements I will reword what is > available and send > it out in the next couple of days. => I'll let you come up with the new text, but my curent concerns on the requirement is: - The scope of AR-based CAR should be limited to one operator's domain and one access technology. - The MN-based one is naturally limited by the number of ARs it can hear. FWIW, I don't think that passing preferences to the AR is a good idea or will ever scale. Hesham > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:59:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08236 for ; Wed, 27 Mar 2002 11:59:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25450; Wed, 27 Mar 2002 11:54:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25335 for ; Wed, 27 Mar 2002 11:54:23 -0500 (EST) Received: from hotmail.com (f104.law9.hotmail.com [64.4.9.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07818 for ; Wed, 27 Mar 2002 11:54:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:53:53 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:53:53 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 11:53:53 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:53:53.0789 (UTC) FILETIME=[FA44CAD0:01C1D5AF] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham, Without knowing how many different GAARs are available (see Henriks mail about N interfaces) without knowing what the capabilities are I don't understand how you have come to the conclusion that the pushing the GAARs (all of them + their capabilities) to the MN is not blasting. All we ask is the MN has an option to say no to this. Aren't you removing the MN's right not to want to proces this kind of information by saying that GAARs and their capabilities MUST be sent over to the MN? Govind. > >What is iths blöasting that people keep >bringing up? an extra option in an RA is blasting ???? >What is the alternative: The magic AR that knows >everything ?????????????? > >Seriously, let's keep it simple or this whole >protocol will start collapsing the moment >anyone starts deploying it. Of course if deployment >is not a concern then I'll just og back to sleep! > >Hesham > > > -----Original Message----- > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > Sent: Wednesday, March 27, 2002 5:21 PM > > To: 'Hemant Chaskar'; seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (wa s: Examples of CAR discovery) > > > > > > So, is there anyone that seriously thinks that "blasting > > GAAR IDs and all of > > their capabilities to MN" is a good idea? If not (which I > > hope so) then the > > requirements document should not imply otherwise. > > > > George > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Wednesday, March 27, 2002 4:08 PM > > To: seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (was: Examples of CAR discovery) > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my > > earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige > > AR to blast all > > GAAR IDs and all of their capabilities to MN, why not say > > so clearly. Why do > > > > we need to hide this fact? We can come up with something > > else, if you do not > > > > like on-demand extension. I think without such extension > > the solution > > satisfying this requirement may have serious shortcomings > > that I described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it > > expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? > > Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this > > requirement unless it > > > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the > > solution satisfying > > > > this requirement looks like and violates basic tenets > > of engineering > > >design, > > > > namely efficiency. The solution satisfying this > > requirement is obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR > > sees MN. This might > > >be a > > > > big chunk of data (= number of GAARs times capability > > set of each). This > > > > flood will occur either on active traffic connection > > which I call case > > >(i) > > > > (relevant for single interface MN and two-interface MN > > where second > > > > interface is sleeping) or on second interface which I > > call case (ii) > > > > (relevant for two interface MN with both interfaces > > awake). There are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > disruption in traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > receiving this flood > > >causes > > > > power wastage. This is because, after receiving these > > capabilities MN > > >either > > > > rejects the new AR (which is worst), and even if it > > selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > every MN that it > > > > sees. Which means the same information (which could be > > big enough) is > > > > transmitted on downlink so many times. This takes up > > considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement > > restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs > > will only be > > > > transmitting GAAR capabilities to different MNs all the > > time. This means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one > > statement requirement > > >that > > > > you proposed and who have not, we should first analyse > > above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list > > of GAARs and > > > > > > their capabilities to the MN (maybe only pass on > > those which satisfy > > > > > > the MN requirements, which is what CAR discovery > > was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > Let me repeat the > > > > >requirement I would like to see (and Henrik apparently > > agrees) so we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails > > saying that there is > > > > > > no basis for network based CAR discovery. So are > > you now agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > The protocol allows > > > > >the MN to discover the GAAR and capabilities, the MN > > decides which one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN > > may use a variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved > > somehow, but that's a > > > > >protocol design, not a requirement, choice. The > > requirement is clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this > > reqirement worded > > > > >just this way. Nothing about "as the MN expresses its > > preferences" or > > > > >"by the CAR discovery module" or anything else. And I > > believe Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should > > we include this > > > > >requirement instead of requirement 3.4, which has the > > AR in control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:59:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08247 for ; Wed, 27 Mar 2002 11:59:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26915 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:59:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25450; Wed, 27 Mar 2002 11:54:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25335 for ; Wed, 27 Mar 2002 11:54:23 -0500 (EST) Received: from hotmail.com (f104.law9.hotmail.com [64.4.9.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07818 for ; Wed, 27 Mar 2002 11:54:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 08:53:53 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 16:53:53 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 11:53:53 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 16:53:53.0789 (UTC) FILETIME=[FA44CAD0:01C1D5AF] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham, Without knowing how many different GAARs are available (see Henriks mail about N interfaces) without knowing what the capabilities are I don't understand how you have come to the conclusion that the pushing the GAARs (all of them + their capabilities) to the MN is not blasting. All we ask is the MN has an option to say no to this. Aren't you removing the MN's right not to want to proces this kind of information by saying that GAARs and their capabilities MUST be sent over to the MN? Govind. > >What is iths blöasting that people keep >bringing up? an extra option in an RA is blasting ???? >What is the alternative: The magic AR that knows >everything ?????????????? > >Seriously, let's keep it simple or this whole >protocol will start collapsing the moment >anyone starts deploying it. Of course if deployment >is not a concern then I'll just og back to sleep! > >Hesham > > > -----Original Message----- > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > Sent: Wednesday, March 27, 2002 5:21 PM > > To: 'Hemant Chaskar'; seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (wa s: Examples of CAR discovery) > > > > > > So, is there anyone that seriously thinks that "blasting > > GAAR IDs and all of > > their capabilities to MN" is a good idea? If not (which I > > hope so) then the > > requirements document should not imply otherwise. > > > > George > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Wednesday, March 27, 2002 4:08 PM > > To: seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (was: Examples of CAR discovery) > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my > > earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige > > AR to blast all > > GAAR IDs and all of their capabilities to MN, why not say > > so clearly. Why do > > > > we need to hide this fact? We can come up with something > > else, if you do not > > > > like on-demand extension. I think without such extension > > the solution > > satisfying this requirement may have serious shortcomings > > that I described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it > > expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? > > Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this > > requirement unless it > > > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the > > solution satisfying > > > > this requirement looks like and violates basic tenets > > of engineering > > >design, > > > > namely efficiency. The solution satisfying this > > requirement is obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR > > sees MN. This might > > >be a > > > > big chunk of data (= number of GAARs times capability > > set of each). This > > > > flood will occur either on active traffic connection > > which I call case > > >(i) > > > > (relevant for single interface MN and two-interface MN > > where second > > > > interface is sleeping) or on second interface which I > > call case (ii) > > > > (relevant for two interface MN with both interfaces > > awake). There are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > disruption in traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > receiving this flood > > >causes > > > > power wastage. This is because, after receiving these > > capabilities MN > > >either > > > > rejects the new AR (which is worst), and even if it > > selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > every MN that it > > > > sees. Which means the same information (which could be > > big enough) is > > > > transmitted on downlink so many times. This takes up > > considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement > > restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs > > will only be > > > > transmitting GAAR capabilities to different MNs all the > > time. This means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one > > statement requirement > > >that > > > > you proposed and who have not, we should first analyse > > above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list > > of GAARs and > > > > > > their capabilities to the MN (maybe only pass on > > those which satisfy > > > > > > the MN requirements, which is what CAR discovery > > was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > Let me repeat the > > > > >requirement I would like to see (and Henrik apparently > > agrees) so we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails > > saying that there is > > > > > > no basis for network based CAR discovery. So are > > you now agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > The protocol allows > > > > >the MN to discover the GAAR and capabilities, the MN > > decides which one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN > > may use a variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved > > somehow, but that's a > > > > >protocol design, not a requirement, choice. The > > requirement is clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this > > reqirement worded > > > > >just this way. Nothing about "as the MN expresses its > > preferences" or > > > > >"by the CAR discovery module" or anything else. And I > > believe Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should > > we include this > > > > >requirement instead of requirement 3.4, which has the > > AR in control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 11:59:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08264 for ; Wed, 27 Mar 2002 11:59:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25058; Wed, 27 Mar 2002 11:53:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25023 for ; Wed, 27 Mar 2002 11:53:31 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07750 for ; Wed, 27 Mar 2002 11:53:29 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGtu120553 for ; Wed, 27 Mar 2002 10:55:56 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:53:30 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:52:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:52:38 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVrq8CWUmvx0CwR9CPrDVMPt88VQAAKc8w To: , , X-OriginalArrivalTime: 27 Mar 2002 16:52:39.0337 (UTC) FILETIME=[CDE45190:01C1D5AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA25024 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hemant, The requirement as first proposed does not imply that *all* GAAR information must be sent. The requirement as first proposed also does not require that a filtering mechanism must be part of the solution. The revised requirement requires a filtering mechanism. I do not believe we know that this is the right way to go yet. Therefore I do not believe that it is good to add this restriction. [DOT] I don't understand why it makes filtering mandatory. If the final solution requires to send ALL information to the MN, the filtering ("as required") is simply not present, since all data is required (which makes filtering unnecessary). But if we figure out that sending all the stuff to the MN shouldn't be done, the "as required" option avoids a mandatory transfer of this data. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 11:59:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08274 for ; Wed, 27 Mar 2002 11:59:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26975 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:59:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25058; Wed, 27 Mar 2002 11:53:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25023 for ; Wed, 27 Mar 2002 11:53:31 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07750 for ; Wed, 27 Mar 2002 11:53:29 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RGtu120553 for ; Wed, 27 Mar 2002 10:55:56 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:53:30 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:52:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:52:38 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVrq8CWUmvx0CwR9CPrDVMPt88VQAAKc8w To: , , X-OriginalArrivalTime: 27 Mar 2002 16:52:39.0337 (UTC) FILETIME=[CDE45190:01C1D5AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA25024 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hemant, The requirement as first proposed does not imply that *all* GAAR information must be sent. The requirement as first proposed also does not require that a filtering mechanism must be part of the solution. The revised requirement requires a filtering mechanism. I do not believe we know that this is the right way to go yet. Therefore I do not believe that it is good to add this restriction. [DOT] I don't understand why it makes filtering mandatory. If the final solution requires to send ALL information to the MN, the filtering ("as required") is simply not present, since all data is required (which makes filtering unnecessary). But if we figure out that sending all the stuff to the MN shouldn't be done, the "as required" option avoids a mandatory transfer of this data. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:00:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08327 for ; Wed, 27 Mar 2002 12:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25442; Wed, 27 Mar 2002 11:54:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25337 for ; Wed, 27 Mar 2002 11:54:23 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07817 for ; Wed, 27 Mar 2002 11:54:20 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA26872; Wed, 27 Mar 2002 17:51:22 +0100 From: "Henrik Levkowetz" To: , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:54:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, Thank you. The point is rather that the revised form of this requirement imposed another restriction, namely that a filtering mechanism would have to be part of the solution. I would like to avoid that requirement for now. The solution when somebody misapprehends a well formulated requirement is NOT to change the requirement into something that has unwanted side effects, but rather to clear up the misapprehension itself, I think. Regards, Henrik > > Henrik, > > > We seem not to be communicating here. You snipped out the part of > my posting where I point out that this requirement does *not* imply that > the MN needs to bee flooded, and then you point out that to avoid flooding > might be worthwile. > > The point I was trying to make here was: > This requirement does not require *all* GAAR > information, it does not require *on-demand operation*, it expresses exactly > what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > I am starting to wonder why people protest and debate this requirement > so much, even when it seems to allow for all variations that people have > advocated, exactly as it stands? > > Henrik > > [DOT] apart from the greetings I left the mail now unchanged. What I don't understand is, > if we are so much in line that it is not required to send ALL GAAR information, why is it > so controversial to state this explicitly? Apparently, the current text is controversial among > a set of people to the extent that it might be interpreted that you have to send ALL GAARs+capa > to the MN. Because of this controversial interpretation, the requirement should be changed in a way > that it is not anymore. So if we agreed that not ALL GAAR information needs to be transferred, we would > make a step forward. But I still see a disagreement even in this discussion. But if we agreed, > we should put that in a wording that reflects it properly and makes the requirement non-controversial > in its understanding to someone who wants to design the protocol. > > Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:00:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08334 for ; Wed, 27 Mar 2002 12:00:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27146 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:00:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25442; Wed, 27 Mar 2002 11:54:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25337 for ; Wed, 27 Mar 2002 11:54:23 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07817 for ; Wed, 27 Mar 2002 11:54:20 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA26872; Wed, 27 Mar 2002 17:51:22 +0100 From: "Henrik Levkowetz" To: , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:54:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, Thank you. The point is rather that the revised form of this requirement imposed another restriction, namely that a filtering mechanism would have to be part of the solution. I would like to avoid that requirement for now. The solution when somebody misapprehends a well formulated requirement is NOT to change the requirement into something that has unwanted side effects, but rather to clear up the misapprehension itself, I think. Regards, Henrik > > Henrik, > > > We seem not to be communicating here. You snipped out the part of > my posting where I point out that this requirement does *not* imply that > the MN needs to bee flooded, and then you point out that to avoid flooding > might be worthwile. > > The point I was trying to make here was: > This requirement does not require *all* GAAR > information, it does not require *on-demand operation*, it expresses exactly > what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > I am starting to wonder why people protest and debate this requirement > so much, even when it seems to allow for all variations that people have > advocated, exactly as it stands? > > Henrik > > [DOT] apart from the greetings I left the mail now unchanged. What I don't understand is, > if we are so much in line that it is not required to send ALL GAAR information, why is it > so controversial to state this explicitly? Apparently, the current text is controversial among > a set of people to the extent that it might be interpreted that you have to send ALL GAARs+capa > to the MN. Because of this controversial interpretation, the requirement should be changed in a way > that it is not anymore. So if we agreed that not ALL GAAR information needs to be transferred, we would > make a step forward. But I still see a disagreement even in this discussion. But if we agreed, > we should put that in a wording that reflects it properly and makes the requirement non-controversial > in its understanding to someone who wants to design the protocol. > > Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:02:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08467 for ; Wed, 27 Mar 2002 12:02:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26053; Wed, 27 Mar 2002 11:56:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26011 for ; Wed, 27 Mar 2002 11:56:19 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07995 for ; Wed, 27 Mar 2002 11:56:16 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGuIkY029532 for ; Wed, 27 Mar 2002 17:56:18 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:56:04 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:45:57 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB95@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 17:55:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA26012 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit > Without knowing how many different GAARs are available (see > Henriks mail > about N interfaces) without knowing what the capabilities > are I don't > understand how you have come to the conclusion that the pushing > the GAARs (all of them + their capabilities) to the MN is > not blasting. => Because I'm narrowing the scope of AR-based CAR to a couple of neighbouring routers within the same domain and the access technology. This is as far as it should go IMHO. That is, if you expect it to be seriously deployed. Hesham > All we ask is the MN has an option to say no to this. > Aren't you removing > the MN's right not to want to proces this kind of information > by saying that GAARs and their capabilities MUST be sent > over to the MN? > > Govind. > > > >What is iths blöasting that people keep > >bringing up? an extra option in an RA is blasting ???? > >What is the alternative: The magic AR that knows > >everything ?????????????? > > > >Seriously, let's keep it simple or this whole > >protocol will start collapsing the moment > >anyone starts deploying it. Of course if deployment > >is not a concern then I'll just og back to sleep! > > > >Hesham > > > > > -----Original Message----- > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (wa s: Examples of CAR discovery) > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > GAAR IDs and all of > > > their capabilities to MN" is a good idea? If not (which I > > > hope so) then the > > > requirements document should not imply otherwise. > > > > > > George > > > > > > -----Original Message----- > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > To: seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (was: Examples of CAR discovery) > > > > > > > > > Hi Hernik: > > > > > > I did read your comment and responded as follows in my > > > earlier email. > > > Cut'n'Paste: > > > > > > ------------------------------- > > > If we honestly think that the requirement does not oblige > > > AR to blast all > > > GAAR IDs and all of their capabilities to MN, why not say > > > so clearly. Why do > > > > > > we need to hide this fact? We can come up with something > > > else, if you do not > > > > > > like on-demand extension. I think without such extension > > > the solution > > > satisfying this requirement may have serious shortcomings > > > that I described > > > in my other email to James. > > > -------------------------------- > > > > > > BR, > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > >Hemant, > > > > > > > > You apparently did not read my recent posting. > Cut'n'Paste: > > > > > > > > No, the requirement is just fine. It does not > require *all* GAAR > > > >information, it does not require *on-demand operation*, it > > > expresses > > > >exactly > > > >what we are in a position to say about the matter now: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > Why? Do you > > > >want to make things more complicated than they have to be? > > > > > > > > Henrik > > > > > > > >Hemant wrote: > > > > > > > > > > Hi James: > > > > > > > > > > There are serious shortcomings of the solution > satisfying this > > > >requirement. > > > > > They are described below. How can we finalise this > > > requirement unless it > > > > > > >is > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > For this, it might be good idea to visualise how the > > > solution satisfying > > > > > this requirement looks like and violates basic tenets > > > of engineering > > > >design, > > > > > namely efficiency. The solution satisfying this > > > requirement is obliged > > > >to > > > > > blast GAAR IDs and their capabilities on MN when AR > > > sees MN. This might > > > >be a > > > > > big chunk of data (= number of GAARs times capability > > > set of each). This > > > > > flood will occur either on active traffic connection > > > which I call case > > > >(i) > > > > > (relevant for single interface MN and two-interface MN > > > where second > > > > > interface is sleeping) or on second interface which I > > > call case (ii) > > > > > (relevant for two interface MN with both interfaces > > > awake). There are > > > > > following effects of this flood: > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > disruption in traffic > > > >over > > > > > active traffic channel. > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > receiving this flood > > > >causes > > > > > power wastage. This is because, after receiving these > > > capabilities MN > > > >either > > > > > rejects the new AR (which is worst), and even if it > > > selcects one why > > > >does it > > > > > need to receive capabilities of GAARs that do not > matter for it. > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > every MN that it > > > > > sees. Which means the same information (which could be > > > big enough) is > > > > > transmitted on downlink so many times. This takes up > > > considerable > > > >fraction > > > > > of downlink capacity. > > > > > > > > > > 4. Limit on capability definition: This requirement > > > restricts the > > > >definition > > > > > of capabilities to a very small size, otherwise all ARs > > > will only be > > > > > transmitting GAAR capabilities to different MNs all the > > > time. This means > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > statement requirement > > > >that > > > > > you proposed and who have not, we should first analyse > > > above harmful > > > >effects > > > > > before deciding either way. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: > > > > > >Examples of CAR discovery) > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > >, > > > > > > > So now you agree that the AR can hand over the list > > > of GAARs and > > > > > > > their capabilities to the MN (maybe only pass on > > > those which satisfy > > > > > > > the MN requirements, which is what CAR discovery > > > was originally > > > > > >about). > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > Let me repeat the > > > > > >requirement I would like to see (and Henrik apparently > > > agrees) so we > > > >are > > > > > >clear on this: > > > > > > > > > > > > The CAR discovery protocol MUST provide the > MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > Which first implies that the network is > taking care of CAR > > > >discovery. > > > > > > > This seems contradictory to your earlier mails > > > saying that there is > > > > > > > no basis for network based CAR discovery. So are > > > you now agreeing > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > The protocol allows > > > > > >the MN to discover the GAAR and capabilities, the MN > > > decides which one > > > > > >it wants. > > > > > >Nothing about the AR in control of anything. The MN > > > may use a variant > > > >of > > > > > >IPv6 neighbor discovery, the AR may be involved > > > somehow, but that's a > > > > > >protocol design, not a requirement, choice. The > > > requirement is clearly > > > > > >that the MN does the discovery. > > > > > > > > > > > >We now have two working group members who want this > > > reqirement worded > > > > > >just this way. Nothing about "as the MN expresses its > > > preferences" or > > > > > >"by the CAR discovery module" or anything else. And I > > > believe Hesham > > > >has > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > we include this > > > > > >requirement instead of requirement 3.4, which has the > > > AR in control? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Seamoby mailing list > > > > > >Seamoby@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print > your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:02:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08478 for ; Wed, 27 Mar 2002 12:02:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27699 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:02:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26053; Wed, 27 Mar 2002 11:56:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26011 for ; Wed, 27 Mar 2002 11:56:19 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07995 for ; Wed, 27 Mar 2002 11:56:16 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RGuIkY029532 for ; Wed, 27 Mar 2002 17:56:18 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 17:56:04 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 17:45:57 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB95@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 17:55:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA26012 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit > Without knowing how many different GAARs are available (see > Henriks mail > about N interfaces) without knowing what the capabilities > are I don't > understand how you have come to the conclusion that the pushing > the GAARs (all of them + their capabilities) to the MN is > not blasting. => Because I'm narrowing the scope of AR-based CAR to a couple of neighbouring routers within the same domain and the access technology. This is as far as it should go IMHO. That is, if you expect it to be seriously deployed. Hesham > All we ask is the MN has an option to say no to this. > Aren't you removing > the MN's right not to want to proces this kind of information > by saying that GAARs and their capabilities MUST be sent > over to the MN? > > Govind. > > > >What is iths blöasting that people keep > >bringing up? an extra option in an RA is blasting ???? > >What is the alternative: The magic AR that knows > >everything ?????????????? > > > >Seriously, let's keep it simple or this whole > >protocol will start collapsing the moment > >anyone starts deploying it. Of course if deployment > >is not a concern then I'll just og back to sleep! > > > >Hesham > > > > > -----Original Message----- > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (wa s: Examples of CAR discovery) > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > GAAR IDs and all of > > > their capabilities to MN" is a good idea? If not (which I > > > hope so) then the > > > requirements document should not imply otherwise. > > > > > > George > > > > > > -----Original Message----- > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > To: seamoby@ietf.org > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > (was: Examples of CAR discovery) > > > > > > > > > Hi Hernik: > > > > > > I did read your comment and responded as follows in my > > > earlier email. > > > Cut'n'Paste: > > > > > > ------------------------------- > > > If we honestly think that the requirement does not oblige > > > AR to blast all > > > GAAR IDs and all of their capabilities to MN, why not say > > > so clearly. Why do > > > > > > we need to hide this fact? We can come up with something > > > else, if you do not > > > > > > like on-demand extension. I think without such extension > > > the solution > > > satisfying this requirement may have serious shortcomings > > > that I described > > > in my other email to James. > > > -------------------------------- > > > > > > BR, > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > >Hemant, > > > > > > > > You apparently did not read my recent posting. > Cut'n'Paste: > > > > > > > > No, the requirement is just fine. It does not > require *all* GAAR > > > >information, it does not require *on-demand operation*, it > > > expresses > > > >exactly > > > >what we are in a position to say about the matter now: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > Why? Do you > > > >want to make things more complicated than they have to be? > > > > > > > > Henrik > > > > > > > >Hemant wrote: > > > > > > > > > > Hi James: > > > > > > > > > > There are serious shortcomings of the solution > satisfying this > > > >requirement. > > > > > They are described below. How can we finalise this > > > requirement unless it > > > > > > >is > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > For this, it might be good idea to visualise how the > > > solution satisfying > > > > > this requirement looks like and violates basic tenets > > > of engineering > > > >design, > > > > > namely efficiency. The solution satisfying this > > > requirement is obliged > > > >to > > > > > blast GAAR IDs and their capabilities on MN when AR > > > sees MN. This might > > > >be a > > > > > big chunk of data (= number of GAARs times capability > > > set of each). This > > > > > flood will occur either on active traffic connection > > > which I call case > > > >(i) > > > > > (relevant for single interface MN and two-interface MN > > > where second > > > > > interface is sleeping) or on second interface which I > > > call case (ii) > > > > > (relevant for two interface MN with both interfaces > > > awake). There are > > > > > following effects of this flood: > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > disruption in traffic > > > >over > > > > > active traffic channel. > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > receiving this flood > > > >causes > > > > > power wastage. This is because, after receiving these > > > capabilities MN > > > >either > > > > > rejects the new AR (which is worst), and even if it > > > selcects one why > > > >does it > > > > > need to receive capabilities of GAARs that do not > matter for it. > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > every MN that it > > > > > sees. Which means the same information (which could be > > > big enough) is > > > > > transmitted on downlink so many times. This takes up > > > considerable > > > >fraction > > > > > of downlink capacity. > > > > > > > > > > 4. Limit on capability definition: This requirement > > > restricts the > > > >definition > > > > > of capabilities to a very small size, otherwise all ARs > > > will only be > > > > > transmitting GAAR capabilities to different MNs all the > > > time. This means > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > statement requirement > > > >that > > > > > you proposed and who have not, we should first analyse > > > above harmful > > > >effects > > > > > before deciding either way. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > Requirement > > > >(was: > > > > > >Examples of CAR discovery) > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > >, > > > > > > > So now you agree that the AR can hand over the list > > > of GAARs and > > > > > > > their capabilities to the MN (maybe only pass on > > > those which satisfy > > > > > > > the MN requirements, which is what CAR discovery > > > was originally > > > > > >about). > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > Let me repeat the > > > > > >requirement I would like to see (and Henrik apparently > > > agrees) so we > > > >are > > > > > >clear on this: > > > > > > > > > > > > The CAR discovery protocol MUST provide the > MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > Which first implies that the network is > taking care of CAR > > > >discovery. > > > > > > > This seems contradictory to your earlier mails > > > saying that there is > > > > > > > no basis for network based CAR discovery. So are > > > you now agreeing > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > The protocol allows > > > > > >the MN to discover the GAAR and capabilities, the MN > > > decides which one > > > > > >it wants. > > > > > >Nothing about the AR in control of anything. The MN > > > may use a variant > > > >of > > > > > >IPv6 neighbor discovery, the AR may be involved > > > somehow, but that's a > > > > > >protocol design, not a requirement, choice. The > > > requirement is clearly > > > > > >that the MN does the discovery. > > > > > > > > > > > >We now have two working group members who want this > > > reqirement worded > > > > > >just this way. Nothing about "as the MN expresses its > > > preferences" or > > > > > >"by the CAR discovery module" or anything else. And I > > > believe Hesham > > > >has > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > we include this > > > > > >requirement instead of requirement 3.4, which has the > > > AR in control? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Seamoby mailing list > > > > > >Seamoby@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print > your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:03:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08527 for ; Wed, 27 Mar 2002 12:03:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26597; Wed, 27 Mar 2002 11:58:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26550 for ; Wed, 27 Mar 2002 11:58:10 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08126 for ; Wed, 27 Mar 2002 11:58:08 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 11:57:40 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5B@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:57:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 4:48 PM To: 'George Tsirtsis'; Hesham Soliman (ERA); 'Hemant Chaskar'; seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > The "extra option" on the RA may or may not be a problem. > We will only know > if this is a problem AFTER we know what "capabilities" mean > i.e.: how much > data can be in there for the list of GAARs. That does make > me nervous, > doesn't you? => I agree, but only if you assume that GAAR discovery will cover a very large number of GAARs. This is where I think that the assumptions are flawed. If we limit the AR-based discovery to one operator's network and one access tech, then we are most likely to end up with one or two GAARs. Right ? GT> In cellular deployment each AR will have up to 6 GAARs assuming ARs on each BS/AP. What you say above is that the protocol we are talking about is clever enough to know between which 2 or 3 ARs the MN is currently located. In the "anticipated" mode CAR discovery takes place prior to handoff so I am not sure your assumption will always hold. Or maybe I have misunderstood something? > > The problem of course starts from the fact that one AR is > supposed to > provide this list of GAARs + capabilities to the MN (which > could be a lot of > info). In a MN centric approach the MN knows which the > GAARs are and gets > their capabilities directly from them...much better IMO. => Can't agree more. GT> I suspected as much...I think that was the general feeling during the WG meeting and after Steve's presentation. Thanks George _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:03:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08542 for ; Wed, 27 Mar 2002 12:03:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28145 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:03:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26597; Wed, 27 Mar 2002 11:58:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26550 for ; Wed, 27 Mar 2002 11:58:10 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08126 for ; Wed, 27 Mar 2002 11:58:08 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 11:57:40 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5B@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:57:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 4:48 PM To: 'George Tsirtsis'; Hesham Soliman (ERA); 'Hemant Chaskar'; seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > The "extra option" on the RA may or may not be a problem. > We will only know > if this is a problem AFTER we know what "capabilities" mean > i.e.: how much > data can be in there for the list of GAARs. That does make > me nervous, > doesn't you? => I agree, but only if you assume that GAAR discovery will cover a very large number of GAARs. This is where I think that the assumptions are flawed. If we limit the AR-based discovery to one operator's network and one access tech, then we are most likely to end up with one or two GAARs. Right ? GT> In cellular deployment each AR will have up to 6 GAARs assuming ARs on each BS/AP. What you say above is that the protocol we are talking about is clever enough to know between which 2 or 3 ARs the MN is currently located. In the "anticipated" mode CAR discovery takes place prior to handoff so I am not sure your assumption will always hold. Or maybe I have misunderstood something? > > The problem of course starts from the fact that one AR is > supposed to > provide this list of GAARs + capabilities to the MN (which > could be a lot of > info). In a MN centric approach the MN knows which the > GAARs are and gets > their capabilities directly from them...much better IMO. => Can't agree more. GT> I suspected as much...I think that was the general feeling during the WG meeting and after Steve's presentation. Thanks George _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:08:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08763 for ; Wed, 27 Mar 2002 12:08:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27861; Wed, 27 Mar 2002 12:02:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27812 for ; Wed, 27 Mar 2002 12:02:35 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08510 for ; Wed, 27 Mar 2002 12:02:33 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RH2Zoq026748 for ; Wed, 27 Mar 2002 18:02:35 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 18:02:33 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:02:33 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB96@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:02:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > GT> In cellular deployment each AR will have up to 6 GAARs > assuming ARs on > each BS/AP. => Err, in _your_ cellular deployment ;) I wouldn't make this general statement about cellular networks. In fact it's the exact opposite with cdma2000 or 3GPP. What you say above is that the protocol we are > talking about is > clever enough to know between which 2 or 3 ARs the MN is > currently located. > In the "anticipated" mode CAR discovery takes place prior > to handoff so I am > not sure your assumption will always hold. Or maybe I have > misunderstood > something? => I think I wasn't too clear. In the anticipated mode, the assumption I make is that the triggers are at the AR, so the AR will do the discovery and forward the info to the MN. Just like the Prrtradv is FMIPv6. This is the problem with calling it anticipated, it gives the impression that anticipated must be network controlled. which is not the case of course. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:08:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08776 for ; Wed, 27 Mar 2002 12:08:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29358 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:08:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27861; Wed, 27 Mar 2002 12:02:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27812 for ; Wed, 27 Mar 2002 12:02:35 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08510 for ; Wed, 27 Mar 2002 12:02:33 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RH2Zoq026748 for ; Wed, 27 Mar 2002 18:02:35 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 18:02:33 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:02:33 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB96@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:02:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > GT> In cellular deployment each AR will have up to 6 GAARs > assuming ARs on > each BS/AP. => Err, in _your_ cellular deployment ;) I wouldn't make this general statement about cellular networks. In fact it's the exact opposite with cdma2000 or 3GPP. What you say above is that the protocol we are > talking about is > clever enough to know between which 2 or 3 ARs the MN is > currently located. > In the "anticipated" mode CAR discovery takes place prior > to handoff so I am > not sure your assumption will always hold. Or maybe I have > misunderstood > something? => I think I wasn't too clear. In the anticipated mode, the assumption I make is that the triggers are at the AR, so the AR will do the discovery and forward the info to the MN. Just like the Prrtradv is FMIPv6. This is the problem with calling it anticipated, it gives the impression that anticipated must be network controlled. which is not the case of course. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:10:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08883 for ; Wed, 27 Mar 2002 12:10:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27779; Wed, 27 Mar 2002 12:02:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27737 for ; Wed, 27 Mar 2002 12:02:25 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08507 for ; Wed, 27 Mar 2002 12:02:23 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:01:55 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5C@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:01:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org For what is worth I am in full agreement with what Hesham is saying below about the scope of this. George -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 4:53 PM To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery .... => I'll let you come up with the new text, but my curent concerns on the requirement is: - The scope of AR-based CAR should be limited to one operator's domain and one access technology. - The MN-based one is naturally limited by the number of ARs it can hear. FWIW, I don't think that passing preferences to the AR is a good idea or will ever scale. Hesham > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:10:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08893 for ; Wed, 27 Mar 2002 12:10:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29791 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:10:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27779; Wed, 27 Mar 2002 12:02:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27737 for ; Wed, 27 Mar 2002 12:02:25 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08507 for ; Wed, 27 Mar 2002 12:02:23 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:01:55 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5C@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:01:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org For what is worth I am in full agreement with what Hesham is saying below about the scope of this. George -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 4:53 PM To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery .... => I'll let you come up with the new text, but my curent concerns on the requirement is: - The scope of AR-based CAR should be limited to one operator's domain and one access technology. - The MN-based one is naturally limited by the number of ARs it can hear. FWIW, I don't think that passing preferences to the AR is a good idea or will ever scale. Hesham > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:13:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04528 for ; Wed, 27 Mar 2002 11:14:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12766 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 11:14:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10377; Wed, 27 Mar 2002 11:06:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10329 for ; Wed, 27 Mar 2002 11:06:45 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04180 for ; Wed, 27 Mar 2002 11:06:41 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RG93114617 for ; Wed, 27 Mar 2002 10:09:03 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 10:06:37 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 10:05:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 11:05:28 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVFF43Akqc2sE8QNm5GNh8iPdYgQAlJwxQ To: , , X-OriginalArrivalTime: 27 Mar 2002 16:05:35.0946 (UTC) FILETIME=[3B050AA0:01C1D5A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA10332 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, On second thought, let's keep it simple. Premature optimization often has unintended consequences. [DOT] Premature non-optimization can be even worse, in particular in this sense in which the actual data (and the amount) we're talking about is not yet understood. So demanding the transmission of ALL data might have very ugly consequences. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:14:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09164 for ; Wed, 27 Mar 2002 12:14:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00386; Wed, 27 Mar 2002 12:12:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00350 for ; Wed, 27 Mar 2002 12:12:17 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09065 for ; Wed, 27 Mar 2002 12:12:15 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:11:44 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5E@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:11:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 5:02 PM To: 'George Tsirtsis'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > GT> In cellular deployment each AR will have up to 6 GAARs > assuming ARs on > each BS/AP. => Err, in _your_ cellular deployment ;) I wouldn't make this general statement about cellular networks. In fact it's the exact opposite with cdma2000 or 3GPP. GT> Personally i do not own or have any cellular deployment so it is certainly not mine :-) But seriously, how does it work in cdma? what I said probably applies to tdma systems I guess? What you say above is that the protocol we are > talking about is > clever enough to know between which 2 or 3 ARs the MN is > currently located. > In the "anticipated" mode CAR discovery takes place prior > to handoff so I am > not sure your assumption will always hold. Or maybe I have > misunderstood > something? => I think I wasn't too clear. In the anticipated mode, the assumption I make is that the triggers are at the AR, so the AR will do the discovery and forward the info to the MN. Just like the Prrtradv is FMIPv6. This is the problem with calling it anticipated, it gives the impression that anticipated must be network controlled. which is not the case of course. GT> What you are saying is that CAR discovery can be network controlled but the actual handoff may be MN controlled? In which case this is a bit weird in that the network knows exactly what the MN is going to do next but lets the MN do it...hmm anyway, I do not have a problem with that although I do not like it either. George _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:14:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09181 for ; Wed, 27 Mar 2002 12:14:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01086 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:14:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00386; Wed, 27 Mar 2002 12:12:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00350 for ; Wed, 27 Mar 2002 12:12:17 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09065 for ; Wed, 27 Mar 2002 12:12:15 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:11:44 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5E@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:11:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 5:02 PM To: 'George Tsirtsis'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > GT> In cellular deployment each AR will have up to 6 GAARs > assuming ARs on > each BS/AP. => Err, in _your_ cellular deployment ;) I wouldn't make this general statement about cellular networks. In fact it's the exact opposite with cdma2000 or 3GPP. GT> Personally i do not own or have any cellular deployment so it is certainly not mine :-) But seriously, how does it work in cdma? what I said probably applies to tdma systems I guess? What you say above is that the protocol we are > talking about is > clever enough to know between which 2 or 3 ARs the MN is > currently located. > In the "anticipated" mode CAR discovery takes place prior > to handoff so I am > not sure your assumption will always hold. Or maybe I have > misunderstood > something? => I think I wasn't too clear. In the anticipated mode, the assumption I make is that the triggers are at the AR, so the AR will do the discovery and forward the info to the MN. Just like the Prrtradv is FMIPv6. This is the problem with calling it anticipated, it gives the impression that anticipated must be network controlled. which is not the case of course. GT> What you are saying is that CAR discovery can be network controlled but the actual handoff may be MN controlled? In which case this is a bit weird in that the network knows exactly what the MN is going to do next but lets the MN do it...hmm anyway, I do not have a problem with that although I do not like it either. George _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:25:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09938 for ; Wed, 27 Mar 2002 12:25:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02591; Wed, 27 Mar 2002 12:19:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02500 for ; Wed, 27 Mar 2002 12:19:33 -0500 (EST) Received: from hotmail.com (f104.law9.hotmail.com [64.4.9.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09512 for ; Wed, 27 Mar 2002 12:19:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:19:04 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:19:04 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:19:04 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:19:04.0173 (UTC) FILETIME=[7E8719D0:01C1D5B3] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org George, Scope has already been addressed in the requirements right now using the Inter (SHOULD) vs. Intra (MUST) domain scope of CAR discovery. Second, to say that CAR discovery for Inter-technology (MUST) not being feasible (using scope as a reason) is again is incorrect IMHO. A simple counter example would be the same provider owning both technologies. Having said that what is too much or acceptible bandwidth usage is very subjective. Thats why the option should rest with the MN whether to accept it or not. AR based or MN based, TAR selection is clearly limited by the number of ARs the MN can be associated with. MN-based CAR discovery is not only constrained by the number of ARs the it can associate with, but how much tolerance the MN has with respect to bandwidth and power requirements. AR-assisted CAR discovery discovers probably all the GAARs in the AR's domain and during TAR selection the MN can choose clearly based and what it can hear. My two cents, Govind. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10537 for ; Wed, 27 Mar 2002 12:43:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20085; Wed, 27 Mar 2002 12:38:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20055 for ; Wed, 27 Mar 2002 12:38:46 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10372 for ; Wed, 27 Mar 2002 12:38:45 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RHcjoq005533 for ; Wed, 27 Mar 2002 18:38:45 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 18:38:45 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:38:44 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB99@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:38:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > GT> Personally i do not own or have any cellular deployment so it is > certainly not mine :-) But seriously, how does it work in > cdma? what I said > probably applies to tdma systems I guess? => Well, the only difference is that the AR coverage area includes several APs, so it's very unlikely that you would end up with 6 GAARs in the same technology. > => I think I wasn't too clear. In the anticipated > mode, the assumption I make is that the triggers > are at the AR, so the AR will do the discovery > and forward the info to the MN. Just like > the Prrtradv is FMIPv6. > This is the problem with calling it anticipated, > it gives the impression that anticipated must > be network controlled. which is not the case > of course. > > GT> What you are saying is that CAR discovery can be > network controlled but > the actual handoff may be MN controlled? => No quite. I meant that ARs can do the discovery of GAARs that _they_know, then pass the info to the MN who might know some more, then the MN can decide. So the way I see it, the ARs are not controlling anything, they simply pass information. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10548 for ; Wed, 27 Mar 2002 12:43:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20591 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:43:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20085; Wed, 27 Mar 2002 12:38:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20055 for ; Wed, 27 Mar 2002 12:38:46 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10372 for ; Wed, 27 Mar 2002 12:38:45 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RHcjoq005533 for ; Wed, 27 Mar 2002 18:38:45 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 18:38:45 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:38:44 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB99@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:38:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > GT> Personally i do not own or have any cellular deployment so it is > certainly not mine :-) But seriously, how does it work in > cdma? what I said > probably applies to tdma systems I guess? => Well, the only difference is that the AR coverage area includes several APs, so it's very unlikely that you would end up with 6 GAARs in the same technology. > => I think I wasn't too clear. In the anticipated > mode, the assumption I make is that the triggers > are at the AR, so the AR will do the discovery > and forward the info to the MN. Just like > the Prrtradv is FMIPv6. > This is the problem with calling it anticipated, > it gives the impression that anticipated must > be network controlled. which is not the case > of course. > > GT> What you are saying is that CAR discovery can be > network controlled but > the actual handoff may be MN controlled? => No quite. I meant that ARs can do the discovery of GAARs that _they_know, then pass the info to the MN who might know some more, then the MN can decide. So the way I see it, the ARs are not controlling anything, they simply pass information. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:43:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10590 for ; Wed, 27 Mar 2002 12:43:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20191; Wed, 27 Mar 2002 12:40:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20161 for ; Wed, 27 Mar 2002 12:40:52 -0500 (EST) Received: from hotmail.com (f23.law7.hotmail.com [216.33.237.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10407 for ; Wed, 27 Mar 2002 12:40:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:40:22 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:40:22 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:40:22 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:40:22.0895 (UTC) FILETIME=[78B497F0:01C1D5B6] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hernik: If we do not know, we should say "we do not know". I have difficulty putting in MUST requirement about which we do not know for sure. If it means that all GAARs and all their capabilities need not be sent, it must say so. Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 17:43:46 +0100 > >Hemant, > > The requirement as first proposed does not imply that *all* >GAAR information must be sent. The requirement as first proposed also >does not require that a filtering mechanism must be part of the solution. > >The revised requirement requires a filtering mechanism. I do not believe >we know that this is the right way to go yet. Therefore I do not believe >that it is good to add this restriction. > > Henrik > > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige AR to blast >all > > GAAR IDs and all of their capabilities to MN, why not say so clearly. >Why do > > we need to hide this fact? We can come up with something else, if you do >not > > like on-demand extension. I think without such extension the solution > > satisfying this requirement may have serious shortcomings that I >described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this requirement >unless it > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the solution >satisfying > > > > this requirement looks like and violates basic tenets of engineering > > >design, > > > > namely efficiency. The solution satisfying this requirement is >obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might > > >be a > > > > big chunk of data (= number of GAARs times capability set of each). >This > > > > flood will occur either on active traffic connection which I call >case > > >(i) > > > > (relevant for single interface MN and two-interface MN where second > > > > interface is sleeping) or on second interface which I call case (ii) > > > > (relevant for two interface MN with both interfaces awake). There >are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > > >causes > > > > power wastage. This is because, after receiving these capabilities >MN > > >either > > > > rejects the new AR (which is worst), and even if it selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN >that it > > > > sees. Which means the same information (which could be big enough) >is > > > > transmitted on downlink so many times. This takes up considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs will only be > > > > transmitting GAAR capabilities to different MNs all the time. This >means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one statement >requirement > > >that > > > > you proposed and who have not, we should first analyse above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > > > the MN requirements, which is what CAR discovery was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat >the > > > > >requirement I would like to see (and Henrik apparently agrees) so >we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails saying that there >is > > > > > > no basis for network based CAR discovery. So are you now >agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN may use a >variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's >a > > > > >protocol design, not a requirement, choice. The requirement is >clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this reqirement >worded > > > > >just this way. Nothing about "as the MN expresses its preferences" >or > > > > >"by the CAR discovery module" or anything else. And I believe >Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should we include >this > > > > >requirement instead of requirement 3.4, which has the AR in >control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world’s largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:43:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10604 for ; Wed, 27 Mar 2002 12:43:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20703 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:43:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20191; Wed, 27 Mar 2002 12:40:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20161 for ; Wed, 27 Mar 2002 12:40:52 -0500 (EST) Received: from hotmail.com (f23.law7.hotmail.com [216.33.237.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10407 for ; Wed, 27 Mar 2002 12:40:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:40:22 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:40:22 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:40:22 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:40:22.0895 (UTC) FILETIME=[78B497F0:01C1D5B6] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hernik: If we do not know, we should say "we do not know". I have difficulty putting in MUST requirement about which we do not know for sure. If it means that all GAARs and all their capabilities need not be sent, it must say so. Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 17:43:46 +0100 > >Hemant, > > The requirement as first proposed does not imply that *all* >GAAR information must be sent. The requirement as first proposed also >does not require that a filtering mechanism must be part of the solution. > >The revised requirement requires a filtering mechanism. I do not believe >we know that this is the right way to go yet. Therefore I do not believe >that it is good to add this restriction. > > Henrik > > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige AR to blast >all > > GAAR IDs and all of their capabilities to MN, why not say so clearly. >Why do > > we need to hide this fact? We can come up with something else, if you do >not > > like on-demand extension. I think without such extension the solution > > satisfying this requirement may have serious shortcomings that I >described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this requirement >unless it > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the solution >satisfying > > > > this requirement looks like and violates basic tenets of engineering > > >design, > > > > namely efficiency. The solution satisfying this requirement is >obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This >might > > >be a > > > > big chunk of data (= number of GAARs times capability set of each). >This > > > > flood will occur either on active traffic connection which I call >case > > >(i) > > > > (relevant for single interface MN and two-interface MN where second > > > > interface is sleeping) or on second interface which I call case (ii) > > > > (relevant for two interface MN with both interfaces awake). There >are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in >traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > > >causes > > > > power wastage. This is because, after receiving these capabilities >MN > > >either > > > > rejects the new AR (which is worst), and even if it selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN >that it > > > > sees. Which means the same information (which could be big enough) >is > > > > transmitted on downlink so many times. This takes up considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs will only be > > > > transmitting GAAR capabilities to different MNs all the time. This >means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one statement >requirement > > >that > > > > you proposed and who have not, we should first analyse above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > > their capabilities to the MN (maybe only pass on those which >satisfy > > > > > > the MN requirements, which is what CAR discovery was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat >the > > > > >requirement I would like to see (and Henrik apparently agrees) so >we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails saying that there >is > > > > > > no basis for network based CAR discovery. So are you now >agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol >allows > > > > >the MN to discover the GAAR and capabilities, the MN decides which >one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN may use a >variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's >a > > > > >protocol design, not a requirement, choice. The requirement is >clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this reqirement >worded > > > > >just this way. Nothing about "as the MN expresses its preferences" >or > > > > >"by the CAR discovery module" or anything else. And I believe >Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should we include >this > > > > >requirement instead of requirement 3.4, which has the AR in >control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world’s largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:53:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11231 for ; Wed, 27 Mar 2002 12:53:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07906 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:25:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02591; Wed, 27 Mar 2002 12:19:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02500 for ; Wed, 27 Mar 2002 12:19:33 -0500 (EST) Received: from hotmail.com (f104.law9.hotmail.com [64.4.9.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09512 for ; Wed, 27 Mar 2002 12:19:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:19:04 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:19:04 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:19:04 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:19:04.0173 (UTC) FILETIME=[7E8719D0:01C1D5B3] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org George, Scope has already been addressed in the requirements right now using the Inter (SHOULD) vs. Intra (MUST) domain scope of CAR discovery. Second, to say that CAR discovery for Inter-technology (MUST) not being feasible (using scope as a reason) is again is incorrect IMHO. A simple counter example would be the same provider owning both technologies. Having said that what is too much or acceptible bandwidth usage is very subjective. Thats why the option should rest with the MN whether to accept it or not. AR based or MN based, TAR selection is clearly limited by the number of ARs the MN can be associated with. MN-based CAR discovery is not only constrained by the number of ARs the it can associate with, but how much tolerance the MN has with respect to bandwidth and power requirements. AR-assisted CAR discovery discovers probably all the GAARs in the AR's domain and during TAR selection the MN can choose clearly based and what it can hear. My two cents, Govind. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:54:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11311 for ; Wed, 27 Mar 2002 12:54:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21236; Wed, 27 Mar 2002 12:48:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21207 for ; Wed, 27 Mar 2002 12:48:22 -0500 (EST) Received: from hotmail.com (f190.law7.hotmail.com [216.33.237.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10880 for ; Wed, 27 Mar 2002 12:48:22 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:47:52 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:47:52 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:47:52 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:47:52.0538 (UTC) FILETIME=[84B6ABA0:01C1D5B7] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: I do not know what consensus you are talking about. There was one question asked which was not clearly stated, and for that too, I saw only three hands go up. The requirement was posted after MPLS and there has not been any consensus on it yet. What we have agreed in MPLS was "MN's requirements MUST be considered in CAR discovery, handoffs etc.". We all are in good agreement on that. I don't think however that this means that it precludes executing processor level algorithms anywhere else than MN's processor, as long as those algorithms consider all MN's requirement. This is implementation-specific aspect. More comments below. Hemant >From: "Hesham Soliman (ERA)" >To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" >, G.Tsirtsis@flarion.com, >seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 17:45:52 +0100 > >Hi Hemant, > > > No RA is not what blasting is about. What this requirement > > is saying is to > > send to MN a volume of data = Number of GAARs times > > capability set of each. > > Number of GAARs itself could be large and capability set > > could be very large > > too. It might contain policies, supported IP protocols, any > > application > > specific functionality support and this set could be extensible. > >=> This is all based on an assumption: The scope >of the GAAR discovery will scale to a very large number of GAARs. [HC] What matters here is the product of number of GAARs and size of their capabilities". Even if you do not have large number of GAARs, capabilities of each one of them can be huge and extensible. >I don't think this is realistic, and after Steve's presentation >I thought the entire WG agreed with this. >Why are we trying to reverse this concensus? > > > > > Sending this volume of data to MN without any regard to > > whether it wants it > > or not is what I call blasting. > >=> See above. > >Hesham > > > > > Hemant > > > > >From: "Hesham Soliman (ERA)" > > >To: "'George Tsirtsis'" , > > "'Hemant Chaskar'" > > >, seamoby@ietf.org > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement (wa > > >s: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 17:32:30 +0100 > > > > > >What is iths blöasting that people keep > > >bringing up? an extra option in an RA is blasting ???? > > >What is the alternative: The magic AR that knows > > >everything ?????????????? > > > > > >Seriously, let's keep it simple or this whole > > >protocol will start collapsing the moment > > >anyone starts deploying it. Of course if deployment > > >is not a concern then I'll just og back to sleep! > > > > > >Hesham > > > > > > > -----Original Message----- > > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (wa s: Examples of CAR discovery) > > > > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > > GAAR IDs and all of > > > > their capabilities to MN" is a good idea? If not (which I > > > > hope so) then the > > > > requirements document should not imply otherwise. > > > > > > > > George > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > > To: seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (was: Examples of CAR discovery) > > > > > > > > > > > > Hi Hernik: > > > > > > > > I did read your comment and responded as follows in my > > > > earlier email. > > > > Cut'n'Paste: > > > > > > > > ------------------------------- > > > > If we honestly think that the requirement does not oblige > > > > AR to blast all > > > > GAAR IDs and all of their capabilities to MN, why not say > > > > so clearly. Why do > > > > > > > > we need to hide this fact? We can come up with something > > > > else, if you do not > > > > > > > > like on-demand extension. I think without such extension > > > > the solution > > > > satisfying this requirement may have serious shortcomings > > > > that I described > > > > in my other email to James. > > > > -------------------------------- > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "Henrik Levkowetz" > > > > >To: "Hemant Chaskar" > > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: Examples of CAR discovery) > > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > > > >Hemant, > > > > > > > > > > You apparently did not read my recent posting. > > Cut'n'Paste: > > > > > > > > > > No, the requirement is just fine. It does not > > require *all* GAAR > > > > >information, it does not require *on-demand operation*, it > > > > expresses > > > > >exactly > > > > >what we are in a position to say about the matter now: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > > Why? Do you > > > > >want to make things more complicated than they have to be? > > > > > > > > > > Henrik > > > > > > > > > >Hemant wrote: > > > > > > > > > > > > Hi James: > > > > > > > > > > > > There are serious shortcomings of the solution > > satisfying this > > > > >requirement. > > > > > > They are described below. How can we finalise this > > > > requirement unless it > > > > > > > > >is > > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > > > For this, it might be good idea to visualise how the > > > > solution satisfying > > > > > > this requirement looks like and violates basic tenets > > > > of engineering > > > > >design, > > > > > > namely efficiency. The solution satisfying this > > > > requirement is obliged > > > > >to > > > > > > blast GAAR IDs and their capabilities on MN when AR > > > > sees MN. This might > > > > >be a > > > > > > big chunk of data (= number of GAARs times capability > > > > set of each). This > > > > > > flood will occur either on active traffic connection > > > > which I call case > > > > >(i) > > > > > > (relevant for single interface MN and two-interface MN > > > > where second > > > > > > interface is sleeping) or on second interface which I > > > > call case (ii) > > > > > > (relevant for two interface MN with both interfaces > > > > awake). There are > > > > > > following effects of this flood: > > > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > > disruption in traffic > > > > >over > > > > > > active traffic channel. > > > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > > receiving this flood > > > > >causes > > > > > > power wastage. This is because, after receiving these > > > > capabilities MN > > > > >either > > > > > > rejects the new AR (which is worst), and even if it > > > > selcects one why > > > > >does it > > > > > > need to receive capabilities of GAARs that do not > > matter for it. > > > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > > every MN that it > > > > > > sees. Which means the same information (which could be > > > > big enough) is > > > > > > transmitted on downlink so many times. This takes up > > > > considerable > > > > >fraction > > > > > > of downlink capacity. > > > > > > > > > > > > 4. Limit on capability definition: This requirement > > > > restricts the > > > > >definition > > > > > > of capabilities to a very small size, otherwise all ARs > > > > will only be > > > > > > transmitting GAAR capabilities to different MNs all the > > > > time. This means > > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > > statement requirement > > > > >that > > > > > > you proposed and who have not, we should first analyse > > > > above harmful > > > > >effects > > > > > > before deciding either way. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: > > > > > > >Examples of CAR discovery) > > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > > > >, > > > > > > > > So now you agree that the AR can hand over the list > > > > of GAARs and > > > > > > > > their capabilities to the MN (maybe only pass on > > > > those which satisfy > > > > > > > > the MN requirements, which is what CAR discovery > > > > was originally > > > > > > >about). > > > > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > > Let me repeat the > > > > > > >requirement I would like to see (and Henrik apparently > > > > agrees) so we > > > > >are > > > > > > >clear on this: > > > > > > > > > > > > > > The CAR discovery protocol MUST provide the > > MN with GAAR > > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > > > > Which first implies that the network is > > taking care of CAR > > > > >discovery. > > > > > > > > This seems contradictory to your earlier mails > > > > saying that there is > > > > > > > > no basis for network based CAR discovery. So are > > > > you now agreeing > > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > > The protocol allows > > > > > > >the MN to discover the GAAR and capabilities, the MN > > > > decides which one > > > > > > >it wants. > > > > > > >Nothing about the AR in control of anything. The MN > > > > may use a variant > > > > >of > > > > > > >IPv6 neighbor discovery, the AR may be involved > > > > somehow, but that's a > > > > > > >protocol design, not a requirement, choice. The > > > > requirement is clearly > > > > > > >that the MN does the discovery. > > > > > > > > > > > > > >We now have two working group members who want this > > > > reqirement worded > > > > > > >just this way. Nothing about "as the MN expresses its > > > > preferences" or > > > > > > >"by the CAR discovery module" or anything else. And I > > > > believe Hesham > > > > >has > > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > > we include this > > > > > > >requirement instead of requirement 3.4, which has the > > > > AR in control? > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Seamoby mailing list > > > > > > >Seamoby@ietf.org > > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > MSN Photos is the easiest way to share and print > > your photos: > > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: >http://messenger.msn.com _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:54:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11321 for ; Wed, 27 Mar 2002 12:54:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22949 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:54:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21236; Wed, 27 Mar 2002 12:48:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21207 for ; Wed, 27 Mar 2002 12:48:22 -0500 (EST) Received: from hotmail.com (f190.law7.hotmail.com [216.33.237.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10880 for ; Wed, 27 Mar 2002 12:48:22 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:47:52 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:47:52 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 17:47:52 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:47:52.0538 (UTC) FILETIME=[84B6ABA0:01C1D5B7] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: I do not know what consensus you are talking about. There was one question asked which was not clearly stated, and for that too, I saw only three hands go up. The requirement was posted after MPLS and there has not been any consensus on it yet. What we have agreed in MPLS was "MN's requirements MUST be considered in CAR discovery, handoffs etc.". We all are in good agreement on that. I don't think however that this means that it precludes executing processor level algorithms anywhere else than MN's processor, as long as those algorithms consider all MN's requirement. This is implementation-specific aspect. More comments below. Hemant >From: "Hesham Soliman (ERA)" >To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" >, G.Tsirtsis@flarion.com, >seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of CAR discovery) >Date: Wed, 27 Mar 2002 17:45:52 +0100 > >Hi Hemant, > > > No RA is not what blasting is about. What this requirement > > is saying is to > > send to MN a volume of data = Number of GAARs times > > capability set of each. > > Number of GAARs itself could be large and capability set > > could be very large > > too. It might contain policies, supported IP protocols, any > > application > > specific functionality support and this set could be extensible. > >=> This is all based on an assumption: The scope >of the GAAR discovery will scale to a very large number of GAARs. [HC] What matters here is the product of number of GAARs and size of their capabilities". Even if you do not have large number of GAARs, capabilities of each one of them can be huge and extensible. >I don't think this is realistic, and after Steve's presentation >I thought the entire WG agreed with this. >Why are we trying to reverse this concensus? > > > > > Sending this volume of data to MN without any regard to > > whether it wants it > > or not is what I call blasting. > >=> See above. > >Hesham > > > > > Hemant > > > > >From: "Hesham Soliman (ERA)" > > >To: "'George Tsirtsis'" , > > "'Hemant Chaskar'" > > >, seamoby@ietf.org > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement (wa > > >s: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 17:32:30 +0100 > > > > > >What is iths blöasting that people keep > > >bringing up? an extra option in an RA is blasting ???? > > >What is the alternative: The magic AR that knows > > >everything ?????????????? > > > > > >Seriously, let's keep it simple or this whole > > >protocol will start collapsing the moment > > >anyone starts deploying it. Of course if deployment > > >is not a concern then I'll just og back to sleep! > > > > > >Hesham > > > > > > > -----Original Message----- > > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (wa s: Examples of CAR discovery) > > > > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > > GAAR IDs and all of > > > > their capabilities to MN" is a good idea? If not (which I > > > > hope so) then the > > > > requirements document should not imply otherwise. > > > > > > > > George > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > > To: seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (was: Examples of CAR discovery) > > > > > > > > > > > > Hi Hernik: > > > > > > > > I did read your comment and responded as follows in my > > > > earlier email. > > > > Cut'n'Paste: > > > > > > > > ------------------------------- > > > > If we honestly think that the requirement does not oblige > > > > AR to blast all > > > > GAAR IDs and all of their capabilities to MN, why not say > > > > so clearly. Why do > > > > > > > > we need to hide this fact? We can come up with something > > > > else, if you do not > > > > > > > > like on-demand extension. I think without such extension > > > > the solution > > > > satisfying this requirement may have serious shortcomings > > > > that I described > > > > in my other email to James. > > > > -------------------------------- > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "Henrik Levkowetz" > > > > >To: "Hemant Chaskar" > > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: Examples of CAR discovery) > > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > > > >Hemant, > > > > > > > > > > You apparently did not read my recent posting. > > Cut'n'Paste: > > > > > > > > > > No, the requirement is just fine. It does not > > require *all* GAAR > > > > >information, it does not require *on-demand operation*, it > > > > expresses > > > > >exactly > > > > >what we are in a position to say about the matter now: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > > Why? Do you > > > > >want to make things more complicated than they have to be? > > > > > > > > > > Henrik > > > > > > > > > >Hemant wrote: > > > > > > > > > > > > Hi James: > > > > > > > > > > > > There are serious shortcomings of the solution > > satisfying this > > > > >requirement. > > > > > > They are described below. How can we finalise this > > > > requirement unless it > > > > > > > > >is > > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > > > For this, it might be good idea to visualise how the > > > > solution satisfying > > > > > > this requirement looks like and violates basic tenets > > > > of engineering > > > > >design, > > > > > > namely efficiency. The solution satisfying this > > > > requirement is obliged > > > > >to > > > > > > blast GAAR IDs and their capabilities on MN when AR > > > > sees MN. This might > > > > >be a > > > > > > big chunk of data (= number of GAARs times capability > > > > set of each). This > > > > > > flood will occur either on active traffic connection > > > > which I call case > > > > >(i) > > > > > > (relevant for single interface MN and two-interface MN > > > > where second > > > > > > interface is sleeping) or on second interface which I > > > > call case (ii) > > > > > > (relevant for two interface MN with both interfaces > > > > awake). There are > > > > > > following effects of this flood: > > > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > > disruption in traffic > > > > >over > > > > > > active traffic channel. > > > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > > receiving this flood > > > > >causes > > > > > > power wastage. This is because, after receiving these > > > > capabilities MN > > > > >either > > > > > > rejects the new AR (which is worst), and even if it > > > > selcects one why > > > > >does it > > > > > > need to receive capabilities of GAARs that do not > > matter for it. > > > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > > every MN that it > > > > > > sees. Which means the same information (which could be > > > > big enough) is > > > > > > transmitted on downlink so many times. This takes up > > > > considerable > > > > >fraction > > > > > > of downlink capacity. > > > > > > > > > > > > 4. Limit on capability definition: This requirement > > > > restricts the > > > > >definition > > > > > > of capabilities to a very small size, otherwise all ARs > > > > will only be > > > > > > transmitting GAAR capabilities to different MNs all the > > > > time. This means > > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > > statement requirement > > > > >that > > > > > > you proposed and who have not, we should first analyse > > > > above harmful > > > > >effects > > > > > > before deciding either way. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: > > > > > > >Examples of CAR discovery) > > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > > > >, > > > > > > > > So now you agree that the AR can hand over the list > > > > of GAARs and > > > > > > > > their capabilities to the MN (maybe only pass on > > > > those which satisfy > > > > > > > > the MN requirements, which is what CAR discovery > > > > was originally > > > > > > >about). > > > > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > > Let me repeat the > > > > > > >requirement I would like to see (and Henrik apparently > > > > agrees) so we > > > > >are > > > > > > >clear on this: > > > > > > > > > > > > > > The CAR discovery protocol MUST provide the > > MN with GAAR > > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > > > > Which first implies that the network is > > taking care of CAR > > > > >discovery. > > > > > > > > This seems contradictory to your earlier mails > > > > saying that there is > > > > > > > > no basis for network based CAR discovery. So are > > > > you now agreeing > > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > > The protocol allows > > > > > > >the MN to discover the GAAR and capabilities, the MN > > > > decides which one > > > > > > >it wants. > > > > > > >Nothing about the AR in control of anything. The MN > > > > may use a variant > > > > >of > > > > > > >IPv6 neighbor discovery, the AR may be involved > > > > somehow, but that's a > > > > > > >protocol design, not a requirement, choice. The > > > > requirement is clearly > > > > > > >that the MN does the discovery. > > > > > > > > > > > > > >We now have two working group members who want this > > > > reqirement worded > > > > > > >just this way. Nothing about "as the MN expresses its > > > > preferences" or > > > > > > >"by the CAR discovery module" or anything else. And I > > > > believe Hesham > > > > >has > > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > > we include this > > > > > > >requirement instead of requirement 3.4, which has the > > > > AR in control? > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Seamoby mailing list > > > > > > >Seamoby@ietf.org > > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > MSN Photos is the easiest way to share and print > > your photos: > > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: >http://messenger.msn.com _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:54:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11340 for ; Wed, 27 Mar 2002 12:54:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21461; Wed, 27 Mar 2002 12:48:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21390 for ; Wed, 27 Mar 2002 12:48:47 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10923 for ; Wed, 27 Mar 2002 12:48:46 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:48:16 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5F@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:48:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 5:39 PM To: 'George Tsirtsis'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > GT> Personally i do not own or have any cellular deployment so it is > certainly not mine :-) But seriously, how does it work in > cdma? what I said > probably applies to tdma systems I guess? => Well, the only difference is that the AR coverage area includes several APs, so it's very unlikely that you would end up with 6 GAARs in the same technology. GT> I see, I guess because of soft handoff in cdma. But then, in environments that can actually utilize an AR per BS/AP it is possible to have multiple GAARs even if you restrict this to a single technology. So the concern that some people have about GAAR+capabilities list is not totally unfounded, wouldn't you say?. > => I think I wasn't too clear. In the anticipated > mode, the assumption I make is that the triggers > are at the AR, so the AR will do the discovery > and forward the info to the MN. Just like > the Prrtradv is FMIPv6. > This is the problem with calling it anticipated, > it gives the impression that anticipated must > be network controlled. which is not the case > of course. > > GT> What you are saying is that CAR discovery can be > network controlled but > the actual handoff may be MN controlled? => No quite. I meant that ARs can do the discovery of GAARs that _they_know, then pass the info to the MN who might know some more, then the MN can decide. So the way I see it, the ARs are not controlling anything, they simply pass information. GT> OK, thanks. George _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:54:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11357 for ; Wed, 27 Mar 2002 12:54:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23002 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:54:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21461; Wed, 27 Mar 2002 12:48:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21390 for ; Wed, 27 Mar 2002 12:48:47 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10923 for ; Wed, 27 Mar 2002 12:48:46 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:48:16 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC5F@ftmail> From: George Tsirtsis To: "'Hesham Soliman (ERA)'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:48:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 5:39 PM To: 'George Tsirtsis'; Hesham Soliman (ERA); seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > GT> Personally i do not own or have any cellular deployment so it is > certainly not mine :-) But seriously, how does it work in > cdma? what I said > probably applies to tdma systems I guess? => Well, the only difference is that the AR coverage area includes several APs, so it's very unlikely that you would end up with 6 GAARs in the same technology. GT> I see, I guess because of soft handoff in cdma. But then, in environments that can actually utilize an AR per BS/AP it is possible to have multiple GAARs even if you restrict this to a single technology. So the concern that some people have about GAAR+capabilities list is not totally unfounded, wouldn't you say?. > => I think I wasn't too clear. In the anticipated > mode, the assumption I make is that the triggers > are at the AR, so the AR will do the discovery > and forward the info to the MN. Just like > the Prrtradv is FMIPv6. > This is the problem with calling it anticipated, > it gives the impression that anticipated must > be network controlled. which is not the case > of course. > > GT> What you are saying is that CAR discovery can be > network controlled but > the actual handoff may be MN controlled? => No quite. I meant that ARs can do the discovery of GAARs that _they_know, then pass the info to the MN who might know some more, then the MN can decide. So the way I see it, the ARs are not controlling anything, they simply pass information. GT> OK, thanks. George _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:55:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11453 for ; Wed, 27 Mar 2002 12:55:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22083; Wed, 27 Mar 2002 12:49:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22051 for ; Wed, 27 Mar 2002 12:49:54 -0500 (EST) Received: from hotmail.com (f166.law7.hotmail.com [216.33.237.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11030 for ; Wed, 27 Mar 2002 12:49:54 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:49:24 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:49:24 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:49:24 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:49:24.0594 (UTC) FILETIME=[BB954D20:01C1D5B7] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik: If you are so sure of this interpretation, why don't we add it to requirement for clarity. Why should leave the requirement text to open interpretation. Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 17:44:53 +0100 > >Hemant, > > Nobody is proposing to blast anybody blindly. This is a misapprehension. > > Henrik > > > > Henrik: > > > > I agree that you cannot focus on one case only, but then you cannot >ignore > > any too. The current requirement of blasting MN blindly with volume of > > capability data does ingore implication on certain cases. Further this > > requirement is a MUST one and does not say whether it is applicable to >only > > some cases or all cases. > > > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" , > > >Subject: RE: [Seamoby] Examples of CAR discovery > > >Date: Wed, 27 Mar 2002 02:28:25 +0100 > > > > > >Hemant wrote: > > > > > > > > Hi Henrik: > > > > > > > > > > > > >-------------------------------------snip------------------------------ > > > > > > > > > > > > An example where such comparison may occur in network is when >there > > >is > > > > >only > > > > > > one interface on MN and it can listen only to radio beacons of > > > > >surrounding > > > > > > access points. This is similar to break-before-make handoff >case. > > >Here, > > > > >MN > > > > > > cannot receive capabilities of GAARs without letting go the >previous > > > > > > connection. Do you think that such cases are not relevant and we > > >should > > > > > > exclude such cases right at the problem statement/requirements > > >stage? > > > > > > > > > >I think that designing for the one access technology case will >cripple > > > > >the solution. > > > > > > > > [HC] I do not understand your comment. Are you essentially saying >that > > >"This > > > > case is irrelevant for CAR discovery" or "Completely AR unassisted >CAR > > > > discovery is optimal for this case too". > > > > > >No, i'm not saying this case is irrelevant, or that AR unassisted CAR > > >discovery > > >is optimal ... for any case. I'm saying: > > > > > >I think that designing for the one access technology case will cripple > > >the solution. > > > > > > > > > > > IMHO neither requirements nor problem statement should ignore any >use > > >cases. > > > > If they do, it should be explicitly stated so in the spec, so that > > >designers > > > > are not misguided to apply solutions to cases for which they are not > > > > designed. > > > > > >Nobody's ignoring any use cases. But if you focus on one sample to the > > >detriment of the rest, it will cripple your solution. > > > > > > Regards, > > > Henrik > > > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world’s largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:55:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11466 for ; Wed, 27 Mar 2002 12:55:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23103 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:55:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22083; Wed, 27 Mar 2002 12:49:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22051 for ; Wed, 27 Mar 2002 12:49:54 -0500 (EST) Received: from hotmail.com (f166.law7.hotmail.com [216.33.237.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11030 for ; Wed, 27 Mar 2002 12:49:54 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:49:24 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:49:24 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:49:24 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:49:24.0594 (UTC) FILETIME=[BB954D20:01C1D5B7] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Henrik: If you are so sure of this interpretation, why don't we add it to requirement for clarity. Why should leave the requirement text to open interpretation. Hemant >From: "Henrik Levkowetz" >To: "Hemant Chaskar" >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 17:44:53 +0100 > >Hemant, > > Nobody is proposing to blast anybody blindly. This is a misapprehension. > > Henrik > > > > Henrik: > > > > I agree that you cannot focus on one case only, but then you cannot >ignore > > any too. The current requirement of blasting MN blindly with volume of > > capability data does ingore implication on certain cases. Further this > > requirement is a MUST one and does not say whether it is applicable to >only > > some cases or all cases. > > > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" , > > >Subject: RE: [Seamoby] Examples of CAR discovery > > >Date: Wed, 27 Mar 2002 02:28:25 +0100 > > > > > >Hemant wrote: > > > > > > > > Hi Henrik: > > > > > > > > > > > > >-------------------------------------snip------------------------------ > > > > > > > > > > > > An example where such comparison may occur in network is when >there > > >is > > > > >only > > > > > > one interface on MN and it can listen only to radio beacons of > > > > >surrounding > > > > > > access points. This is similar to break-before-make handoff >case. > > >Here, > > > > >MN > > > > > > cannot receive capabilities of GAARs without letting go the >previous > > > > > > connection. Do you think that such cases are not relevant and we > > >should > > > > > > exclude such cases right at the problem statement/requirements > > >stage? > > > > > > > > > >I think that designing for the one access technology case will >cripple > > > > >the solution. > > > > > > > > [HC] I do not understand your comment. Are you essentially saying >that > > >"This > > > > case is irrelevant for CAR discovery" or "Completely AR unassisted >CAR > > > > discovery is optimal for this case too". > > > > > >No, i'm not saying this case is irrelevant, or that AR unassisted CAR > > >discovery > > >is optimal ... for any case. I'm saying: > > > > > >I think that designing for the one access technology case will cripple > > >the solution. > > > > > > > > > > > IMHO neither requirements nor problem statement should ignore any >use > > >cases. > > > > If they do, it should be explicitly stated so in the spec, so that > > >designers > > > > are not misguided to apply solutions to cases for which they are not > > > > designed. > > > > > >Nobody's ignoring any use cases. But if you focus on one sample to the > > >detriment of the rest, it will cripple your solution. > > > > > > Regards, > > > Henrik > > > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world’s largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:57:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11662 for ; Wed, 27 Mar 2002 12:57:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22284; Wed, 27 Mar 2002 12:51:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22206 for ; Wed, 27 Mar 2002 12:51:33 -0500 (EST) Received: from hotmail.com (f161.law9.hotmail.com [64.4.9.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11139 for ; Wed, 27 Mar 2002 12:51:32 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:51:03 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:51:03 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 12:51:03 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:51:03.0297 (UTC) FILETIME=[F66A2F10:01C1D5B7] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > GT> Personally i do not own or have any cellular deployment so it is > > certainly not mine :-) But seriously, how does it work in > > cdma? what I said > > probably applies to tdma systems I guess? > >=> Well, the only difference is that the AR coverage >area includes several APs, so it's very unlikely >that you would end up with 6 GAARs in the same >technology. [Govind] Well one example could be in a large mall or airport wherein you have different APs connected to different providers (at least three of them can be in a vicinity according to the 802.11 spec). Second, the number of different APs gets multiplied by the number of interface cards the MN has. Also a question, even if the APs belong to the same AR. Could you verify that just by looking at the L2 beacon or do you have to connect to them first and then to the associated AR first to determine that? _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:57:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11673 for ; Wed, 27 Mar 2002 12:57:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23287 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:57:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22284; Wed, 27 Mar 2002 12:51:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22206 for ; Wed, 27 Mar 2002 12:51:33 -0500 (EST) Received: from hotmail.com (f161.law9.hotmail.com [64.4.9.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11139 for ; Wed, 27 Mar 2002 12:51:32 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:51:03 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:51:03 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 12:51:03 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:51:03.0297 (UTC) FILETIME=[F66A2F10:01C1D5B7] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > GT> Personally i do not own or have any cellular deployment so it is > > certainly not mine :-) But seriously, how does it work in > > cdma? what I said > > probably applies to tdma systems I guess? > >=> Well, the only difference is that the AR coverage >area includes several APs, so it's very unlikely >that you would end up with 6 GAARs in the same >technology. [Govind] Well one example could be in a large mall or airport wherein you have different APs connected to different providers (at least three of them can be in a vicinity according to the 802.11 spec). Second, the number of different APs gets multiplied by the number of interface cards the MN has. Also a question, even if the APs belong to the same AR. Could you verify that just by looking at the L2 beacon or do you have to connect to them first and then to the associated AR first to determine that? _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:57:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11723 for ; Wed, 27 Mar 2002 12:57:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22350; Wed, 27 Mar 2002 12:52:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22323 for ; Wed, 27 Mar 2002 12:52:05 -0500 (EST) Received: from hotmail.com (f267.law7.hotmail.com [216.33.236.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11160 for ; Wed, 27 Mar 2002 12:52:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:51:30 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:51:30 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:51:30 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:51:30.0362 (UTC) FILETIME=[068BF9A0:01C1D5B8] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Then you cannot make requirements for specific special cases. If you want to solve general case, you must consider impact of requirements for that general case on all special cases, at least the harmful part of it. >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 17:47:30 +0100 > >Oh, this is interesting. I advocate solving the general case, and >you interpret that as another particular case. > >Well, anyway, I advocate solving the general case, in case that did >not come across clearly. > > Best regards, > Henrik > > > > > Hi Henrik: > > > > ------------------snip--------------------------- > > > > >Neither. > > > > > >The "one access technology case" is the case where your mobile node >only > > >has one access technology, i.e. only one interface, and will not have >more. > > > > > >Designing for this case in particular, instead of designing for the >general > > >case with multiple interfaces and technologies, will cripple our >solution. > > > > > >Designing for the general case will permit handling this special case, > > >and many many others. > > > > > > [HC] I totally agree with your statement that we should list >requirements > > for general case. But that is not what is happening here. Here >requirements > > seem to be being formulated around a specific case of "two interface, >both > > awake, no power constraint" case, without considering their impact on >other > > cases. > > > > BR, > > Hemant > > > > > > > > > > Regards, > > > Henrik > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:57:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11737 for ; Wed, 27 Mar 2002 12:57:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23406 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:57:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22350; Wed, 27 Mar 2002 12:52:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22323 for ; Wed, 27 Mar 2002 12:52:05 -0500 (EST) Received: from hotmail.com (f267.law7.hotmail.com [216.33.236.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11160 for ; Wed, 27 Mar 2002 12:52:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:51:30 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:51:30 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 17:51:30 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:51:30.0362 (UTC) FILETIME=[068BF9A0:01C1D5B8] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Then you cannot make requirements for specific special cases. If you want to solve general case, you must consider impact of requirements for that general case on all special cases, at least the harmful part of it. >From: "Henrik Levkowetz" >To: "Hemant Chaskar" , >Subject: RE: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 17:47:30 +0100 > >Oh, this is interesting. I advocate solving the general case, and >you interpret that as another particular case. > >Well, anyway, I advocate solving the general case, in case that did >not come across clearly. > > Best regards, > Henrik > > > > > Hi Henrik: > > > > ------------------snip--------------------------- > > > > >Neither. > > > > > >The "one access technology case" is the case where your mobile node >only > > >has one access technology, i.e. only one interface, and will not have >more. > > > > > >Designing for this case in particular, instead of designing for the >general > > >case with multiple interfaces and technologies, will cripple our >solution. > > > > > >Designing for the general case will permit handling this special case, > > >and many many others. > > > > > > [HC] I totally agree with your statement that we should list >requirements > > for general case. But that is not what is happening here. Here >requirements > > seem to be being formulated around a specific case of "two interface, >both > > awake, no power constraint" case, without considering their impact on >other > > cases. > > > > BR, > > Hemant > > > > > > > > > > Regards, > > > Henrik > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:58:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11806 for ; Wed, 27 Mar 2002 12:58:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23196; Wed, 27 Mar 2002 12:56:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23161 for ; Wed, 27 Mar 2002 12:56:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11570 for ; Wed, 27 Mar 2002 12:56:04 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RHtWI07633; Wed, 27 Mar 2002 09:55:32 -0800 (PST) Message-ID: <017501c1d5b8$5d7dd170$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 09:53:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > [DOT] Can you explain to me where requirement 3.4 states that AR is in control? > You should realize that the expression of requirements to do the job of CAR > discovery is simply necessary to do the matching. Even if the MN is doing > the matching, you still needs means to express requirements. > Here's the requirement: The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. There is not one single mention of the MN in this requirement. How can you interpret that this requirement does NOT put the AR in control? This is exactly the message Steve Deering was trying to get across in the Minne-apple. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:58:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11816 for ; Wed, 27 Mar 2002 12:58:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23468 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:58:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23196; Wed, 27 Mar 2002 12:56:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23161 for ; Wed, 27 Mar 2002 12:56:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11570 for ; Wed, 27 Mar 2002 12:56:04 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RHtWI07633; Wed, 27 Mar 2002 09:55:32 -0800 (PST) Message-ID: <017501c1d5b8$5d7dd170$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 09:53:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > [DOT] Can you explain to me where requirement 3.4 states that AR is in control? > You should realize that the expression of requirements to do the job of CAR > discovery is simply necessary to do the matching. Even if the MN is doing > the matching, you still needs means to express requirements. > Here's the requirement: The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. There is not one single mention of the MN in this requirement. How can you interpret that this requirement does NOT put the AR in control? This is exactly the message Steve Deering was trying to get across in the Minne-apple. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 12:59:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11932 for ; Wed, 27 Mar 2002 12:59:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22937; Wed, 27 Mar 2002 12:54:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22903 for ; Wed, 27 Mar 2002 12:53:58 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11300 for ; Wed, 27 Mar 2002 12:53:57 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RHqqI07549; Wed, 27 Mar 2002 09:52:52 -0800 (PST) Message-ID: <016d01c1d5b7$fe79ef60$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 09:51:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, And I pointed out the flaw in Hemant's argument: premature optimization. The requirements are supposed to say what the protocol will do, not specify it in detail. We need a strong statement that it is MN centered. Later, there may be need for optimization, but if we put the optimization in up front, we constrain the solution too much or open it up to nonviable solutions. I also have a hard time buying that there will be sooo much GAAR information. We are not talking about a complete list of the NASDAQ here, just whatever routers happen to be in the vicinity. jak ----- Original Message ----- From: To: ; Sent: Wednesday, March 27, 2002 7:48 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi all, > > just to have another opinion on record. > > Firstly, I disagree with keeping the requirement in the current wording. Hemant > already pointed out the major flaw of this requirement, namely the > pushing of unnecessary information to the MN. James comment about > "keeping it simple" neglects a simple fact. It is not about making it > more complicated (how, just by adding "if required"???), it is about > avoiding unnecessary flooding and therefore wasting power of the MN for > receiving information it does not need or, even worse, does not want. > > Secondly, I even stronger disagree with REPLACING requirement 3.4 with > this requirement, even in a re-worded manner. Requirement 3.4 deals with > a different problem, namely the expression of MN requirements. Even though > some people apparently think that this involves complicated AAA transactions > (let's simply see what the solutions will bring), it just actually says that > you need ANY means to express what the MN's requirements are. This is even > important in an MN-based case, which could be realized in a simple user interface > or something else. The proposed requirement though deals with information provision. > Even if you get the information at the MN, you still need means to express your > requirements so that you can do the match from GAARs to CARs. > > Regards, > > > Dirk > > > -----Original Message----- > From: ext Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Tuesday, March 26, 2002 8:10 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (was: Examples of CAR discovery) > > > Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR > information, it does not require *on-demand operation*, it expresses exactly > what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > Henrik > > Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this requirement. > > They are described below. How can we finalise this requirement unless it is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering design, > > namely efficiency. The solution satisfying this requirement is obliged to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case (i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > > power wastage. This is because, after receiving these capabilities MN either > > rejects the new AR (which is worst), and even if it selcects one why does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement that > > you proposed and who have not, we should first analyse above harmful effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 12:59:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11944 for ; Wed, 27 Mar 2002 12:59:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23557 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 12:59:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22937; Wed, 27 Mar 2002 12:54:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22903 for ; Wed, 27 Mar 2002 12:53:58 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11300 for ; Wed, 27 Mar 2002 12:53:57 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RHqqI07549; Wed, 27 Mar 2002 09:52:52 -0800 (PST) Message-ID: <016d01c1d5b7$fe79ef60$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 09:51:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, And I pointed out the flaw in Hemant's argument: premature optimization. The requirements are supposed to say what the protocol will do, not specify it in detail. We need a strong statement that it is MN centered. Later, there may be need for optimization, but if we put the optimization in up front, we constrain the solution too much or open it up to nonviable solutions. I also have a hard time buying that there will be sooo much GAAR information. We are not talking about a complete list of the NASDAQ here, just whatever routers happen to be in the vicinity. jak ----- Original Message ----- From: To: ; Sent: Wednesday, March 27, 2002 7:48 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi all, > > just to have another opinion on record. > > Firstly, I disagree with keeping the requirement in the current wording. Hemant > already pointed out the major flaw of this requirement, namely the > pushing of unnecessary information to the MN. James comment about > "keeping it simple" neglects a simple fact. It is not about making it > more complicated (how, just by adding "if required"???), it is about > avoiding unnecessary flooding and therefore wasting power of the MN for > receiving information it does not need or, even worse, does not want. > > Secondly, I even stronger disagree with REPLACING requirement 3.4 with > this requirement, even in a re-worded manner. Requirement 3.4 deals with > a different problem, namely the expression of MN requirements. Even though > some people apparently think that this involves complicated AAA transactions > (let's simply see what the solutions will bring), it just actually says that > you need ANY means to express what the MN's requirements are. This is even > important in an MN-based case, which could be realized in a simple user interface > or something else. The proposed requirement though deals with information provision. > Even if you get the information at the MN, you still need means to express your > requirements so that you can do the match from GAARs to CARs. > > Regards, > > > Dirk > > > -----Original Message----- > From: ext Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Tuesday, March 26, 2002 8:10 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (was: Examples of CAR discovery) > > > Hemant, > > You apparently did not read my recent posting. Cut'n'Paste: > > No, the requirement is just fine. It does not require *all* GAAR > information, it does not require *on-demand operation*, it expresses exactly > what we are in a position to say about the matter now: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > > > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > Henrik > > Hemant wrote: > > > > Hi James: > > > > There are serious shortcomings of the solution satisfying this requirement. > > They are described below. How can we finalise this requirement unless it is > > agreed that these pitfalls do not exist? > > > > For this, it might be good idea to visualise how the solution satisfying > > this requirement looks like and violates basic tenets of engineering design, > > namely efficiency. The solution satisfying this requirement is obliged to > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might be a > > big chunk of data (= number of GAARs times capability set of each). This > > flood will occur either on active traffic connection which I call case (i) > > (relevant for single interface MN and two-interface MN where second > > interface is sleeping) or on second interface which I call case (ii) > > (relevant for two interface MN with both interfaces awake). There are > > following effects of this flood: > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic over > > active traffic channel. > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood causes > > power wastage. This is because, after receiving these capabilities MN either > > rejects the new AR (which is worst), and even if it selcects one why does it > > need to receive capabilities of GAARs that do not matter for it. > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > sees. Which means the same information (which could be big enough) is > > transmitted on downlink so many times. This takes up considerable fraction > > of downlink capacity. > > > > 4. Limit on capability definition: This requirement restricts the definition > > of capabilities to a very small size, otherwise all ARs will only be > > transmitting GAAR capabilities to different MNs all the time. This means > > capability set cannot be comprehensive and extensible. > > > > So, IMHO rather than counting who agrees to one statement requirement that > > you proposed and who have not, we should first analyse above harmful effects > > before deciding either way. > > > > Br, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Govind Krishnamurthi" , > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement (was: > > >Examples of CAR discovery) > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > >, > > > > So now you agree that the AR can hand over the list of GAARs and > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > the MN requirements, which is what CAR discovery was originally > > >about). > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > >requirement I would like to see (and Henrik apparently agrees) so we are > > >clear on this: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > > Which first implies that the network is taking care of CAR discovery. > > > > This seems contradictory to your earlier mails saying that there is > > > > no basis for network based CAR discovery. So are you now agreeing > > > > that network based CAR discovery has its place? > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > >the MN to discover the GAAR and capabilities, the MN decides which one > > >it wants. > > >Nothing about the AR in control of anything. The MN may use a variant of > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > >protocol design, not a requirement, choice. The requirement is clearly > > >that the MN does the discovery. > > > > > >We now have two working group members who want this reqirement worded > > >just this way. Nothing about "as the MN expresses its preferences" or > > >"by the CAR discovery module" or anything else. And I believe Hesham has > > >also expressed a preference for this requirement. > > > > > >Anybody else out there have an opinion on this? Should we include this > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > jak > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:01:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12054 for ; Wed, 27 Mar 2002 13:01:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23075; Wed, 27 Mar 2002 12:55:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23031 for ; Wed, 27 Mar 2002 12:54:57 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11394 for ; Wed, 27 Mar 2002 12:54:56 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RHsvoq009322 for ; Wed, 27 Mar 2002 18:54:57 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 18:54:44 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:44:37 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB9E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:54:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > => Well, the only difference is that the AR coverage > area includes several APs, so it's very unlikely > that you would end up with 6 GAARs in the same > technology. > > GT> I see, I guess because of soft handoff in cdma. But then, in > environments that can actually utilize an AR per BS/AP it > is possible to > have multiple GAARs even if you restrict this to a single > technology. So the > concern that some people have about GAAR+capabilities list > is not totally > unfounded, wouldn't you say?. > => Right, but if we restrict it to a single technology within one operator's network, then it should be fairly simple for the AR to send only one or two GAAR info. I still think that in this scenario it would be difficult to get 6 different GAARs that the MN can choose from, given that the MN is moving a certain direction. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:04:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12248 for ; Wed, 27 Mar 2002 13:04:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22440; Wed, 27 Mar 2002 12:52:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22398 for ; Wed, 27 Mar 2002 12:52:39 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11197 for ; Wed, 27 Mar 2002 12:52:38 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RHqdkY011880 for ; Wed, 27 Mar 2002 18:52:39 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 18:52:37 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:42:29 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB9D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:52:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA22399 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit > I do not know what consensus you are talking about. There > was one question > asked which was not clearly stated, and for that too, I saw > only three hands > go up. => We must have been in different meetings :) I vividly remember James asking people whether the model Steve presented made more sense than the current assumptions, and almost all hands went up. In fact Michael even said that he and Dana Blair presented the same model a year ago and there was no interest in the WG and he wondered why the sudden change ? So I don't know what you're referring to really. Perhaps we should wait for the minutes. Hesham > > The requirement was posted after MPLS and there has not > been any consensus > on it yet. > > What we have agreed in MPLS was "MN's requirements MUST be > considered in CAR > discovery, handoffs etc.". We all are in good agreement on that. > > I don't think however that this means that it precludes > executing processor > level algorithms anywhere else than MN's processor, as long > as those > algorithms consider all MN's requirement. This is > implementation-specific > aspect. > > More comments below. > > Hemant > > > >From: "Hesham Soliman (ERA)" > >To: "'Hemant Chaskar'" , "Hesham > Soliman (ERA)" > >, G.Tsirtsis@flarion.com, > >seamoby@ietf.org > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement (wa > >s: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 17:45:52 +0100 > > > >Hi Hemant, > > > > > No RA is not what blasting is about. What this requirement > > > is saying is to > > > send to MN a volume of data = Number of GAARs times > > > capability set of each. > > > Number of GAARs itself could be large and capability set > > > could be very large > > > too. It might contain policies, supported IP protocols, any > > > application > > > specific functionality support and this set could be > extensible. > > > >=> This is all based on an assumption: The scope > >of the GAAR discovery will scale to a very large number of GAARs. > > [HC] What matters here is the product of number of GAARs > and size of their > capabilities". Even if you do not have large number of > GAARs, capabilities > of each one of them can be huge and extensible. > > > >I don't think this is realistic, and after Steve's presentation > >I thought the entire WG agreed with this. > >Why are we trying to reverse this concensus? > > > > > > > > Sending this volume of data to MN without any regard to > > > whether it wants it > > > or not is what I call blasting. > > > >=> See above. > > > >Hesham > > > > > > > > Hemant > > > > > > >From: "Hesham Soliman (ERA)" > > > >To: "'George Tsirtsis'" , > > > "'Hemant Chaskar'" > > > >, seamoby@ietf.org > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement (wa > > > >s: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 17:32:30 +0100 > > > > > > > >What is iths blöasting that people keep > > > >bringing up? an extra option in an RA is blasting ???? > > > >What is the alternative: The magic AR that knows > > > >everything ?????????????? > > > > > > > >Seriously, let's keep it simple or this whole > > > >protocol will start collapsing the moment > > > >anyone starts deploying it. Of course if deployment > > > >is not a concern then I'll just og back to sleep! > > > > > > > >Hesham > > > > > > > > > -----Original Message----- > > > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > > > Subject: RE: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > (wa s: Examples of CAR discovery) > > > > > > > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > > > GAAR IDs and all of > > > > > their capabilities to MN" is a good idea? If > not (which I > > > > > hope so) then the > > > > > requirements document should not imply otherwise. > > > > > > > > > > George > > > > > > > > > > -----Original Message----- > > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > > > To: seamoby@ietf.org > > > > > Subject: RE: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > (was: Examples of CAR discovery) > > > > > > > > > > > > > > > Hi Hernik: > > > > > > > > > > I did read your comment and responded as follows in my > > > > > earlier email. > > > > > Cut'n'Paste: > > > > > > > > > > ------------------------------- > > > > > If we honestly think that the requirement does > not oblige > > > > > AR to blast all > > > > > GAAR IDs and all of their capabilities to MN, > why not say > > > > > so clearly. Why do > > > > > > > > > > we need to hide this fact? We can come up with something > > > > > else, if you do not > > > > > > > > > > like on-demand extension. I think without such extension > > > > > the solution > > > > > satisfying this requirement may have serious > shortcomings > > > > > that I described > > > > > in my other email to James. > > > > > -------------------------------- > > > > > > > > > > BR, > > > > > Hemant > > > > > > > > > > > > > > > >From: "Henrik Levkowetz" > > > > > >To: "Hemant Chaskar" > > > > > >Subject: RE: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > >(was: Examples of CAR discovery) > > > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > > > > > >Hemant, > > > > > > > > > > > > You apparently did not read my recent posting. > > > Cut'n'Paste: > > > > > > > > > > > > No, the requirement is just fine. It does not > > > require *all* GAAR > > > > > >information, it does not require *on-demand > operation*, it > > > > > expresses > > > > > >exactly > > > > > >what we are in a position to say about the matter now: > > > > > > > > > > > > The CAR discovery protocol MUST provide > the MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > I think that's the essence of it. Do > you oppose this? > > > > > Why? Do you > > > > > >want to make things more complicated than they > have to be? > > > > > > > > > > > > Henrik > > > > > > > > > > > >Hemant wrote: > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > > > There are serious shortcomings of the solution > > > satisfying this > > > > > >requirement. > > > > > > > They are described below. How can we finalise this > > > > > requirement unless it > > > > > > > > > > >is > > > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > > > > > For this, it might be good idea to visualise how the > > > > > solution satisfying > > > > > > > this requirement looks like and violates > basic tenets > > > > > of engineering > > > > > >design, > > > > > > > namely efficiency. The solution satisfying this > > > > > requirement is obliged > > > > > >to > > > > > > > blast GAAR IDs and their capabilities on MN when AR > > > > > sees MN. This might > > > > > >be a > > > > > > > big chunk of data (= number of GAARs times > capability > > > > > set of each). This > > > > > > > flood will occur either on active traffic connection > > > > > which I call case > > > > > >(i) > > > > > > > (relevant for single interface MN and > two-interface MN > > > > > where second > > > > > > > interface is sleeping) or on second > interface which I > > > > > call case (ii) > > > > > > > (relevant for two interface MN with both interfaces > > > > > awake). There are > > > > > > > following effects of this flood: > > > > > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > > > disruption in traffic > > > > > >over > > > > > > > active traffic channel. > > > > > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > > > receiving this flood > > > > > >causes > > > > > > > power wastage. This is because, after > receiving these > > > > > capabilities MN > > > > > >either > > > > > > > rejects the new AR (which is worst), and even if it > > > > > selcects one why > > > > > >does it > > > > > > > need to receive capabilities of GAARs that do not > > > matter for it. > > > > > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send > this flood to > > > > > every MN that it > > > > > > > sees. Which means the same information > (which could be > > > > > big enough) is > > > > > > > transmitted on downlink so many times. This takes up > > > > > considerable > > > > > >fraction > > > > > > > of downlink capacity. > > > > > > > > > > > > > > 4. Limit on capability definition: This requirement > > > > > restricts the > > > > > >definition > > > > > > > of capabilities to a very small size, > otherwise all ARs > > > > > will only be > > > > > > > transmitting GAAR capabilities to different > MNs all the > > > > > time. This means > > > > > > > capability set cannot be comprehensive and > extensible. > > > > > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > > > statement requirement > > > > > >that > > > > > > > you proposed and who have not, we should > first analyse > > > > > above harmful > > > > > >effects > > > > > > > before deciding either way. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > > > > > >Subject: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > >(was: > > > > > > > >Examples of CAR discovery) > > > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > > > > > >, > > > > > > > > > So now you agree that the AR can hand > over the list > > > > > of GAARs and > > > > > > > > > their capabilities to the MN (maybe only pass on > > > > > those which satisfy > > > > > > > > > the MN requirements, which is what CAR discovery > > > > > was originally > > > > > > > >about). > > > > > > > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > > > Let me repeat the > > > > > > > >requirement I would like to see (and > Henrik apparently > > > > > agrees) so we > > > > > >are > > > > > > > >clear on this: > > > > > > > > > > > > > > > > The CAR discovery protocol MUST provide the > > > MN with GAAR > > > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > > > > > > > Which first implies that the network is > > > taking care of CAR > > > > > >discovery. > > > > > > > > > This seems contradictory to your earlier mails > > > > > saying that there is > > > > > > > > > no basis for network based CAR discovery. So are > > > > > you now agreeing > > > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > > > The protocol allows > > > > > > > >the MN to discover the GAAR and > capabilities, the MN > > > > > decides which one > > > > > > > >it wants. > > > > > > > >Nothing about the AR in control of anything. The MN > > > > > may use a variant > > > > > >of > > > > > > > >IPv6 neighbor discovery, the AR may be involved > > > > > somehow, but that's a > > > > > > > >protocol design, not a requirement, choice. The > > > > > requirement is clearly > > > > > > > >that the MN does the discovery. > > > > > > > > > > > > > > > >We now have two working group members who want this > > > > > reqirement worded > > > > > > > >just this way. Nothing about "as the MN > expresses its > > > > > preferences" or > > > > > > > >"by the CAR discovery module" or anything > else. And I > > > > > believe Hesham > > > > > >has > > > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > > > > > >Anybody else out there have an opinion on > this? Should > > > > > we include this > > > > > > > >requirement instead of requirement 3.4, > which has the > > > > > AR in control? > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > >Seamoby mailing list > > > > > > > >Seamoby@ietf.org > > > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > MSN Photos is the easiest way to share and print > > > your photos: > > > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Seamoby mailing list > > > > > > > Seamoby@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Join the world's largest e-mail service with > MSN Hotmail. > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: > >http://messenger.msn.com > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:04:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12259 for ; Wed, 27 Mar 2002 13:04:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24348 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:04:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22440; Wed, 27 Mar 2002 12:52:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22398 for ; Wed, 27 Mar 2002 12:52:39 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11197 for ; Wed, 27 Mar 2002 12:52:38 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RHqdkY011880 for ; Wed, 27 Mar 2002 18:52:39 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 18:52:37 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:42:29 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB9D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , G.Tsirtsis@flarion.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:52:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA22399 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit > I do not know what consensus you are talking about. There > was one question > asked which was not clearly stated, and for that too, I saw > only three hands > go up. => We must have been in different meetings :) I vividly remember James asking people whether the model Steve presented made more sense than the current assumptions, and almost all hands went up. In fact Michael even said that he and Dana Blair presented the same model a year ago and there was no interest in the WG and he wondered why the sudden change ? So I don't know what you're referring to really. Perhaps we should wait for the minutes. Hesham > > The requirement was posted after MPLS and there has not > been any consensus > on it yet. > > What we have agreed in MPLS was "MN's requirements MUST be > considered in CAR > discovery, handoffs etc.". We all are in good agreement on that. > > I don't think however that this means that it precludes > executing processor > level algorithms anywhere else than MN's processor, as long > as those > algorithms consider all MN's requirement. This is > implementation-specific > aspect. > > More comments below. > > Hemant > > > >From: "Hesham Soliman (ERA)" > >To: "'Hemant Chaskar'" , "Hesham > Soliman (ERA)" > >, G.Tsirtsis@flarion.com, > >seamoby@ietf.org > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > Requirement (wa > >s: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 17:45:52 +0100 > > > >Hi Hemant, > > > > > No RA is not what blasting is about. What this requirement > > > is saying is to > > > send to MN a volume of data = Number of GAARs times > > > capability set of each. > > > Number of GAARs itself could be large and capability set > > > could be very large > > > too. It might contain policies, supported IP protocols, any > > > application > > > specific functionality support and this set could be > extensible. > > > >=> This is all based on an assumption: The scope > >of the GAAR discovery will scale to a very large number of GAARs. > > [HC] What matters here is the product of number of GAARs > and size of their > capabilities". Even if you do not have large number of > GAARs, capabilities > of each one of them can be huge and extensible. > > > >I don't think this is realistic, and after Steve's presentation > >I thought the entire WG agreed with this. > >Why are we trying to reverse this concensus? > > > > > > > > Sending this volume of data to MN without any regard to > > > whether it wants it > > > or not is what I call blasting. > > > >=> See above. > > > >Hesham > > > > > > > > Hemant > > > > > > >From: "Hesham Soliman (ERA)" > > > >To: "'George Tsirtsis'" , > > > "'Hemant Chaskar'" > > > >, seamoby@ietf.org > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > Requirement (wa > > > >s: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 17:32:30 +0100 > > > > > > > >What is iths blöasting that people keep > > > >bringing up? an extra option in an RA is blasting ???? > > > >What is the alternative: The magic AR that knows > > > >everything ?????????????? > > > > > > > >Seriously, let's keep it simple or this whole > > > >protocol will start collapsing the moment > > > >anyone starts deploying it. Of course if deployment > > > >is not a concern then I'll just og back to sleep! > > > > > > > >Hesham > > > > > > > > > -----Original Message----- > > > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > > > Subject: RE: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > (wa s: Examples of CAR discovery) > > > > > > > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > > > GAAR IDs and all of > > > > > their capabilities to MN" is a good idea? If > not (which I > > > > > hope so) then the > > > > > requirements document should not imply otherwise. > > > > > > > > > > George > > > > > > > > > > -----Original Message----- > > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > > > To: seamoby@ietf.org > > > > > Subject: RE: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > (was: Examples of CAR discovery) > > > > > > > > > > > > > > > Hi Hernik: > > > > > > > > > > I did read your comment and responded as follows in my > > > > > earlier email. > > > > > Cut'n'Paste: > > > > > > > > > > ------------------------------- > > > > > If we honestly think that the requirement does > not oblige > > > > > AR to blast all > > > > > GAAR IDs and all of their capabilities to MN, > why not say > > > > > so clearly. Why do > > > > > > > > > > we need to hide this fact? We can come up with something > > > > > else, if you do not > > > > > > > > > > like on-demand extension. I think without such extension > > > > > the solution > > > > > satisfying this requirement may have serious > shortcomings > > > > > that I described > > > > > in my other email to James. > > > > > -------------------------------- > > > > > > > > > > BR, > > > > > Hemant > > > > > > > > > > > > > > > >From: "Henrik Levkowetz" > > > > > >To: "Hemant Chaskar" > > > > > >Subject: RE: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > >(was: Examples of CAR discovery) > > > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > > > > > >Hemant, > > > > > > > > > > > > You apparently did not read my recent posting. > > > Cut'n'Paste: > > > > > > > > > > > > No, the requirement is just fine. It does not > > > require *all* GAAR > > > > > >information, it does not require *on-demand > operation*, it > > > > > expresses > > > > > >exactly > > > > > >what we are in a position to say about the matter now: > > > > > > > > > > > > The CAR discovery protocol MUST provide > the MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > I think that's the essence of it. Do > you oppose this? > > > > > Why? Do you > > > > > >want to make things more complicated than they > have to be? > > > > > > > > > > > > Henrik > > > > > > > > > > > >Hemant wrote: > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > > > There are serious shortcomings of the solution > > > satisfying this > > > > > >requirement. > > > > > > > They are described below. How can we finalise this > > > > > requirement unless it > > > > > > > > > > >is > > > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > > > > > For this, it might be good idea to visualise how the > > > > > solution satisfying > > > > > > > this requirement looks like and violates > basic tenets > > > > > of engineering > > > > > >design, > > > > > > > namely efficiency. The solution satisfying this > > > > > requirement is obliged > > > > > >to > > > > > > > blast GAAR IDs and their capabilities on MN when AR > > > > > sees MN. This might > > > > > >be a > > > > > > > big chunk of data (= number of GAARs times > capability > > > > > set of each). This > > > > > > > flood will occur either on active traffic connection > > > > > which I call case > > > > > >(i) > > > > > > > (relevant for single interface MN and > two-interface MN > > > > > where second > > > > > > > interface is sleeping) or on second > interface which I > > > > > call case (ii) > > > > > > > (relevant for two interface MN with both interfaces > > > > > awake). There are > > > > > > > following effects of this flood: > > > > > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > > > disruption in traffic > > > > > >over > > > > > > > active traffic channel. > > > > > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > > > receiving this flood > > > > > >causes > > > > > > > power wastage. This is because, after > receiving these > > > > > capabilities MN > > > > > >either > > > > > > > rejects the new AR (which is worst), and even if it > > > > > selcects one why > > > > > >does it > > > > > > > need to receive capabilities of GAARs that do not > > > matter for it. > > > > > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send > this flood to > > > > > every MN that it > > > > > > > sees. Which means the same information > (which could be > > > > > big enough) is > > > > > > > transmitted on downlink so many times. This takes up > > > > > considerable > > > > > >fraction > > > > > > > of downlink capacity. > > > > > > > > > > > > > > 4. Limit on capability definition: This requirement > > > > > restricts the > > > > > >definition > > > > > > > of capabilities to a very small size, > otherwise all ARs > > > > > will only be > > > > > > > transmitting GAAR capabilities to different > MNs all the > > > > > time. This means > > > > > > > capability set cannot be comprehensive and > extensible. > > > > > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > > > statement requirement > > > > > >that > > > > > > > you proposed and who have not, we should > first analyse > > > > > above harmful > > > > > >effects > > > > > > > before deciding either way. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > > > > > >Subject: [Seamoby] Concensus call on new > CAR Discovery > > > > > Requirement > > > > > >(was: > > > > > > > >Examples of CAR discovery) > > > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > > > > > >, > > > > > > > > > So now you agree that the AR can hand > over the list > > > > > of GAARs and > > > > > > > > > their capabilities to the MN (maybe only pass on > > > > > those which satisfy > > > > > > > > > the MN requirements, which is what CAR discovery > > > > > was originally > > > > > > > >about). > > > > > > > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > > > Let me repeat the > > > > > > > >requirement I would like to see (and > Henrik apparently > > > > > agrees) so we > > > > > >are > > > > > > > >clear on this: > > > > > > > > > > > > > > > > The CAR discovery protocol MUST provide the > > > MN with GAAR > > > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > > > > > > > Which first implies that the network is > > > taking care of CAR > > > > > >discovery. > > > > > > > > > This seems contradictory to your earlier mails > > > > > saying that there is > > > > > > > > > no basis for network based CAR discovery. So are > > > > > you now agreeing > > > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > > > The protocol allows > > > > > > > >the MN to discover the GAAR and > capabilities, the MN > > > > > decides which one > > > > > > > >it wants. > > > > > > > >Nothing about the AR in control of anything. The MN > > > > > may use a variant > > > > > >of > > > > > > > >IPv6 neighbor discovery, the AR may be involved > > > > > somehow, but that's a > > > > > > > >protocol design, not a requirement, choice. The > > > > > requirement is clearly > > > > > > > >that the MN does the discovery. > > > > > > > > > > > > > > > >We now have two working group members who want this > > > > > reqirement worded > > > > > > > >just this way. Nothing about "as the MN > expresses its > > > > > preferences" or > > > > > > > >"by the CAR discovery module" or anything > else. And I > > > > > believe Hesham > > > > > >has > > > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > > > > > >Anybody else out there have an opinion on > this? Should > > > > > we include this > > > > > > > >requirement instead of requirement 3.4, > which has the > > > > > AR in control? > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > >Seamoby mailing list > > > > > > > >Seamoby@ietf.org > > > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > MSN Photos is the easiest way to share and print > > > your photos: > > > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Seamoby mailing list > > > > > > > Seamoby@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Join the world's largest e-mail service with > MSN Hotmail. > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: > >http://messenger.msn.com > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:05:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12345 for ; Wed, 27 Mar 2002 13:05:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23514; Wed, 27 Mar 2002 12:59:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23485 for ; Wed, 27 Mar 2002 12:59:10 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11858 for ; Wed, 27 Mar 2002 12:59:08 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id SAA28071; Wed, 27 Mar 2002 18:55:55 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 18:58:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Sure. Glad you agree. Henrik Hemant wrote: > > Then you cannot make requirements for specific special cases. If you want to > solve general case, you must consider impact of requirements for that > general case on all special cases, at least the harmful part of it. > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" , > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Wed, 27 Mar 2002 17:47:30 +0100 > > > >Oh, this is interesting. I advocate solving the general case, and > >you interpret that as another particular case. > > > >Well, anyway, I advocate solving the general case, in case that did > >not come across clearly. > > > > Best regards, > > Henrik > > > > > > > > Hi Henrik: > > > > > > ------------------snip--------------------------- > > > > > > >Neither. > > > > > > > >The "one access technology case" is the case where your mobile node > >only > > > >has one access technology, i.e. only one interface, and will not have > >more. > > > > > > > >Designing for this case in particular, instead of designing for the > >general > > > >case with multiple interfaces and technologies, will cripple our > >solution. > > > > > > > >Designing for the general case will permit handling this special case, > > > >and many many others. > > > > > > > > > [HC] I totally agree with your statement that we should list > >requirements > > > for general case. But that is not what is happening here. Here > >requirements > > > seem to be being formulated around a specific case of "two interface, > >both > > > awake, no power constraint" case, without considering their impact on > >other > > > cases. > > > > > > BR, > > > Hemant > > > > > > > > > > > > > > Regards, > > > > Henrik > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:05:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12353 for ; Wed, 27 Mar 2002 13:05:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24523 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:05:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23514; Wed, 27 Mar 2002 12:59:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23485 for ; Wed, 27 Mar 2002 12:59:10 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11858 for ; Wed, 27 Mar 2002 12:59:08 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id SAA28071; Wed, 27 Mar 2002 18:55:55 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 18:58:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Sure. Glad you agree. Henrik Hemant wrote: > > Then you cannot make requirements for specific special cases. If you want to > solve general case, you must consider impact of requirements for that > general case on all special cases, at least the harmful part of it. > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" , > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Wed, 27 Mar 2002 17:47:30 +0100 > > > >Oh, this is interesting. I advocate solving the general case, and > >you interpret that as another particular case. > > > >Well, anyway, I advocate solving the general case, in case that did > >not come across clearly. > > > > Best regards, > > Henrik > > > > > > > > Hi Henrik: > > > > > > ------------------snip--------------------------- > > > > > > >Neither. > > > > > > > >The "one access technology case" is the case where your mobile node > >only > > > >has one access technology, i.e. only one interface, and will not have > >more. > > > > > > > >Designing for this case in particular, instead of designing for the > >general > > > >case with multiple interfaces and technologies, will cripple our > >solution. > > > > > > > >Designing for the general case will permit handling this special case, > > > >and many many others. > > > > > > > > > [HC] I totally agree with your statement that we should list > >requirements > > > for general case. But that is not what is happening here. Here > >requirements > > > seem to be being formulated around a specific case of "two interface, > >both > > > awake, no power constraint" case, without considering their impact on > >other > > > cases. > > > > > > BR, > > > Hemant > > > > > > > > > > > > > > Regards, > > > > Henrik > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:06:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12426 for ; Wed, 27 Mar 2002 13:06:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23997; Wed, 27 Mar 2002 13:01:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23965 for ; Wed, 27 Mar 2002 13:01:02 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12043 for ; Wed, 27 Mar 2002 13:01:01 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RI11oq010619 for ; Wed, 27 Mar 2002 19:01:01 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:01:00 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:00:59 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB9F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:00:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > GT> Personally i do not own or have any cellular > deployment so it is > > > certainly not mine :-) But seriously, how does it work in > > > cdma? what I said > > > probably applies to tdma systems I guess? > > > >=> Well, the only difference is that the AR coverage > >area includes several APs, so it's very unlikely > >that you would end up with 6 GAARs in the same > >technology. > > [Govind] Well one example could be in a large mall or airport > wherein you have > different APs connected to different providers (at least > three of them can > be in a vicinity according to the 802.11 spec). Second, the number > of different APs gets multiplied by the number of interface > cards the > MN has. => As I said, limit it to one operator. None of these issues will come up. I mean do you really believe that operators will give each other cost information ? Or do you believe that they will continuously update each other so honestly ? > Also a question, even if the APs belong to the same AR. > Could you verify > that just by looking at the L2 beacon or do you have to > connect to them > first and then to the associated AR first to determine that? => That's an interesting point. One thing you could do is solicit. The RTT for this is about 4 ms on WLAN. Another way is that there are options in 802.11 to include the network identity as part of the beacon. So there are different ways of handling it. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:06:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12448 for ; Wed, 27 Mar 2002 13:06:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24616 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:06:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23997; Wed, 27 Mar 2002 13:01:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23965 for ; Wed, 27 Mar 2002 13:01:02 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12043 for ; Wed, 27 Mar 2002 13:01:01 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RI11oq010619 for ; Wed, 27 Mar 2002 19:01:01 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:01:00 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:00:59 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB9F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:00:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > GT> Personally i do not own or have any cellular > deployment so it is > > > certainly not mine :-) But seriously, how does it work in > > > cdma? what I said > > > probably applies to tdma systems I guess? > > > >=> Well, the only difference is that the AR coverage > >area includes several APs, so it's very unlikely > >that you would end up with 6 GAARs in the same > >technology. > > [Govind] Well one example could be in a large mall or airport > wherein you have > different APs connected to different providers (at least > three of them can > be in a vicinity according to the 802.11 spec). Second, the number > of different APs gets multiplied by the number of interface > cards the > MN has. => As I said, limit it to one operator. None of these issues will come up. I mean do you really believe that operators will give each other cost information ? Or do you believe that they will continuously update each other so honestly ? > Also a question, even if the APs belong to the same AR. > Could you verify > that just by looking at the L2 beacon or do you have to > connect to them > first and then to the associated AR first to determine that? => That's an interesting point. One thing you could do is solicit. The RTT for this is about 4 ms on WLAN. Another way is that there are options in 802.11 to include the network identity as part of the beacon. So there are different ways of handling it. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:06:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12536 for ; Wed, 27 Mar 2002 13:06:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24110; Wed, 27 Mar 2002 13:01:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24073 for ; Wed, 27 Mar 2002 13:01:12 -0500 (EST) Received: from hotmail.com (f38.law7.hotmail.com [216.33.237.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12088 for ; Wed, 27 Mar 2002 13:01:07 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:00:38 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:00:38 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, govs23@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 18:00:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:00:38.0511 (UTC) FILETIME=[4D44DFF0:01C1D5B9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: Then that has to be there in requirements too. "CAR discovery solution MAY not consider more that two APs". Isn't it. What is the problem in not explicitly stating in the requirements what the requirements are about. Hemant >From: "Hesham Soliman (ERA)" >To: "'Govind Krishnamurthi'" , "Hesham Soliman >(ERA)" , seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of >Date: Wed, 27 Mar 2002 17:55:56 +0100 > > > Without knowing how many different GAARs are available (see > > Henriks mail > > about N interfaces) without knowing what the capabilities > > are I don't > > understand how you have come to the conclusion that the pushing > > the GAARs (all of them + their capabilities) to the MN is > > not blasting. > > >=> Because I'm narrowing the scope of AR-based >CAR to a couple of neighbouring routers within >the same domain and the access technology. >This is as far as it should go IMHO. >That is, if you expect it to be seriously >deployed. > >Hesham > > > > All we ask is the MN has an option to say no to this. > > Aren't you removing > > the MN's right not to want to proces this kind of information > > by saying that GAARs and their capabilities MUST be sent > > over to the MN? > > > > Govind. > > > > > >What is iths blöasting that people keep > > >bringing up? an extra option in an RA is blasting ???? > > >What is the alternative: The magic AR that knows > > >everything ?????????????? > > > > > >Seriously, let's keep it simple or this whole > > >protocol will start collapsing the moment > > >anyone starts deploying it. Of course if deployment > > >is not a concern then I'll just og back to sleep! > > > > > >Hesham > > > > > > > -----Original Message----- > > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (wa s: Examples of CAR discovery) > > > > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > > GAAR IDs and all of > > > > their capabilities to MN" is a good idea? If not (which I > > > > hope so) then the > > > > requirements document should not imply otherwise. > > > > > > > > George > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > > To: seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (was: Examples of CAR discovery) > > > > > > > > > > > > Hi Hernik: > > > > > > > > I did read your comment and responded as follows in my > > > > earlier email. > > > > Cut'n'Paste: > > > > > > > > ------------------------------- > > > > If we honestly think that the requirement does not oblige > > > > AR to blast all > > > > GAAR IDs and all of their capabilities to MN, why not say > > > > so clearly. Why do > > > > > > > > we need to hide this fact? We can come up with something > > > > else, if you do not > > > > > > > > like on-demand extension. I think without such extension > > > > the solution > > > > satisfying this requirement may have serious shortcomings > > > > that I described > > > > in my other email to James. > > > > -------------------------------- > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "Henrik Levkowetz" > > > > >To: "Hemant Chaskar" > > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: Examples of CAR discovery) > > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > > > >Hemant, > > > > > > > > > > You apparently did not read my recent posting. > > Cut'n'Paste: > > > > > > > > > > No, the requirement is just fine. It does not > > require *all* GAAR > > > > >information, it does not require *on-demand operation*, it > > > > expresses > > > > >exactly > > > > >what we are in a position to say about the matter now: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > > Why? Do you > > > > >want to make things more complicated than they have to be? > > > > > > > > > > Henrik > > > > > > > > > >Hemant wrote: > > > > > > > > > > > > Hi James: > > > > > > > > > > > > There are serious shortcomings of the solution > > satisfying this > > > > >requirement. > > > > > > They are described below. How can we finalise this > > > > requirement unless it > > > > > > > > >is > > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > > > For this, it might be good idea to visualise how the > > > > solution satisfying > > > > > > this requirement looks like and violates basic tenets > > > > of engineering > > > > >design, > > > > > > namely efficiency. The solution satisfying this > > > > requirement is obliged > > > > >to > > > > > > blast GAAR IDs and their capabilities on MN when AR > > > > sees MN. This might > > > > >be a > > > > > > big chunk of data (= number of GAARs times capability > > > > set of each). This > > > > > > flood will occur either on active traffic connection > > > > which I call case > > > > >(i) > > > > > > (relevant for single interface MN and two-interface MN > > > > where second > > > > > > interface is sleeping) or on second interface which I > > > > call case (ii) > > > > > > (relevant for two interface MN with both interfaces > > > > awake). There are > > > > > > following effects of this flood: > > > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > > disruption in traffic > > > > >over > > > > > > active traffic channel. > > > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > > receiving this flood > > > > >causes > > > > > > power wastage. This is because, after receiving these > > > > capabilities MN > > > > >either > > > > > > rejects the new AR (which is worst), and even if it > > > > selcects one why > > > > >does it > > > > > > need to receive capabilities of GAARs that do not > > matter for it. > > > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > > every MN that it > > > > > > sees. Which means the same information (which could be > > > > big enough) is > > > > > > transmitted on downlink so many times. This takes up > > > > considerable > > > > >fraction > > > > > > of downlink capacity. > > > > > > > > > > > > 4. Limit on capability definition: This requirement > > > > restricts the > > > > >definition > > > > > > of capabilities to a very small size, otherwise all ARs > > > > will only be > > > > > > transmitting GAAR capabilities to different MNs all the > > > > time. This means > > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > > statement requirement > > > > >that > > > > > > you proposed and who have not, we should first analyse > > > > above harmful > > > > >effects > > > > > > before deciding either way. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: > > > > > > >Examples of CAR discovery) > > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > > > >, > > > > > > > > So now you agree that the AR can hand over the list > > > > of GAARs and > > > > > > > > their capabilities to the MN (maybe only pass on > > > > those which satisfy > > > > > > > > the MN requirements, which is what CAR discovery > > > > was originally > > > > > > >about). > > > > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > > Let me repeat the > > > > > > >requirement I would like to see (and Henrik apparently > > > > agrees) so we > > > > >are > > > > > > >clear on this: > > > > > > > > > > > > > > The CAR discovery protocol MUST provide the > > MN with GAAR > > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > > > > Which first implies that the network is > > taking care of CAR > > > > >discovery. > > > > > > > > This seems contradictory to your earlier mails > > > > saying that there is > > > > > > > > no basis for network based CAR discovery. So are > > > > you now agreeing > > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > > The protocol allows > > > > > > >the MN to discover the GAAR and capabilities, the MN > > > > decides which one > > > > > > >it wants. > > > > > > >Nothing about the AR in control of anything. The MN > > > > may use a variant > > > > >of > > > > > > >IPv6 neighbor discovery, the AR may be involved > > > > somehow, but that's a > > > > > > >protocol design, not a requirement, choice. The > > > > requirement is clearly > > > > > > >that the MN does the discovery. > > > > > > > > > > > > > >We now have two working group members who want this > > > > reqirement worded > > > > > > >just this way. Nothing about "as the MN expresses its > > > > preferences" or > > > > > > >"by the CAR discovery module" or anything else. And I > > > > believe Hesham > > > > >has > > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > > we include this > > > > > > >requirement instead of requirement 3.4, which has the > > > > AR in control? > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Seamoby mailing list > > > > > > >Seamoby@ietf.org > > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > MSN Photos is the easiest way to share and print > > your photos: > > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: >http://mobile.msn.com > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:06:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12542 for ; Wed, 27 Mar 2002 13:06:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24635 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:06:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24110; Wed, 27 Mar 2002 13:01:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24073 for ; Wed, 27 Mar 2002 13:01:12 -0500 (EST) Received: from hotmail.com (f38.law7.hotmail.com [216.33.237.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12088 for ; Wed, 27 Mar 2002 13:01:07 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:00:38 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:00:38 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: hesham.soliman@era.ericsson.se, govs23@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 18:00:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:00:38.0511 (UTC) FILETIME=[4D44DFF0:01C1D5B9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi Hesham: Then that has to be there in requirements too. "CAR discovery solution MAY not consider more that two APs". Isn't it. What is the problem in not explicitly stating in the requirements what the requirements are about. Hemant >From: "Hesham Soliman (ERA)" >To: "'Govind Krishnamurthi'" , "Hesham Soliman >(ERA)" , seamoby@ietf.org >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa >s: Examples of >Date: Wed, 27 Mar 2002 17:55:56 +0100 > > > Without knowing how many different GAARs are available (see > > Henriks mail > > about N interfaces) without knowing what the capabilities > > are I don't > > understand how you have come to the conclusion that the pushing > > the GAARs (all of them + their capabilities) to the MN is > > not blasting. > > >=> Because I'm narrowing the scope of AR-based >CAR to a couple of neighbouring routers within >the same domain and the access technology. >This is as far as it should go IMHO. >That is, if you expect it to be seriously >deployed. > >Hesham > > > > All we ask is the MN has an option to say no to this. > > Aren't you removing > > the MN's right not to want to proces this kind of information > > by saying that GAARs and their capabilities MUST be sent > > over to the MN? > > > > Govind. > > > > > >What is iths blöasting that people keep > > >bringing up? an extra option in an RA is blasting ???? > > >What is the alternative: The magic AR that knows > > >everything ?????????????? > > > > > >Seriously, let's keep it simple or this whole > > >protocol will start collapsing the moment > > >anyone starts deploying it. Of course if deployment > > >is not a concern then I'll just og back to sleep! > > > > > >Hesham > > > > > > > -----Original Message----- > > > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > > > Sent: Wednesday, March 27, 2002 5:21 PM > > > > To: 'Hemant Chaskar'; seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (wa s: Examples of CAR discovery) > > > > > > > > > > > > So, is there anyone that seriously thinks that "blasting > > > > GAAR IDs and all of > > > > their capabilities to MN" is a good idea? If not (which I > > > > hope so) then the > > > > requirements document should not imply otherwise. > > > > > > > > George > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Wednesday, March 27, 2002 4:08 PM > > > > To: seamoby@ietf.org > > > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > (was: Examples of CAR discovery) > > > > > > > > > > > > Hi Hernik: > > > > > > > > I did read your comment and responded as follows in my > > > > earlier email. > > > > Cut'n'Paste: > > > > > > > > ------------------------------- > > > > If we honestly think that the requirement does not oblige > > > > AR to blast all > > > > GAAR IDs and all of their capabilities to MN, why not say > > > > so clearly. Why do > > > > > > > > we need to hide this fact? We can come up with something > > > > else, if you do not > > > > > > > > like on-demand extension. I think without such extension > > > > the solution > > > > satisfying this requirement may have serious shortcomings > > > > that I described > > > > in my other email to James. > > > > -------------------------------- > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "Henrik Levkowetz" > > > > >To: "Hemant Chaskar" > > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: Examples of CAR discovery) > > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > > > >Hemant, > > > > > > > > > > You apparently did not read my recent posting. > > Cut'n'Paste: > > > > > > > > > > No, the requirement is just fine. It does not > > require *all* GAAR > > > > >information, it does not require *on-demand operation*, it > > > > expresses > > > > >exactly > > > > >what we are in a position to say about the matter now: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? > > > > Why? Do you > > > > >want to make things more complicated than they have to be? > > > > > > > > > > Henrik > > > > > > > > > >Hemant wrote: > > > > > > > > > > > > Hi James: > > > > > > > > > > > > There are serious shortcomings of the solution > > satisfying this > > > > >requirement. > > > > > > They are described below. How can we finalise this > > > > requirement unless it > > > > > > > > >is > > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > > > For this, it might be good idea to visualise how the > > > > solution satisfying > > > > > > this requirement looks like and violates basic tenets > > > > of engineering > > > > >design, > > > > > > namely efficiency. The solution satisfying this > > > > requirement is obliged > > > > >to > > > > > > blast GAAR IDs and their capabilities on MN when AR > > > > sees MN. This might > > > > >be a > > > > > > big chunk of data (= number of GAARs times capability > > > > set of each). This > > > > > > flood will occur either on active traffic connection > > > > which I call case > > > > >(i) > > > > > > (relevant for single interface MN and two-interface MN > > > > where second > > > > > > interface is sleeping) or on second interface which I > > > > call case (ii) > > > > > > (relevant for two interface MN with both interfaces > > > > awake). There are > > > > > > following effects of this flood: > > > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > > > disruption in traffic > > > > >over > > > > > > active traffic channel. > > > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > > > receiving this flood > > > > >causes > > > > > > power wastage. This is because, after receiving these > > > > capabilities MN > > > > >either > > > > > > rejects the new AR (which is worst), and even if it > > > > selcects one why > > > > >does it > > > > > > need to receive capabilities of GAARs that do not > > matter for it. > > > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > > > every MN that it > > > > > > sees. Which means the same information (which could be > > > > big enough) is > > > > > > transmitted on downlink so many times. This takes up > > > > considerable > > > > >fraction > > > > > > of downlink capacity. > > > > > > > > > > > > 4. Limit on capability definition: This requirement > > > > restricts the > > > > >definition > > > > > > of capabilities to a very small size, otherwise all ARs > > > > will only be > > > > > > transmitting GAAR capabilities to different MNs all the > > > > time. This means > > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > > > So, IMHO rather than counting who agrees to one > > > > statement requirement > > > > >that > > > > > > you proposed and who have not, we should first analyse > > > > above harmful > > > > >effects > > > > > > before deciding either way. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Govind Krishnamurthi" , > > > > > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > > > Requirement > > > > >(was: > > > > > > >Examples of CAR discovery) > > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > > > >, > > > > > > > > So now you agree that the AR can hand over the list > > > > of GAARs and > > > > > > > > their capabilities to the MN (maybe only pass on > > > > those which satisfy > > > > > > > > the MN requirements, which is what CAR discovery > > > > was originally > > > > > > >about). > > > > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > > > Let me repeat the > > > > > > >requirement I would like to see (and Henrik apparently > > > > agrees) so we > > > > >are > > > > > > >clear on this: > > > > > > > > > > > > > > The CAR discovery protocol MUST provide the > > MN with GAAR > > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > > > > Which first implies that the network is > > taking care of CAR > > > > >discovery. > > > > > > > > This seems contradictory to your earlier mails > > > > saying that there is > > > > > > > > no basis for network based CAR discovery. So are > > > > you now agreeing > > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > > > The protocol allows > > > > > > >the MN to discover the GAAR and capabilities, the MN > > > > decides which one > > > > > > >it wants. > > > > > > >Nothing about the AR in control of anything. The MN > > > > may use a variant > > > > >of > > > > > > >IPv6 neighbor discovery, the AR may be involved > > > > somehow, but that's a > > > > > > >protocol design, not a requirement, choice. The > > > > requirement is clearly > > > > > > >that the MN does the discovery. > > > > > > > > > > > > > >We now have two working group members who want this > > > > reqirement worded > > > > > > >just this way. Nothing about "as the MN expresses its > > > > preferences" or > > > > > > >"by the CAR discovery module" or anything else. And I > > > > believe Hesham > > > > >has > > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > > > >Anybody else out there have an opinion on this? Should > > > > we include this > > > > > > >requirement instead of requirement 3.4, which has the > > > > AR in control? > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Seamoby mailing list > > > > > > >Seamoby@ietf.org > > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > MSN Photos is the easiest way to share and print > > your photos: > > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: >http://mobile.msn.com > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:08:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12739 for ; Wed, 27 Mar 2002 13:08:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23393; Wed, 27 Mar 2002 12:57:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23326 for ; Wed, 27 Mar 2002 12:57:21 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11713 for ; Wed, 27 Mar 2002 12:57:20 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA28039; Wed, 27 Mar 2002 18:54:21 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:57:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Hmenat, If we mean "all", we should say "all". If we don't mean "all", we should not say "all". We don't say "all". So we don't mean "all". Keep it simple. Sure, if I say: "There are black cats there", I could also say "There are black cats there. There may also be other colours of cats. Or all the cats could be black. We don't know today, because we have not looked yet. And tomorrow that could change, so there could be that there are probably only one black cats. As a matter of fact, some days ago, there was exactly two black cats there. etc. etc. etc. ................" But I dont't think verbosity is the goal, I think correct requirements are the goal. Isn't it fun to spend days discussing how we could change a clearly formulated requirement to be "better" but still maybe mean the same? Henrik > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 5:40 PM > To: henrik@levkowetz.com; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > If we do not know, we should say "we do not know". I have difficulty putting > in MUST requirement about which we do not know for sure. If it means that > all GAARs and all their capabilities need not be sent, it must say so. > > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" , > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 17:43:46 +0100 > > > >Hemant, > > > > The requirement as first proposed does not imply that *all* > >GAAR information must be sent. The requirement as first proposed also > >does not require that a filtering mechanism must be part of the solution. > > > >The revised requirement requires a filtering mechanism. I do not believe > >we know that this is the right way to go yet. Therefore I do not believe > >that it is good to add this restriction. > > > > Henrik > > > > > > > > > > > Hi Hernik: > > > > > > I did read your comment and responded as follows in my earlier email. > > > Cut'n'Paste: > > > > > > ------------------------------- > > > If we honestly think that the requirement does not oblige AR to blast > >all > > > GAAR IDs and all of their capabilities to MN, why not say so clearly. > >Why do > > > we need to hide this fact? We can come up with something else, if you do > >not > > > like on-demand extension. I think without such extension the solution > > > satisfying this requirement may have serious shortcomings that I > >described > > > in my other email to James. > > > -------------------------------- > > > > > > BR, > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > > > >(was: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > >Hemant, > > > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > > >information, it does not require *on-demand operation*, it expresses > > > >exactly > > > >what we are in a position to say about the matter now: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > > > >want to make things more complicated than they have to be? > > > > > > > > Henrik > > > > > > > >Hemant wrote: > > > > > > > > > > Hi James: > > > > > > > > > > There are serious shortcomings of the solution satisfying this > > > >requirement. > > > > > They are described below. How can we finalise this requirement > >unless it > > > >is > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > For this, it might be good idea to visualise how the solution > >satisfying > > > > > this requirement looks like and violates basic tenets of engineering > > > >design, > > > > > namely efficiency. The solution satisfying this requirement is > >obliged > > > >to > > > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This > >might > > > >be a > > > > > big chunk of data (= number of GAARs times capability set of each). > >This > > > > > flood will occur either on active traffic connection which I call > >case > > > >(i) > > > > > (relevant for single interface MN and two-interface MN where second > > > > > interface is sleeping) or on second interface which I call case (ii) > > > > > (relevant for two interface MN with both interfaces awake). There > >are > > > > > following effects of this flood: > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in > >traffic > > > >over > > > > > active traffic channel. > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > > > >causes > > > > > power wastage. This is because, after receiving these capabilities > >MN > > > >either > > > > > rejects the new AR (which is worst), and even if it selcects one why > > > >does it > > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN > >that it > > > > > sees. Which means the same information (which could be big enough) > >is > > > > > transmitted on downlink so many times. This takes up considerable > > > >fraction > > > > > of downlink capacity. > > > > > > > > > > 4. Limit on capability definition: This requirement restricts the > > > >definition > > > > > of capabilities to a very small size, otherwise all ARs will only be > > > > > transmitting GAAR capabilities to different MNs all the time. This > >means > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > So, IMHO rather than counting who agrees to one statement > >requirement > > > >that > > > > > you proposed and who have not, we should first analyse above harmful > > > >effects > > > > > before deciding either way. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Govind Krishnamurthi" , > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > > > >(was: > > > > > >Examples of CAR discovery) > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > >, > > > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > > > their capabilities to the MN (maybe only pass on those which > >satisfy > > > > > > > the MN requirements, which is what CAR discovery was originally > > > > > >about). > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat > >the > > > > > >requirement I would like to see (and Henrik apparently agrees) so > >we > > > >are > > > > > >clear on this: > > > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > > >discovery. > > > > > > > This seems contradictory to your earlier mails saying that there > >is > > > > > > > no basis for network based CAR discovery. So are you now > >agreeing > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol > >allows > > > > > >the MN to discover the GAAR and capabilities, the MN decides which > >one > > > > > >it wants. > > > > > >Nothing about the AR in control of anything. The MN may use a > >variant > > > >of > > > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's > >a > > > > > >protocol design, not a requirement, choice. The requirement is > >clearly > > > > > >that the MN does the discovery. > > > > > > > > > > > >We now have two working group members who want this reqirement > >worded > > > > > >just this way. Nothing about "as the MN expresses its preferences" > >or > > > > > >"by the CAR discovery module" or anything else. And I believe > >Hesham > > > >has > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > >Anybody else out there have an opinion on this? Should we include > >this > > > > > >requirement instead of requirement 3.4, which has the AR in > >control? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Seamoby mailing list > > > > > >Seamoby@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world’s largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:08:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12749 for ; Wed, 27 Mar 2002 13:08:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24724 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:08:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23393; Wed, 27 Mar 2002 12:57:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23326 for ; Wed, 27 Mar 2002 12:57:21 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11713 for ; Wed, 27 Mar 2002 12:57:20 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA28039; Wed, 27 Mar 2002 18:54:21 +0100 From: "Henrik Levkowetz" To: "Hemant Chaskar" , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:57:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi Hmenat, If we mean "all", we should say "all". If we don't mean "all", we should not say "all". We don't say "all". So we don't mean "all". Keep it simple. Sure, if I say: "There are black cats there", I could also say "There are black cats there. There may also be other colours of cats. Or all the cats could be black. We don't know today, because we have not looked yet. And tomorrow that could change, so there could be that there are probably only one black cats. As a matter of fact, some days ago, there was exactly two black cats there. etc. etc. etc. ................" But I dont't think verbosity is the goal, I think correct requirements are the goal. Isn't it fun to spend days discussing how we could change a clearly formulated requirement to be "better" but still maybe mean the same? Henrik > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 5:40 PM > To: henrik@levkowetz.com; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > If we do not know, we should say "we do not know". I have difficulty putting > in MUST requirement about which we do not know for sure. If it means that > all GAARs and all their capabilities need not be sent, it must say so. > > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" , > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 17:43:46 +0100 > > > >Hemant, > > > > The requirement as first proposed does not imply that *all* > >GAAR information must be sent. The requirement as first proposed also > >does not require that a filtering mechanism must be part of the solution. > > > >The revised requirement requires a filtering mechanism. I do not believe > >we know that this is the right way to go yet. Therefore I do not believe > >that it is good to add this restriction. > > > > Henrik > > > > > > > > > > > Hi Hernik: > > > > > > I did read your comment and responded as follows in my earlier email. > > > Cut'n'Paste: > > > > > > ------------------------------- > > > If we honestly think that the requirement does not oblige AR to blast > >all > > > GAAR IDs and all of their capabilities to MN, why not say so clearly. > >Why do > > > we need to hide this fact? We can come up with something else, if you do > >not > > > like on-demand extension. I think without such extension the solution > > > satisfying this requirement may have serious shortcomings that I > >described > > > in my other email to James. > > > -------------------------------- > > > > > > BR, > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" > > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > > > >(was: Examples of CAR discovery) > > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > > > >Hemant, > > > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > > >information, it does not require *on-demand operation*, it expresses > > > >exactly > > > >what we are in a position to say about the matter now: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > > > >want to make things more complicated than they have to be? > > > > > > > > Henrik > > > > > > > >Hemant wrote: > > > > > > > > > > Hi James: > > > > > > > > > > There are serious shortcomings of the solution satisfying this > > > >requirement. > > > > > They are described below. How can we finalise this requirement > >unless it > > > >is > > > > > agreed that these pitfalls do not exist? > > > > > > > > > > For this, it might be good idea to visualise how the solution > >satisfying > > > > > this requirement looks like and violates basic tenets of engineering > > > >design, > > > > > namely efficiency. The solution satisfying this requirement is > >obliged > > > >to > > > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This > >might > > > >be a > > > > > big chunk of data (= number of GAARs times capability set of each). > >This > > > > > flood will occur either on active traffic connection which I call > >case > > > >(i) > > > > > (relevant for single interface MN and two-interface MN where second > > > > > interface is sleeping) or on second interface which I call case (ii) > > > > > (relevant for two interface MN with both interfaces awake). There > >are > > > > > following effects of this flood: > > > > > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in > >traffic > > > >over > > > > > active traffic channel. > > > > > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > > > >causes > > > > > power wastage. This is because, after receiving these capabilities > >MN > > > >either > > > > > rejects the new AR (which is worst), and even if it selcects one why > > > >does it > > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN > >that it > > > > > sees. Which means the same information (which could be big enough) > >is > > > > > transmitted on downlink so many times. This takes up considerable > > > >fraction > > > > > of downlink capacity. > > > > > > > > > > 4. Limit on capability definition: This requirement restricts the > > > >definition > > > > > of capabilities to a very small size, otherwise all ARs will only be > > > > > transmitting GAAR capabilities to different MNs all the time. This > >means > > > > > capability set cannot be comprehensive and extensible. > > > > > > > > > > So, IMHO rather than counting who agrees to one statement > >requirement > > > >that > > > > > you proposed and who have not, we should first analyse above harmful > > > >effects > > > > > before deciding either way. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Govind Krishnamurthi" , > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > > > >(was: > > > > > >Examples of CAR discovery) > > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > > > >, > > > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > > > their capabilities to the MN (maybe only pass on those which > >satisfy > > > > > > > the MN requirements, which is what CAR discovery was originally > > > > > >about). > > > > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat > >the > > > > > >requirement I would like to see (and Henrik apparently agrees) so > >we > > > >are > > > > > >clear on this: > > > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > > >discovery. > > > > > > > This seems contradictory to your earlier mails saying that there > >is > > > > > > > no basis for network based CAR discovery. So are you now > >agreeing > > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol > >allows > > > > > >the MN to discover the GAAR and capabilities, the MN decides which > >one > > > > > >it wants. > > > > > >Nothing about the AR in control of anything. The MN may use a > >variant > > > >of > > > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's > >a > > > > > >protocol design, not a requirement, choice. The requirement is > >clearly > > > > > >that the MN does the discovery. > > > > > > > > > > > >We now have two working group members who want this reqirement > >worded > > > > > >just this way. Nothing about "as the MN expresses its preferences" > >or > > > > > >"by the CAR discovery module" or anything else. And I believe > >Hesham > > > >has > > > > > >also expressed a preference for this requirement. > > > > > > > > > > > >Anybody else out there have an opinion on this? Should we include > >this > > > > > >requirement instead of requirement 3.4, which has the AR in > >control? > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Seamoby mailing list > > > > > >Seamoby@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > MSN Photos is the easiest way to share and print your photos: > > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world’s largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:10:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12880 for ; Wed, 27 Mar 2002 13:10:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24486; Wed, 27 Mar 2002 13:04:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24456 for ; Wed, 27 Mar 2002 13:04:51 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12316 for ; Wed, 27 Mar 2002 13:04:50 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RI59s29369 for ; Wed, 27 Mar 2002 12:05:09 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:04:49 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:04:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 13:04:26 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVuDrxH7P+dKlIR1aOdYZOWL9q5QAADm1g To: , , X-OriginalArrivalTime: 27 Mar 2002 18:04:27.0835 (UTC) FILETIME=[D5F4F0B0:01C1D5B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA24457 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, And I pointed out the flaw in Hemant's argument: premature optimization. The requirements are supposed to say what the protocol will do, not specify it in detail. We need a strong statement that it is MN centered. Later, there may be need for optimization, but if we put the optimization in up front, we constrain the solution too much or open it up to nonviable solutions. [DOT] Assume we had a requirement saying that GAAR+capa must be sent to MN. This is a strong requirement (MUST) without knowing what's the amount of said data. Personally believing that it is not that much is not enough to justify this. Maybe, you have more clearer idea of the data we're talking about. Then please share it with the WG. [DOT] All I'm saying is that there must a possibility for the MN to say which information it wants to receive to avoid a mandatory transmission of data that might be unnecessary in large parts. If we had this addition, it would be still be MN-centered (it is the MN that says what to receive). And it does not restrict, since if the MN decides to receive everything, it can still say so. So it contains actually the original requirement (ALL information) plus it mandates possibilities for the MN to restrict the information it wants to receive. So I don't see why this constrains the solution? And I wouldn't call it opening up to nonviable solution, when I raise the concern that there should be the possibility for the MN to restrict information delivery, in particular in a stage where we actually don't know how the data looks like. I also have a hard time buying that there will be sooo much GAAR information. We are not talking about a complete list of the NASDAQ here, just whatever routers happen to be in the vicinity. [DOT] I can buy nothing from guessing, James. As long as we didn't really study what are the capabilities, what is the format, what are the scenarios, I'd like to see transmission of said data to the MN being able to limit BY THE MN. That's what I'm asking for. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:11:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12978 for ; Wed, 27 Mar 2002 13:11:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24562; Wed, 27 Mar 2002 13:06:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24535 for ; Wed, 27 Mar 2002 13:05:58 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12380 for ; Wed, 27 Mar 2002 13:05:55 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RI5uoq011654 for ; Wed, 27 Mar 2002 19:05:56 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:05:55 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:05:54 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , govs23@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:05:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hemant, > Then that has to be there in requirements too. > > "CAR discovery solution MAY not consider more that two APs". > => This is why I prefer talking face to face ! So if the MN has 3 interfaces and listens to ARs anyway then we should disallow that? There are 2 problems here: - You assume CAR discovery == AR looking for GAARs, I think this is only one part of CAR discovery. This is why we're having this discussion. There is a clear problem in the understanding of what CAR discovery means. - I always said, limit it to the same operator and the same access technology. I didn't say one or two. I said it is unlikely to get more than two if you apply the limitation above. I might be wrong and more than happy to hear that, but the discussion seems to be going towards picking words rather than picking technical reasons. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:11:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12985 for ; Wed, 27 Mar 2002 13:11:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25004 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:11:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24562; Wed, 27 Mar 2002 13:06:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24535 for ; Wed, 27 Mar 2002 13:05:58 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12380 for ; Wed, 27 Mar 2002 13:05:55 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RI5uoq011654 for ; Wed, 27 Mar 2002 19:05:56 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:05:55 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:05:54 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hemant Chaskar'" , "Hesham Soliman (ERA)" , govs23@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:05:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hemant, > Then that has to be there in requirements too. > > "CAR discovery solution MAY not consider more that two APs". > => This is why I prefer talking face to face ! So if the MN has 3 interfaces and listens to ARs anyway then we should disallow that? There are 2 problems here: - You assume CAR discovery == AR looking for GAARs, I think this is only one part of CAR discovery. This is why we're having this discussion. There is a clear problem in the understanding of what CAR discovery means. - I always said, limit it to the same operator and the same access technology. I didn't say one or two. I said it is unlikely to get more than two if you apply the limitation above. I might be wrong and more than happy to hear that, but the discussion seems to be going towards picking words rather than picking technical reasons. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:16:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13259 for ; Wed, 27 Mar 2002 13:16:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24936; Wed, 27 Mar 2002 13:11:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24903 for ; Wed, 27 Mar 2002 13:11:00 -0500 (EST) Received: from hotmail.com (f62.law9.hotmail.com [64.4.9.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12941 for ; Wed, 27 Mar 2002 13:10:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:10:30 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:10:30 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 13:10:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:10:30.0630 (UTC) FILETIME=[AE331060:01C1D5BA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, >- I always said, limit it to the same operator >and the same access technology. I didn't say >one or two. I said it is unlikely to get more >than two if you apply the limitation above. >I might be wrong and more than happy to hear >that, but the discussion seems to be going towards >picking words rather than picking technical reasons. [Govind] Well this is new. Iam curious :) Intertechnology part is a MUST and it was deemed an uncontroversial requirement in MPLS and put towards the end of the presentation as this requirement did not raise ANY discussion prior to MPLS and even prior to today. If you had an objection always, why did you not raise any objection at MPLS? Nor did you raise any in our quite extensive discussions in GPRS to WLAN handovers. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:16:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13286 for ; Wed, 27 Mar 2002 13:16:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25862 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:16:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24936; Wed, 27 Mar 2002 13:11:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24903 for ; Wed, 27 Mar 2002 13:11:00 -0500 (EST) Received: from hotmail.com (f62.law9.hotmail.com [64.4.9.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12941 for ; Wed, 27 Mar 2002 13:10:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:10:30 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:10:30 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 13:10:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:10:30.0630 (UTC) FILETIME=[AE331060:01C1D5BA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, >- I always said, limit it to the same operator >and the same access technology. I didn't say >one or two. I said it is unlikely to get more >than two if you apply the limitation above. >I might be wrong and more than happy to hear >that, but the discussion seems to be going towards >picking words rather than picking technical reasons. [Govind] Well this is new. Iam curious :) Intertechnology part is a MUST and it was deemed an uncontroversial requirement in MPLS and put towards the end of the presentation as this requirement did not raise ANY discussion prior to MPLS and even prior to today. If you had an objection always, why did you not raise any objection at MPLS? Nor did you raise any in our quite extensive discussions in GPRS to WLAN handovers. Regards, Govind. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:17:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13389 for ; Wed, 27 Mar 2002 13:17:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25576; Wed, 27 Mar 2002 13:15:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25529 for ; Wed, 27 Mar 2002 13:15:15 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13143 for ; Wed, 27 Mar 2002 13:15:13 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28434 for ; Wed, 27 Mar 2002 19:12:19 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 19:15:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant wrote: > > Hi Hesham: > > I do not know what consensus you are talking about. There was one question > asked which was not clearly stated, and for that too, I saw only three hands > go up. > > The requirement was posted after MPLS and there has not been any consensus > on it yet. > > What we have agreed in MPLS was "MN's requirements MUST be considered in CAR > discovery, handoffs etc.". We all are in good agreement on that. I disagree on this representation of Steve D's talk in Minneapolis. The consensus there was much wider, and focused on the whole conceptual idea of Steve's talk. Henrik > > I don't think however that this means that it precludes executing processor > level algorithms anywhere else than MN's processor, as long as those > algorithms consider all MN's requirement. This is implementation-specific > aspect. > > More comments below. > > Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:17:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13397 for ; Wed, 27 Mar 2002 13:17:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26130 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:17:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25576; Wed, 27 Mar 2002 13:15:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25529 for ; Wed, 27 Mar 2002 13:15:15 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13143 for ; Wed, 27 Mar 2002 13:15:13 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28434 for ; Wed, 27 Mar 2002 19:12:19 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 19:15:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant wrote: > > Hi Hesham: > > I do not know what consensus you are talking about. There was one question > asked which was not clearly stated, and for that too, I saw only three hands > go up. > > The requirement was posted after MPLS and there has not been any consensus > on it yet. > > What we have agreed in MPLS was "MN's requirements MUST be considered in CAR > discovery, handoffs etc.". We all are in good agreement on that. I disagree on this representation of Steve D's talk in Minneapolis. The consensus there was much wider, and focused on the whole conceptual idea of Steve's talk. Henrik > > I don't think however that this means that it precludes executing processor > level algorithms anywhere else than MN's processor, as long as those > algorithms consider all MN's requirement. This is implementation-specific > aspect. > > More comments below. > > Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:17:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13417 for ; Wed, 27 Mar 2002 13:17:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24421; Wed, 27 Mar 2002 13:04:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24390 for ; Wed, 27 Mar 2002 13:04:19 -0500 (EST) Received: from hotmail.com (f4.law9.hotmail.com [64.4.9.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12291 for ; Wed, 27 Mar 2002 13:04:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:03:49 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:03:48 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 13:03:48 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:03:49.0156 (UTC) FILETIME=[BEE6FE40:01C1D5B9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >Here's the requirement: > > The other fundamental function of CAR discovery protocols is that of > identifying the capabilities of GAARs. The protocol MUST provide > functionality to allow ARs to discover their GAAR's capabilities. >These > capabilities MUST be communicated in a secure fashion. > >There is not one single mention of the MN in this requirement. > >How can you interpret that this requirement does NOT put the AR in >control? This is exactly the message Steve Deering was trying to get >across in the Minne-apple. [Govind] There is a bias and I agree that the bias should be removed. But what you are suggesting is to swing the pendulum to the opposite end putting an MN bias. We should work toward an un-biased set of requirements, IMHO, and thats what I will endeavor to do based on the discussions in the mailing list. Regards, Govind. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:17:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13428 for ; Wed, 27 Mar 2002 13:17:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26149 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:17:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24421; Wed, 27 Mar 2002 13:04:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24390 for ; Wed, 27 Mar 2002 13:04:19 -0500 (EST) Received: from hotmail.com (f4.law9.hotmail.com [64.4.9.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12291 for ; Wed, 27 Mar 2002 13:04:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:03:49 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:03:48 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 13:03:48 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:03:49.0156 (UTC) FILETIME=[BEE6FE40:01C1D5B9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, >Here's the requirement: > > The other fundamental function of CAR discovery protocols is that of > identifying the capabilities of GAARs. The protocol MUST provide > functionality to allow ARs to discover their GAAR's capabilities. >These > capabilities MUST be communicated in a secure fashion. > >There is not one single mention of the MN in this requirement. > >How can you interpret that this requirement does NOT put the AR in >control? This is exactly the message Steve Deering was trying to get >across in the Minne-apple. [Govind] There is a bias and I agree that the bias should be removed. But what you are suggesting is to swing the pendulum to the opposite end putting an MN bias. We should work toward an un-biased set of requirements, IMHO, and thats what I will endeavor to do based on the discussions in the mailing list. Regards, Govind. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:19:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13549 for ; Wed, 27 Mar 2002 13:19:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25941; Wed, 27 Mar 2002 13:17:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25874 for ; Wed, 27 Mar 2002 13:16:59 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13298 for ; Wed, 27 Mar 2002 13:16:58 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RIJK100627 for ; Wed, 27 Mar 2002 12:19:20 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:16:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:16:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 13:16:47 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVuJqQ0cShZPK3RAqdx0slhE9xLgAAmdBg To: , , X-OriginalArrivalTime: 27 Mar 2002 18:16:48.0652 (UTC) FILETIME=[8F84A4C0:01C1D5BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA25875 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Here's the requirement: The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. [DOT] Sorry, I mixed up some numbers, you're right with this one. But this addresses another problem, and Govind already sent this to list, namely to remove certain AR-biased wordings. The above requirement is entirely possible without mentioning the AR, and I assumed after Govind's comment that this will happen in the revised version. But even if you did this, you still need means to express MN's requirements in the sense I described. That was my point. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:19:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13566 for ; Wed, 27 Mar 2002 13:19:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26207 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:19:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25941; Wed, 27 Mar 2002 13:17:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25874 for ; Wed, 27 Mar 2002 13:16:59 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13298 for ; Wed, 27 Mar 2002 13:16:58 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RIJK100627 for ; Wed, 27 Mar 2002 12:19:20 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:16:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:16:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 13:16:47 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVuJqQ0cShZPK3RAqdx0slhE9xLgAAmdBg To: , , X-OriginalArrivalTime: 27 Mar 2002 18:16:48.0652 (UTC) FILETIME=[8F84A4C0:01C1D5BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA25875 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, Here's the requirement: The other fundamental function of CAR discovery protocols is that of identifying the capabilities of GAARs. The protocol MUST provide functionality to allow ARs to discover their GAAR's capabilities. These capabilities MUST be communicated in a secure fashion. [DOT] Sorry, I mixed up some numbers, you're right with this one. But this addresses another problem, and Govind already sent this to list, namely to remove certain AR-biased wordings. The above requirement is entirely possible without mentioning the AR, and I assumed after Govind's comment that this will happen in the revised version. But even if you did this, you still need means to express MN's requirements in the sense I described. That was my point. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:20:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13636 for ; Wed, 27 Mar 2002 13:20:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26091; Wed, 27 Mar 2002 13:17:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26059 for ; Wed, 27 Mar 2002 13:17:30 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13343 for ; Wed, 27 Mar 2002 13:17:28 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28496 for ; Wed, 27 Mar 2002 19:14:35 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 19:17:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hemant wrote: > > Henrik: > > If you are so sure of this interpretation, why don't we add it to > requirement for clarity. Why should leave the requirement text to open > interpretation. Because the requirement is perfectly clear as is. Henrik > > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Wed, 27 Mar 2002 17:44:53 +0100 > > > >Hemant, > > > > Nobody is proposing to blast anybody blindly. This is a misapprehension. > > > > Henrik > > > > > > Henrik: > > > > > > I agree that you cannot focus on one case only, but then you cannot > >ignore > > > any too. The current requirement of blasting MN blindly with volume of > > > capability data does ingore implication on certain cases. Further this > > > requirement is a MUST one and does not say whether it is applicable to > >only > > > some cases or all cases. > > > > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" , > > > >Subject: RE: [Seamoby] Examples of CAR discovery > > > >Date: Wed, 27 Mar 2002 02:28:25 +0100 > > > > > > > >Hemant wrote: > > > > > > > > > > Hi Henrik: > > > > > > > > > > > > > > > > >-------------------------------------snip------------------------------ > > > > > > > > > > > > > > An example where such comparison may occur in network is when > >there > > > >is > > > > > >only > > > > > > > one interface on MN and it can listen only to radio beacons of > > > > > >surrounding > > > > > > > access points. This is similar to break-before-make handoff > >case. > > > >Here, > > > > > >MN > > > > > > > cannot receive capabilities of GAARs without letting go the > >previous > > > > > > > connection. Do you think that such cases are not relevant and we > > > >should > > > > > > > exclude such cases right at the problem statement/requirements > > > >stage? > > > > > > > > > > > >I think that designing for the one access technology case will > >cripple > > > > > >the solution. > > > > > > > > > > [HC] I do not understand your comment. Are you essentially saying > >that > > > >"This > > > > > case is irrelevant for CAR discovery" or "Completely AR unassisted > >CAR > > > > > discovery is optimal for this case too". > > > > > > > >No, i'm not saying this case is irrelevant, or that AR unassisted CAR > > > >discovery > > > >is optimal ... for any case. I'm saying: > > > > > > > >I think that designing for the one access technology case will cripple > > > >the solution. > > > > > > > > > > > > > > IMHO neither requirements nor problem statement should ignore any > >use > > > >cases. > > > > > If they do, it should be explicitly stated so in the spec, so that > > > >designers > > > > > are not misguided to apply solutions to cases for which they are not > > > > > designed. > > > > > > > >Nobody's ignoring any use cases. But if you focus on one sample to the > > > >detriment of the rest, it will cripple your solution. > > > > > > > > Regards, > > > > Henrik > > > > > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world’s largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:20:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13651 for ; Wed, 27 Mar 2002 13:20:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26268 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:20:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26091; Wed, 27 Mar 2002 13:17:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26059 for ; Wed, 27 Mar 2002 13:17:30 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13343 for ; Wed, 27 Mar 2002 13:17:28 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28496 for ; Wed, 27 Mar 2002 19:14:35 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 19:17:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hemant wrote: > > Henrik: > > If you are so sure of this interpretation, why don't we add it to > requirement for clarity. Why should leave the requirement text to open > interpretation. Because the requirement is perfectly clear as is. Henrik > > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Examples of CAR discovery > >Date: Wed, 27 Mar 2002 17:44:53 +0100 > > > >Hemant, > > > > Nobody is proposing to blast anybody blindly. This is a misapprehension. > > > > Henrik > > > > > > Henrik: > > > > > > I agree that you cannot focus on one case only, but then you cannot > >ignore > > > any too. The current requirement of blasting MN blindly with volume of > > > capability data does ingore implication on certain cases. Further this > > > requirement is a MUST one and does not say whether it is applicable to > >only > > > some cases or all cases. > > > > > > Hemant > > > > > > > > > >From: "Henrik Levkowetz" > > > >To: "Hemant Chaskar" , > > > >Subject: RE: [Seamoby] Examples of CAR discovery > > > >Date: Wed, 27 Mar 2002 02:28:25 +0100 > > > > > > > >Hemant wrote: > > > > > > > > > > Hi Henrik: > > > > > > > > > > > > > > > > >-------------------------------------snip------------------------------ > > > > > > > > > > > > > > An example where such comparison may occur in network is when > >there > > > >is > > > > > >only > > > > > > > one interface on MN and it can listen only to radio beacons of > > > > > >surrounding > > > > > > > access points. This is similar to break-before-make handoff > >case. > > > >Here, > > > > > >MN > > > > > > > cannot receive capabilities of GAARs without letting go the > >previous > > > > > > > connection. Do you think that such cases are not relevant and we > > > >should > > > > > > > exclude such cases right at the problem statement/requirements > > > >stage? > > > > > > > > > > > >I think that designing for the one access technology case will > >cripple > > > > > >the solution. > > > > > > > > > > [HC] I do not understand your comment. Are you essentially saying > >that > > > >"This > > > > > case is irrelevant for CAR discovery" or "Completely AR unassisted > >CAR > > > > > discovery is optimal for this case too". > > > > > > > >No, i'm not saying this case is irrelevant, or that AR unassisted CAR > > > >discovery > > > >is optimal ... for any case. I'm saying: > > > > > > > >I think that designing for the one access technology case will cripple > > > >the solution. > > > > > > > > > > > > > > IMHO neither requirements nor problem statement should ignore any > >use > > > >cases. > > > > > If they do, it should be explicitly stated so in the spec, so that > > > >designers > > > > > are not misguided to apply solutions to cases for which they are not > > > > > designed. > > > > > > > >Nobody's ignoring any use cases. But if you focus on one sample to the > > > >detriment of the rest, it will cripple your solution. > > > > > > > > Regards, > > > > Henrik > > > > > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world’s largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:20:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13680 for ; Wed, 27 Mar 2002 13:20:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26041; Wed, 27 Mar 2002 13:17:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26006 for ; Wed, 27 Mar 2002 13:17:22 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13329 for ; Wed, 27 Mar 2002 13:17:21 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIHLoq013862 for ; Wed, 27 Mar 2002 19:17:22 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:17:21 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:17:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Dirk.Trossen@nokia.com, henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 19:17:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > I think that's the essence of it. Do you oppose this? Why? Do you > > want to make things more complicated than they have to be? > > > > [DOT] Avoiding flooding of MN with unnecessary information might > complicate > > the design but might also be a worthwhile goal of a > protocol design? > > > > If this is such a big issue then why not a simple > requirement that says > the protocol should make optimal use of network bandwidth, with no > wording in it about whether the network or MN is in control? => Exactly! Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:20:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13694 for ; Wed, 27 Mar 2002 13:20:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26302 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:20:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26041; Wed, 27 Mar 2002 13:17:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26006 for ; Wed, 27 Mar 2002 13:17:22 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13329 for ; Wed, 27 Mar 2002 13:17:21 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIHLoq013862 for ; Wed, 27 Mar 2002 19:17:22 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:17:21 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:17:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Dirk.Trossen@nokia.com, henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 19:17:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > I think that's the essence of it. Do you oppose this? Why? Do you > > want to make things more complicated than they have to be? > > > > [DOT] Avoiding flooding of MN with unnecessary information might > complicate > > the design but might also be a worthwhile goal of a > protocol design? > > > > If this is such a big issue then why not a simple > requirement that says > the protocol should make optimal use of network bandwidth, with no > wording in it about whether the network or MN is in control? => Exactly! Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:24:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13908 for ; Wed, 27 Mar 2002 13:24:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26378; Wed, 27 Mar 2002 13:21:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26346 for ; Wed, 27 Mar 2002 13:21:27 -0500 (EST) Received: from hotmail.com (f35.law9.hotmail.com [64.4.9.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13734 for ; Wed, 27 Mar 2002 13:21:26 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:20:57 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:20:56 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 13:20:56 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:20:57.0156 (UTC) FILETIME=[23A35840:01C1D5BC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > [Govind] Well one example could be in a large mall or airport > > wherein you have > > different APs connected to different providers (at least > > three of them can > > be in a vicinity according to the 802.11 spec). Second, the number > > of different APs gets multiplied by the number of interface > > cards the > > MN has. > >=> As I said, limit it to one operator. None of these issues >will come up. I mean do you really believe that >operators will give each other cost information ? >Or do you believe that they will continuously update >each other so honestly? [Govind] If it is in the MN's profile to do such a handover when it is possible (the MN could have negotiated a deal with the other operator before) then I think we can enforce it cant we? But cost is just one issue, there are others which I pointed out in my earlier mail. > > > Also a question, even if the APs belong to the same AR. > > Could you verify > > that just by looking at the L2 beacon or do you have to > > connect to them > > first and then to the associated AR first to determine that? > >=> That's an interesting point. One thing you could >do is solicit. The RTT for this is about 4 ms on WLAN. >Another way is that there are options in 802.11 >to include the network identity as part of the >beacon. So there are different ways of handling it. [Govind] But to solicit you have to be connected to the other one, and hence disconnect from the first one. Essentially this has to be done for every AP right. And if each one of them is connected to different ones. Also, does RTT depend on exactly where the AR is located or this is an upper limit that you mention? Thanks, Govind. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:24:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13919 for ; Wed, 27 Mar 2002 13:24:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26942 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:24:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26378; Wed, 27 Mar 2002 13:21:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26346 for ; Wed, 27 Mar 2002 13:21:27 -0500 (EST) Received: from hotmail.com (f35.law9.hotmail.com [64.4.9.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13734 for ; Wed, 27 Mar 2002 13:21:26 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:20:57 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:20:56 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 13:20:56 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:20:57.0156 (UTC) FILETIME=[23A35840:01C1D5BC] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > [Govind] Well one example could be in a large mall or airport > > wherein you have > > different APs connected to different providers (at least > > three of them can > > be in a vicinity according to the 802.11 spec). Second, the number > > of different APs gets multiplied by the number of interface > > cards the > > MN has. > >=> As I said, limit it to one operator. None of these issues >will come up. I mean do you really believe that >operators will give each other cost information ? >Or do you believe that they will continuously update >each other so honestly? [Govind] If it is in the MN's profile to do such a handover when it is possible (the MN could have negotiated a deal with the other operator before) then I think we can enforce it cant we? But cost is just one issue, there are others which I pointed out in my earlier mail. > > > Also a question, even if the APs belong to the same AR. > > Could you verify > > that just by looking at the L2 beacon or do you have to > > connect to them > > first and then to the associated AR first to determine that? > >=> That's an interesting point. One thing you could >do is solicit. The RTT for this is about 4 ms on WLAN. >Another way is that there are options in 802.11 >to include the network identity as part of the >beacon. So there are different ways of handling it. [Govind] But to solicit you have to be connected to the other one, and hence disconnect from the first one. Essentially this has to be done for every AP right. And if each one of them is connected to different ones. Also, does RTT depend on exactly where the AR is located or this is an upper limit that you mention? Thanks, Govind. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:25:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13956 for ; Wed, 27 Mar 2002 13:25:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25237; Wed, 27 Mar 2002 13:14:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25192 for ; Wed, 27 Mar 2002 13:14:36 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13115 for ; Wed, 27 Mar 2002 13:14:35 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIEZkY015693 for ; Wed, 27 Mar 2002 19:14:35 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:14:34 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:04:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:14:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, I was saying that the MN can do the CAR in the intertechnology case because it is extremely trivial. If routers advertise their capabilities and the MN has the interface it doesn't need some other AR to tell it that there is a GGSN nearby does it? What I think should be limited is my GGSN/PDSN/AR looking for the AR in Starbucks. I really think it's unreasonable since the MN will know it anyway. I hope this clarifies my comment. Hesham > >- I always said, limit it to the same operator > >and the same access technology. I didn't say > >one or two. I said it is unlikely to get more > >than two if you apply the limitation above. > >I might be wrong and more than happy to hear > >that, but the discussion seems to be going towards > >picking words rather than picking technical reasons. > > > [Govind] Well this is new. Iam curious :) > Intertechnology part is a MUST and it was deemed an > uncontroversial requirement in MPLS and put towards the end > of the presentation as this requirement did not raise ANY > discussion prior to MPLS and even prior to today. > If you had an objection > always, why did you not raise any objection at MPLS? Nor > did you raise any in our quite extensive discussions in GPRS to WLAN > handovers. > > Regards, > Govind. > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:25:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13965 for ; Wed, 27 Mar 2002 13:25:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27251 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:25:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25237; Wed, 27 Mar 2002 13:14:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25192 for ; Wed, 27 Mar 2002 13:14:36 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13115 for ; Wed, 27 Mar 2002 13:14:35 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIEZkY015693 for ; Wed, 27 Mar 2002 19:14:35 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:14:34 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:04:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:14:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, I was saying that the MN can do the CAR in the intertechnology case because it is extremely trivial. If routers advertise their capabilities and the MN has the interface it doesn't need some other AR to tell it that there is a GGSN nearby does it? What I think should be limited is my GGSN/PDSN/AR looking for the AR in Starbucks. I really think it's unreasonable since the MN will know it anyway. I hope this clarifies my comment. Hesham > >- I always said, limit it to the same operator > >and the same access technology. I didn't say > >one or two. I said it is unlikely to get more > >than two if you apply the limitation above. > >I might be wrong and more than happy to hear > >that, but the discussion seems to be going towards > >picking words rather than picking technical reasons. > > > [Govind] Well this is new. Iam curious :) > Intertechnology part is a MUST and it was deemed an > uncontroversial requirement in MPLS and put towards the end > of the presentation as this requirement did not raise ANY > discussion prior to MPLS and even prior to today. > If you had an objection > always, why did you not raise any objection at MPLS? Nor > did you raise any in our quite extensive discussions in GPRS to WLAN > handovers. > > Regards, > Govind. > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:29:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14389 for ; Wed, 27 Mar 2002 13:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26553; Wed, 27 Mar 2002 13:23:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26517 for ; Wed, 27 Mar 2002 13:23:37 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13858 for ; Wed, 27 Mar 2002 13:23:36 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIN6I08673; Wed, 27 Mar 2002 10:23:06 -0800 (PST) Message-ID: <01c801c1d5bc$374792d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hemant Chaskar'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC59@ftmail> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:21:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit George, Please propose an efficiency requirement that does not make it sound like the network is controlling. jak PS: I am suspicious of the apparent assumption that there will be sooooo much capability information. At the most, I think the capabilities will be whether the AR supports this or that wireless protocol. But that is an issue for the protocol design. ----- Original Message ----- From: "George Tsirtsis" To: "'Hemant Chaskar'" ; Sent: Wednesday, March 27, 2002 8:21 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > So, is there anyone that seriously thinks that "blasting GAAR IDs and all of > their capabilities to MN" is a good idea? If not (which I hope so) then the > requirements document should not imply otherwise. > > George > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 4:08 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > I did read your comment and responded as follows in my earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige AR to blast all > GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do > > we need to hide this fact? We can come up with something else, if you do not > > like on-demand extension. I think without such extension the solution > satisfying this requirement may have serious shortcomings that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability set of each). This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:29:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14398 for ; Wed, 27 Mar 2002 13:29:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28326 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26553; Wed, 27 Mar 2002 13:23:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26517 for ; Wed, 27 Mar 2002 13:23:37 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13858 for ; Wed, 27 Mar 2002 13:23:36 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIN6I08673; Wed, 27 Mar 2002 10:23:06 -0800 (PST) Message-ID: <01c801c1d5bc$374792d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hemant Chaskar'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC59@ftmail> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:21:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit George, Please propose an efficiency requirement that does not make it sound like the network is controlling. jak PS: I am suspicious of the apparent assumption that there will be sooooo much capability information. At the most, I think the capabilities will be whether the AR supports this or that wireless protocol. But that is an issue for the protocol design. ----- Original Message ----- From: "George Tsirtsis" To: "'Hemant Chaskar'" ; Sent: Wednesday, March 27, 2002 8:21 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > So, is there anyone that seriously thinks that "blasting GAAR IDs and all of > their capabilities to MN" is a good idea? If not (which I hope so) then the > requirements document should not imply otherwise. > > George > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Wednesday, March 27, 2002 4:08 PM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (was: Examples of CAR discovery) > > > Hi Hernik: > > I did read your comment and responded as follows in my earlier email. > Cut'n'Paste: > > ------------------------------- > If we honestly think that the requirement does not oblige AR to blast all > GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do > > we need to hide this fact? We can come up with something else, if you do not > > like on-demand extension. I think without such extension the solution > satisfying this requirement may have serious shortcomings that I described > in my other email to James. > -------------------------------- > > BR, > Hemant > > > >From: "Henrik Levkowetz" > >To: "Hemant Chaskar" > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > >Hemant, > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > No, the requirement is just fine. It does not require *all* GAAR > >information, it does not require *on-demand operation*, it expresses > >exactly > >what we are in a position to say about the matter now: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > > > > I think that's the essence of it. Do you oppose this? Why? Do you > >want to make things more complicated than they have to be? > > > > Henrik > > > >Hemant wrote: > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless it > > >is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This might > >be a > > > big chunk of data (= number of GAARs times capability set of each). This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in traffic > >over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol allows > > > >the MN to discover the GAAR and capabilities, the MN decides which one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:29:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14416 for ; Wed, 27 Mar 2002 13:29:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26661; Wed, 27 Mar 2002 13:23:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26625 for ; Wed, 27 Mar 2002 13:23:47 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13871 for ; Wed, 27 Mar 2002 13:23:46 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RIO1s00551 for ; Wed, 27 Mar 2002 12:24:01 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:23:40 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:23:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 13:23:07 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVu0XB+egPSFnfT0OZjQ5MFyDdsgAAN1Qg To: , , X-OriginalArrivalTime: 27 Mar 2002 18:23:08.0328 (UTC) FILETIME=[71D29A80:01C1D5BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA26626 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > [DOT] Avoiding flooding of MN with unnecessary information might complicate > the design but might also be a worthwhile goal of a protocol design? > If this is such a big issue then why not a simple requirement that says the protocol should make optimal use of network bandwidth, with no wording in it about whether the network or MN is in control? [DOT] What is "optimal use"? If we demanded for sending all information to MNs, then the optimal use would be bounded to maybe compressing the content, but the optimal use would not consider sending unwanted information if another requirement demanded it, right? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:29:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14425 for ; Wed, 27 Mar 2002 13:29:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28340 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:29:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26661; Wed, 27 Mar 2002 13:23:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26625 for ; Wed, 27 Mar 2002 13:23:47 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13871 for ; Wed, 27 Mar 2002 13:23:46 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RIO1s00551 for ; Wed, 27 Mar 2002 12:24:01 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:23:40 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:23:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 13:23:07 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVu0XB+egPSFnfT0OZjQ5MFyDdsgAAN1Qg To: , , X-OriginalArrivalTime: 27 Mar 2002 18:23:08.0328 (UTC) FILETIME=[71D29A80:01C1D5BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA26626 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > [DOT] Avoiding flooding of MN with unnecessary information might complicate > the design but might also be a worthwhile goal of a protocol design? > If this is such a big issue then why not a simple requirement that says the protocol should make optimal use of network bandwidth, with no wording in it about whether the network or MN is in control? [DOT] What is "optimal use"? If we demanded for sending all information to MNs, then the optimal use would be bounded to maybe compressing the content, but the optimal use would not consider sending unwanted information if another requirement demanded it, right? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:29:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14471 for ; Wed, 27 Mar 2002 13:29:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27559; Wed, 27 Mar 2002 13:26:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27527 for ; Wed, 27 Mar 2002 13:26:55 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14224 for ; Wed, 27 Mar 2002 13:26:54 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RIRDs00783 for ; Wed, 27 Mar 2002 12:27:13 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:26:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:25:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 13:25:56 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVu7IM8QKcVSNWTlOXGPa9MTLOnAAAOoyg To: , X-OriginalArrivalTime: 27 Mar 2002 18:25:57.0690 (UTC) FILETIME=[D6C531A0:01C1D5BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA27528 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, > > Henrik: > > If you are so sure of this interpretation, why don't we add it to > requirement for clarity. Why should leave the requirement text to open > interpretation. Because the requirement is perfectly clear as is. Henrik [DOT] By all due respect, but this is your opinion. There is certain concern on this mailing list that the text is not clear and allows for interpretation, which makes it a controversial requirement. We shouldn't have those in a requirement document, since we're going to have the same discussion when assessing solutions. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:29:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14483 for ; Wed, 27 Mar 2002 13:29:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28372 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:29:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27559; Wed, 27 Mar 2002 13:26:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27527 for ; Wed, 27 Mar 2002 13:26:55 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14224 for ; Wed, 27 Mar 2002 13:26:54 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RIRDs00783 for ; Wed, 27 Mar 2002 12:27:13 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:26:54 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:25:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 13:25:56 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVu7IM8QKcVSNWTlOXGPa9MTLOnAAAOoyg To: , X-OriginalArrivalTime: 27 Mar 2002 18:25:57.0690 (UTC) FILETIME=[D6C531A0:01C1D5BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA27528 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, > > Henrik: > > If you are so sure of this interpretation, why don't we add it to > requirement for clarity. Why should leave the requirement text to open > interpretation. Because the requirement is perfectly clear as is. Henrik [DOT] By all due respect, but this is your opinion. There is certain concern on this mailing list that the text is not clear and allows for interpretation, which makes it a controversial requirement. We shouldn't have those in a requirement document, since we're going to have the same discussion when assessing solutions. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:30:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14532 for ; Wed, 27 Mar 2002 13:30:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27189; Wed, 27 Mar 2002 13:24:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27058 for ; Wed, 27 Mar 2002 13:24:49 -0500 (EST) Received: from hotmail.com (f31.law9.hotmail.com [64.4.9.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09965 for ; Wed, 27 Mar 2002 12:26:30 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:26:03 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:26:02 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 12:26:02 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:26:03.0016 (UTC) FILETIME=[782D7880:01C1D5B4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >=> I think I wasn't too clear. In the anticipated >mode, the assumption I make is that the triggers >are at the AR, so the AR will do the discovery >and forward the info to the MN. Just like >the Prrtradv is FMIPv6. >This is the problem with calling it anticipated, >it gives the impression that anticipated must >be network controlled. which is not the case >of course. > >GT> What you are saying is that CAR discovery can be network controlled but >the actual handoff may be MN controlled? In which case this is a bit weird >in that the network knows exactly what the MN is going to do next but lets >the MN do it...hmm anyway, I do not have a problem with that although I do >not like it either. [Govind] CAR discovery does not know where the MN will actually handover to TAR selection knows that. Yes, the TAR selection algorithm could potentially choose from the CARs but it needn't too. Example: the case wherein the MN forces a handover to a particular AP (this can be done again either in the network or the MN)whose association is with say AR1 and AR1 not currently recognized as a GAAR by the CAR discovery process. Hope this makes it clear. -Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:30:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14542 for ; Wed, 27 Mar 2002 13:30:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28561 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:30:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27189; Wed, 27 Mar 2002 13:24:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27058 for ; Wed, 27 Mar 2002 13:24:49 -0500 (EST) Received: from hotmail.com (f31.law9.hotmail.com [64.4.9.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09965 for ; Wed, 27 Mar 2002 12:26:30 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 09:26:03 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 17:26:02 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 12:26:02 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 17:26:03.0016 (UTC) FILETIME=[782D7880:01C1D5B4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org >=> I think I wasn't too clear. In the anticipated >mode, the assumption I make is that the triggers >are at the AR, so the AR will do the discovery >and forward the info to the MN. Just like >the Prrtradv is FMIPv6. >This is the problem with calling it anticipated, >it gives the impression that anticipated must >be network controlled. which is not the case >of course. > >GT> What you are saying is that CAR discovery can be network controlled but >the actual handoff may be MN controlled? In which case this is a bit weird >in that the network knows exactly what the MN is going to do next but lets >the MN do it...hmm anyway, I do not have a problem with that although I do >not like it either. [Govind] CAR discovery does not know where the MN will actually handover to TAR selection knows that. Yes, the TAR selection algorithm could potentially choose from the CARs but it needn't too. Example: the case wherein the MN forces a handover to a particular AP (this can be done again either in the network or the MN)whose association is with say AR1 and AR1 not currently recognized as a GAAR by the CAR discovery process. Hope this makes it clear. -Govind. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:31:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14607 for ; Wed, 27 Mar 2002 13:31:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25787; Wed, 27 Mar 2002 13:15:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25745 for ; Wed, 27 Mar 2002 13:15:43 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13164 for ; Wed, 27 Mar 2002 13:15:42 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIEeI08301; Wed, 27 Mar 2002 10:14:40 -0800 (PST) Message-ID: <01a001c1d5bb$09a84d70$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:13:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > [DOT] Avoiding flooding of MN with unnecessary information might complicate > the design but might also be a worthwhile goal of a protocol design? > If this is such a big issue then why not a simple requirement that says the protocol should make optimal use of network bandwidth, with no wording in it about whether the network or MN is in control? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:31:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14618 for ; Wed, 27 Mar 2002 13:31:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28802 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:31:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25787; Wed, 27 Mar 2002 13:15:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25745 for ; Wed, 27 Mar 2002 13:15:43 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13164 for ; Wed, 27 Mar 2002 13:15:42 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIEeI08301; Wed, 27 Mar 2002 10:14:40 -0800 (PST) Message-ID: <01a001c1d5bb$09a84d70$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:13:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > I think that's the essence of it. Do you oppose this? Why? Do you > want to make things more complicated than they have to be? > > [DOT] Avoiding flooding of MN with unnecessary information might complicate > the design but might also be a worthwhile goal of a protocol design? > If this is such a big issue then why not a simple requirement that says the protocol should make optimal use of network bandwidth, with no wording in it about whether the network or MN is in control? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:31:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14637 for ; Wed, 27 Mar 2002 13:31:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28309; Wed, 27 Mar 2002 13:29:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28240 for ; Wed, 27 Mar 2002 13:28:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14378 for ; Wed, 27 Mar 2002 13:28:55 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RISQI08878; Wed, 27 Mar 2002 10:28:26 -0800 (PST) Message-ID: <01f401c1d5bc$f5dc0690$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:26:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, This is too radio specific. What about IR, where there may be no power considerations? How about: The CAR discovery protocol MUST make efficient use of network bandwidth, particularly on the wireless link. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Wednesday, March 27, 2002 4:33 PM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > James: > > And formulating a generic requirement without studying its performance > impact on all possible cases is even worse, IMHO. > > I explicitly make my "disagreement" known over this requirement in its > current form, in case you are counting votes. It needs some extension. > > At least this one: > > "The impact of this on power, wireless bandwidth and mobile terminal's > interface capabilities MUST be considered". > > BR, > Hemant > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 08:20:02 -0800 > > > >Hemant, > > > >Like I said, premature optimization is always a bad idea. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: > >Sent: Wednesday, March 27, 2002 12:40 AM > >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless > >it is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution > >satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This > >might be a > > > big chunk of data (= number of GAARs times capability set of each). > >This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in > >traffic over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that > >it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This > >means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which > >satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there > >is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol > >allows > > > >the MN to discover the GAAR and capabilities, the MN decides which > >one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is > >clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include > >this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:31:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14648 for ; Wed, 27 Mar 2002 13:31:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28870 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:31:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28309; Wed, 27 Mar 2002 13:29:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28240 for ; Wed, 27 Mar 2002 13:28:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14378 for ; Wed, 27 Mar 2002 13:28:55 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RISQI08878; Wed, 27 Mar 2002 10:28:26 -0800 (PST) Message-ID: <01f401c1d5bc$f5dc0690$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:26:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hemant, This is too radio specific. What about IR, where there may be no power considerations? How about: The CAR discovery protocol MUST make efficient use of network bandwidth, particularly on the wireless link. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Wednesday, March 27, 2002 4:33 PM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > James: > > And formulating a generic requirement without studying its performance > impact on all possible cases is even worse, IMHO. > > I explicitly make my "disagreement" known over this requirement in its > current form, in case you are counting votes. It needs some extension. > > At least this one: > > "The impact of this on power, wireless bandwidth and mobile terminal's > interface capabilities MUST be considered". > > BR, > Hemant > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > >Date: Wed, 27 Mar 2002 08:20:02 -0800 > > > >Hemant, > > > >Like I said, premature optimization is always a bad idea. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: > >Sent: Wednesday, March 27, 2002 12:40 AM > >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of CAR discovery) > > > > > > > Hi James: > > > > > > There are serious shortcomings of the solution satisfying this > >requirement. > > > They are described below. How can we finalise this requirement unless > >it is > > > agreed that these pitfalls do not exist? > > > > > > For this, it might be good idea to visualise how the solution > >satisfying > > > this requirement looks like and violates basic tenets of engineering > >design, > > > namely efficiency. The solution satisfying this requirement is obliged > >to > > > blast GAAR IDs and their capabilities on MN when AR sees MN. This > >might be a > > > big chunk of data (= number of GAARs times capability set of each). > >This > > > flood will occur either on active traffic connection which I call case > >(i) > > > (relevant for single interface MN and two-interface MN where second > > > interface is sleeping) or on second interface which I call case (ii) > > > (relevant for two interface MN with both interfaces awake). There are > > > following effects of this flood: > > > > > > 1. Disruption in traffic: For case (i), it causes disruption in > >traffic over > > > active traffic channel. > > > > > > 2. Power wastage: For both cases (i) and (ii), receiving this flood > >causes > > > power wastage. This is because, after receiving these capabilities MN > >either > > > rejects the new AR (which is worst), and even if it selcects one why > >does it > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that > >it > > > sees. Which means the same information (which could be big enough) is > > > transmitted on downlink so many times. This takes up considerable > >fraction > > > of downlink capacity. > > > > > > 4. Limit on capability definition: This requirement restricts the > >definition > > > of capabilities to a very small size, otherwise all ARs will only be > > > transmitting GAAR capabilities to different MNs all the time. This > >means > > > capability set cannot be comprehensive and extensible. > > > > > > So, IMHO rather than counting who agrees to one statement requirement > >that > > > you proposed and who have not, we should first analyse above harmful > >effects > > > before deciding either way. > > > > > > Br, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Govind Krishnamurthi" , > > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: > > > >Examples of CAR discovery) > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > >, > > > > > So now you agree that the AR can hand over the list of GAARs and > > > > > their capabilities to the MN (maybe only pass on those which > >satisfy > > > > > the MN requirements, which is what CAR discovery was originally > > > >about). > > > > > > > > > > > > >No, that it sends all, along with the capabilities. Let me repeat the > > > >requirement I would like to see (and Henrik apparently agrees) so we > >are > > > >clear on this: > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > information, along with capabilities. > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > >discovery. > > > > > This seems contradictory to your earlier mails saying that there > >is > > > > > no basis for network based CAR discovery. So are you now agreeing > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > >Please see the requirement above. No contradiction. The protocol > >allows > > > >the MN to discover the GAAR and capabilities, the MN decides which > >one > > > >it wants. > > > >Nothing about the AR in control of anything. The MN may use a variant > >of > > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a > > > >protocol design, not a requirement, choice. The requirement is > >clearly > > > >that the MN does the discovery. > > > > > > > >We now have two working group members who want this reqirement worded > > > >just this way. Nothing about "as the MN expresses its preferences" or > > > >"by the CAR discovery module" or anything else. And I believe Hesham > >has > > > >also expressed a preference for this requirement. > > > > > > > >Anybody else out there have an opinion on this? Should we include > >this > > > >requirement instead of requirement 3.4, which has the AR in control? > > > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:32:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14683 for ; Wed, 27 Mar 2002 13:32:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27473; Wed, 27 Mar 2002 13:26:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27444 for ; Wed, 27 Mar 2002 13:26:37 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14192 for ; Wed, 27 Mar 2002 13:26:36 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIQaoq015478 for ; Wed, 27 Mar 2002 19:26:36 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:26:36 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:26:36 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:26:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > >=> As I said, limit it to one operator. None of these issues > >will come up. I mean do you really believe that > >operators will give each other cost information ? > >Or do you believe that they will continuously update > >each other so honestly? > > [Govind] If it is in the MN's profile to do such a handover > when it is > possible (the MN could have negotiated a deal with the > other operator > before) then I think we can enforce it cant we? But cost is just > one issue, there are others which I pointed out in my earlier mail. => Well I still anxously await the contents of this profile and how it is transferred. Also why do you think that the capabilities will change sooo often but the profile won't ? > >=> That's an interesting point. One thing you could > >do is solicit. The RTT for this is about 4 ms on WLAN. > >Another way is that there are options in 802.11 > >to include the network identity as part of the > >beacon. So there are different ways of handling it. > > [Govind] But to solicit you have to be connected to the other one, > and hence disconnect from the first one. Essentially this has > to be done for every AP right. And if each one of them is connected > to different ones. => As I said there are 2 options, RSs or use the network id in the beacon. If you're uncomfortable with the (roughly) 20 - 30 ms delay to dicover a GAAR, then you can use the information in the beacon. Also, does RTT depend on exactly where > the AR is located > or this is an upper limit that you mention? => People don't usually put APs in the airport and the AR in the city (in the WLAN case), so the RS RTT time will not vary that much. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:32:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14692 for ; Wed, 27 Mar 2002 13:32:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28955 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:32:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27473; Wed, 27 Mar 2002 13:26:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27444 for ; Wed, 27 Mar 2002 13:26:37 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14192 for ; Wed, 27 Mar 2002 13:26:36 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIQaoq015478 for ; Wed, 27 Mar 2002 19:26:36 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:26:36 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:26:36 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:26:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > >=> As I said, limit it to one operator. None of these issues > >will come up. I mean do you really believe that > >operators will give each other cost information ? > >Or do you believe that they will continuously update > >each other so honestly? > > [Govind] If it is in the MN's profile to do such a handover > when it is > possible (the MN could have negotiated a deal with the > other operator > before) then I think we can enforce it cant we? But cost is just > one issue, there are others which I pointed out in my earlier mail. => Well I still anxously await the contents of this profile and how it is transferred. Also why do you think that the capabilities will change sooo often but the profile won't ? > >=> That's an interesting point. One thing you could > >do is solicit. The RTT for this is about 4 ms on WLAN. > >Another way is that there are options in 802.11 > >to include the network identity as part of the > >beacon. So there are different ways of handling it. > > [Govind] But to solicit you have to be connected to the other one, > and hence disconnect from the first one. Essentially this has > to be done for every AP right. And if each one of them is connected > to different ones. => As I said there are 2 options, RSs or use the network id in the beacon. If you're uncomfortable with the (roughly) 20 - 30 ms delay to dicover a GAAR, then you can use the information in the beacon. Also, does RTT depend on exactly where > the AR is located > or this is an upper limit that you mention? => People don't usually put APs in the airport and the AR in the city (in the WLAN case), so the RS RTT time will not vary that much. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:34:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14785 for ; Wed, 27 Mar 2002 13:34:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28130; Wed, 27 Mar 2002 13:28:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28078 for ; Wed, 27 Mar 2002 13:28:05 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14337 for ; Wed, 27 Mar 2002 13:28:03 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28752 for ; Wed, 27 Mar 2002 19:25:08 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 19:27:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind wrote: > [Govind] There is a bias and I agree that the bias should be removed. > > But > what you are suggesting is to swing the pendulum to the opposite end > putting an MN bias. We should work toward an un-biased set of requirements, > IMHO, and thats what I will endeavor to do based on the discussions in the > mailing list. Yes, yes! That is what we are suggesting! That there *needs* to be a bias towards the MN, that whatever we design which does not give this to the MN will not provide the User with what he wants and needs, and ultimately won't be deployed and used. I thought Steve was so clear in Minneapolis, and the case so clear as well, that I did not expect this resistance. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:34:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14798 for ; Wed, 27 Mar 2002 13:34:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29068 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:34:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28130; Wed, 27 Mar 2002 13:28:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28078 for ; Wed, 27 Mar 2002 13:28:05 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14337 for ; Wed, 27 Mar 2002 13:28:03 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28752 for ; Wed, 27 Mar 2002 19:25:08 +0100 From: "Henrik Levkowetz" To: Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 19:27:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind wrote: > [Govind] There is a bias and I agree that the bias should be removed. > > But > what you are suggesting is to swing the pendulum to the opposite end > putting an MN bias. We should work toward an un-biased set of requirements, > IMHO, and thats what I will endeavor to do based on the discussions in the > mailing list. Yes, yes! That is what we are suggesting! That there *needs* to be a bias towards the MN, that whatever we design which does not give this to the MN will not provide the User with what he wants and needs, and ultimately won't be deployed and used. I thought Steve was so clear in Minneapolis, and the case so clear as well, that I did not expect this resistance. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:40:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15195 for ; Wed, 27 Mar 2002 13:40:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29691; Wed, 27 Mar 2002 13:38:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29662 for ; Wed, 27 Mar 2002 13:38:08 -0500 (EST) Received: from hotmail.com (f59.law9.hotmail.com [64.4.9.59]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15036 for ; Wed, 27 Mar 2002 13:38:07 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:37:38 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:37:38 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 13:37:38 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:37:38.0677 (UTC) FILETIME=[78975250:01C1D5BE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, Thanks for the clarification. >Govind, > >I was saying that the MN can do the CAR >in the intertechnology case because it >is extremely trivial. If routers advertise >their capabilities and the MN has the interface >it doesn't need some other AR to tell it >that there is a GGSN nearby does it? [Govind] Ofcourse, this assumes that the MN may have to connect to each and every AP in the neighborhood and solicit. This is fine with me. > >What I think should be limited is my GGSN/PDSN/AR >looking for the AR in Starbucks. I really think >it's unreasonable since the MN will know it >anyway. [Govind] I totally agree that an extensive search process like what you propose may include extensive searches over multiple domains, which is quite infeasible. But there may be other ways in which the MN and AR can cooperate and help in such situations too, is it not? All I want the requirement to allow is for people to explore such cooperation if possible in solutions. I just want requirements should be too restrictive. Is that acceptible to you? Ofcourse you may always have the choice to reject it if some one comes up with solutions that make too many impractical assumptions. But why should we say no now before we know what solutions are possible. Just my opinion thats all. Regards, -Govind _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:40:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15204 for ; Wed, 27 Mar 2002 13:40:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29830 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:40:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29691; Wed, 27 Mar 2002 13:38:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29662 for ; Wed, 27 Mar 2002 13:38:08 -0500 (EST) Received: from hotmail.com (f59.law9.hotmail.com [64.4.9.59]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15036 for ; Wed, 27 Mar 2002 13:38:07 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:37:38 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:37:38 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 13:37:38 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:37:38.0677 (UTC) FILETIME=[78975250:01C1D5BE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, Thanks for the clarification. >Govind, > >I was saying that the MN can do the CAR >in the intertechnology case because it >is extremely trivial. If routers advertise >their capabilities and the MN has the interface >it doesn't need some other AR to tell it >that there is a GGSN nearby does it? [Govind] Ofcourse, this assumes that the MN may have to connect to each and every AP in the neighborhood and solicit. This is fine with me. > >What I think should be limited is my GGSN/PDSN/AR >looking for the AR in Starbucks. I really think >it's unreasonable since the MN will know it >anyway. [Govind] I totally agree that an extensive search process like what you propose may include extensive searches over multiple domains, which is quite infeasible. But there may be other ways in which the MN and AR can cooperate and help in such situations too, is it not? All I want the requirement to allow is for people to explore such cooperation if possible in solutions. I just want requirements should be too restrictive. Is that acceptible to you? Ofcourse you may always have the choice to reject it if some one comes up with solutions that make too many impractical assumptions. But why should we say no now before we know what solutions are possible. Just my opinion thats all. Regards, -Govind _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:42:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15275 for ; Wed, 27 Mar 2002 13:42:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29326; Wed, 27 Mar 2002 13:36:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29291 for ; Wed, 27 Mar 2002 13:36:21 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14935 for ; Wed, 27 Mar 2002 13:36:20 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIZlI09158; Wed, 27 Mar 2002 10:35:47 -0800 (PST) Message-ID: <020601c1d5bd$fd05de40$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hesham Soliman \(ERA\)'" , "'Hemant Chaskar'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC5A@ftmail> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:34:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit George, Right, this is what we have been arguing about with Dirk, Hemant, and Govind. The MN should get the GAARs and decide. The requirement I posted does not say that the AR sends those to the MN, it says that the protocol should provide them to the MN. Exactly how is the task of the protocol design. Dirk, Hemant, and Govind have been making the assumption that they have to come from one specific AR, this might not be the case, but, it depends on the design. However, I am sympathetic to the efficiency argument and have no objection to a network efficiency requirement. I posted one in a response to Hemant's message. So, let me ask again, do you like the requirement I posted or not? jak PS: . Frankly, I am somewhat skeptical that so much information will be involved, but, again, that is solution space. ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; "'Hemant Chaskar'" ; Sent: Wednesday, March 27, 2002 8:40 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > > Hesham relax :-) > > The "extra option" on the RA may or may not be a problem. We will only know > if this is a problem AFTER we know what "capabilities" mean i.e.: how much > data can be in there for the list of GAARs. That does make me nervous, > doesn't you? > > The problem of course starts from the fact that one AR is supposed to > provide this list of GAARs + capabilities to the MN (which could be a lot of > info). In a MN centric approach the MN knows which the GAARs are and gets > their capabilities directly from them...much better IMO. > > George > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:33 PM > To: 'George Tsirtsis'; 'Hemant Chaskar'; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (wa s: Examples of CAR discovery) > > > What is iths blöasting that people keep > bringing up? an extra option in an RA is blasting ???? > What is the alternative: The magic AR that knows > everything ?????????????? > > Seriously, let's keep it simple or this whole > protocol will start collapsing the moment > anyone starts deploying it. Of course if deployment > is not a concern then I'll just og back to sleep! > > Hesham > > > -----Original Message----- > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > Sent: Wednesday, March 27, 2002 5:21 PM > > To: 'Hemant Chaskar'; seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (wa s: Examples of CAR discovery) > > > > > > So, is there anyone that seriously thinks that "blasting > > GAAR IDs and all of > > their capabilities to MN" is a good idea? If not (which I > > hope so) then the > > requirements document should not imply otherwise. > > > > George > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Wednesday, March 27, 2002 4:08 PM > > To: seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (was: Examples of CAR discovery) > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my > > earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige > > AR to blast all > > GAAR IDs and all of their capabilities to MN, why not say > > so clearly. Why do > > > > we need to hide this fact? We can come up with something > > else, if you do not > > > > like on-demand extension. I think without such extension > > the solution > > satisfying this requirement may have serious shortcomings > > that I described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it > > expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? > > Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this > > requirement unless it > > > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the > > solution satisfying > > > > this requirement looks like and violates basic tenets > > of engineering > > >design, > > > > namely efficiency. The solution satisfying this > > requirement is obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR > > sees MN. This might > > >be a > > > > big chunk of data (= number of GAARs times capability > > set of each). This > > > > flood will occur either on active traffic connection > > which I call case > > >(i) > > > > (relevant for single interface MN and two-interface MN > > where second > > > > interface is sleeping) or on second interface which I > > call case (ii) > > > > (relevant for two interface MN with both interfaces > > awake). There are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > disruption in traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > receiving this flood > > >causes > > > > power wastage. This is because, after receiving these > > capabilities MN > > >either > > > > rejects the new AR (which is worst), and even if it > > selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > every MN that it > > > > sees. Which means the same information (which could be > > big enough) is > > > > transmitted on downlink so many times. This takes up > > considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement > > restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs > > will only be > > > > transmitting GAAR capabilities to different MNs all the > > time. This means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one > > statement requirement > > >that > > > > you proposed and who have not, we should first analyse > > above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list > > of GAARs and > > > > > > their capabilities to the MN (maybe only pass on > > those which satisfy > > > > > > the MN requirements, which is what CAR discovery > > was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > Let me repeat the > > > > >requirement I would like to see (and Henrik apparently > > agrees) so we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails > > saying that there is > > > > > > no basis for network based CAR discovery. So are > > you now agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > The protocol allows > > > > >the MN to discover the GAAR and capabilities, the MN > > decides which one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN > > may use a variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved > > somehow, but that's a > > > > >protocol design, not a requirement, choice. The > > requirement is clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this > > reqirement worded > > > > >just this way. Nothing about "as the MN expresses its > > preferences" or > > > > >"by the CAR discovery module" or anything else. And I > > believe Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should > > we include this > > > > >requirement instead of requirement 3.4, which has the > > AR in control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:42:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15282 for ; Wed, 27 Mar 2002 13:42:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29914 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:42:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29326; Wed, 27 Mar 2002 13:36:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29291 for ; Wed, 27 Mar 2002 13:36:21 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14935 for ; Wed, 27 Mar 2002 13:36:20 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIZlI09158; Wed, 27 Mar 2002 10:35:47 -0800 (PST) Message-ID: <020601c1d5bd$fd05de40$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hesham Soliman \(ERA\)'" , "'Hemant Chaskar'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC5A@ftmail> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:34:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit George, Right, this is what we have been arguing about with Dirk, Hemant, and Govind. The MN should get the GAARs and decide. The requirement I posted does not say that the AR sends those to the MN, it says that the protocol should provide them to the MN. Exactly how is the task of the protocol design. Dirk, Hemant, and Govind have been making the assumption that they have to come from one specific AR, this might not be the case, but, it depends on the design. However, I am sympathetic to the efficiency argument and have no objection to a network efficiency requirement. I posted one in a response to Hemant's message. So, let me ask again, do you like the requirement I posted or not? jak PS: . Frankly, I am somewhat skeptical that so much information will be involved, but, again, that is solution space. ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; "'Hemant Chaskar'" ; Sent: Wednesday, March 27, 2002 8:40 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > > Hesham relax :-) > > The "extra option" on the RA may or may not be a problem. We will only know > if this is a problem AFTER we know what "capabilities" mean i.e.: how much > data can be in there for the list of GAARs. That does make me nervous, > doesn't you? > > The problem of course starts from the fact that one AR is supposed to > provide this list of GAARs + capabilities to the MN (which could be a lot of > info). In a MN centric approach the MN knows which the GAARs are and gets > their capabilities directly from them...much better IMO. > > George > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:33 PM > To: 'George Tsirtsis'; 'Hemant Chaskar'; seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (wa s: Examples of CAR discovery) > > > What is iths blöasting that people keep > bringing up? an extra option in an RA is blasting ???? > What is the alternative: The magic AR that knows > everything ?????????????? > > Seriously, let's keep it simple or this whole > protocol will start collapsing the moment > anyone starts deploying it. Of course if deployment > is not a concern then I'll just og back to sleep! > > Hesham > > > -----Original Message----- > > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > > Sent: Wednesday, March 27, 2002 5:21 PM > > To: 'Hemant Chaskar'; seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (wa s: Examples of CAR discovery) > > > > > > So, is there anyone that seriously thinks that "blasting > > GAAR IDs and all of > > their capabilities to MN" is a good idea? If not (which I > > hope so) then the > > requirements document should not imply otherwise. > > > > George > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Wednesday, March 27, 2002 4:08 PM > > To: seamoby@ietf.org > > Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > (was: Examples of CAR discovery) > > > > > > Hi Hernik: > > > > I did read your comment and responded as follows in my > > earlier email. > > Cut'n'Paste: > > > > ------------------------------- > > If we honestly think that the requirement does not oblige > > AR to blast all > > GAAR IDs and all of their capabilities to MN, why not say > > so clearly. Why do > > > > we need to hide this fact? We can come up with something > > else, if you do not > > > > like on-demand extension. I think without such extension > > the solution > > satisfying this requirement may have serious shortcomings > > that I described > > in my other email to James. > > -------------------------------- > > > > BR, > > Hemant > > > > > > >From: "Henrik Levkowetz" > > >To: "Hemant Chaskar" > > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: Examples of CAR discovery) > > >Date: Wed, 27 Mar 2002 02:09:44 +0100 > > > > > >Hemant, > > > > > > You apparently did not read my recent posting. Cut'n'Paste: > > > > > > No, the requirement is just fine. It does not require *all* GAAR > > >information, it does not require *on-demand operation*, it > > expresses > > >exactly > > >what we are in a position to say about the matter now: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > > > > > I think that's the essence of it. Do you oppose this? > > Why? Do you > > >want to make things more complicated than they have to be? > > > > > > Henrik > > > > > >Hemant wrote: > > > > > > > > Hi James: > > > > > > > > There are serious shortcomings of the solution satisfying this > > >requirement. > > > > They are described below. How can we finalise this > > requirement unless it > > > > >is > > > > agreed that these pitfalls do not exist? > > > > > > > > For this, it might be good idea to visualise how the > > solution satisfying > > > > this requirement looks like and violates basic tenets > > of engineering > > >design, > > > > namely efficiency. The solution satisfying this > > requirement is obliged > > >to > > > > blast GAAR IDs and their capabilities on MN when AR > > sees MN. This might > > >be a > > > > big chunk of data (= number of GAARs times capability > > set of each). This > > > > flood will occur either on active traffic connection > > which I call case > > >(i) > > > > (relevant for single interface MN and two-interface MN > > where second > > > > interface is sleeping) or on second interface which I > > call case (ii) > > > > (relevant for two interface MN with both interfaces > > awake). There are > > > > following effects of this flood: > > > > > > > > 1. Disruption in traffic: For case (i), it causes > > disruption in traffic > > >over > > > > active traffic channel. > > > > > > > > 2. Power wastage: For both cases (i) and (ii), > > receiving this flood > > >causes > > > > power wastage. This is because, after receiving these > > capabilities MN > > >either > > > > rejects the new AR (which is worst), and even if it > > selcects one why > > >does it > > > > need to receive capabilities of GAARs that do not matter for it. > > > > > > > > 3. Bandwidth wastage: An AR needs to send this flood to > > every MN that it > > > > sees. Which means the same information (which could be > > big enough) is > > > > transmitted on downlink so many times. This takes up > > considerable > > >fraction > > > > of downlink capacity. > > > > > > > > 4. Limit on capability definition: This requirement > > restricts the > > >definition > > > > of capabilities to a very small size, otherwise all ARs > > will only be > > > > transmitting GAAR capabilities to different MNs all the > > time. This means > > > > capability set cannot be comprehensive and extensible. > > > > > > > > So, IMHO rather than counting who agrees to one > > statement requirement > > >that > > > > you proposed and who have not, we should first analyse > > above harmful > > >effects > > > > before deciding either way. > > > > > > > > Br, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Govind Krishnamurthi" , > > > > > > >Subject: [Seamoby] Concensus call on new CAR Discovery > > Requirement > > >(was: > > > > >Examples of CAR discovery) > > > > >Date: Tue, 26 Mar 2002 15:40:36 -0800 > > > > > > > > > >, > > > > > > So now you agree that the AR can hand over the list > > of GAARs and > > > > > > their capabilities to the MN (maybe only pass on > > those which satisfy > > > > > > the MN requirements, which is what CAR discovery > > was originally > > > > >about). > > > > > > > > > > > > > > > >No, that it sends all, along with the capabilities. > > Let me repeat the > > > > >requirement I would like to see (and Henrik apparently > > agrees) so we > > >are > > > > >clear on this: > > > > > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > > > information, along with capabilities. > > > > > > > > > > > > > > > > Which first implies that the network is taking care of CAR > > >discovery. > > > > > > This seems contradictory to your earlier mails > > saying that there is > > > > > > no basis for network based CAR discovery. So are > > you now agreeing > > > > > > that network based CAR discovery has its place? > > > > > > > > > > > > > > > >Please see the requirement above. No contradiction. > > The protocol allows > > > > >the MN to discover the GAAR and capabilities, the MN > > decides which one > > > > >it wants. > > > > >Nothing about the AR in control of anything. The MN > > may use a variant > > >of > > > > >IPv6 neighbor discovery, the AR may be involved > > somehow, but that's a > > > > >protocol design, not a requirement, choice. The > > requirement is clearly > > > > >that the MN does the discovery. > > > > > > > > > >We now have two working group members who want this > > reqirement worded > > > > >just this way. Nothing about "as the MN expresses its > > preferences" or > > > > >"by the CAR discovery module" or anything else. And I > > believe Hesham > > >has > > > > >also expressed a preference for this requirement. > > > > > > > > > >Anybody else out there have an opinion on this? Should > > we include this > > > > >requirement instead of requirement 3.4, which has the > > AR in control? > > > > > > > > > > jak > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:43:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15395 for ; Wed, 27 Mar 2002 13:43:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29774; Wed, 27 Mar 2002 13:38:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29739 for ; Wed, 27 Mar 2002 13:38:31 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15062 for ; Wed, 27 Mar 2002 13:38:29 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28997; Wed, 27 Mar 2002 19:35:31 +0100 From: "Henrik Levkowetz" To: , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 19:38:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > > > > If you are so sure of this interpretation, why don't we add it to > > requirement for clarity. Why should leave the requirement text to open > > interpretation. > > Because the requirement is perfectly clear as is. > > Henrik > > [DOT] By all due respect, but this is your opinion. There is certain concern > on this mailing list that the text is not clear and allows for interpretation, > which makes it a controversial requirement. We shouldn't have those in a requirement > document, since we're going to have the same discussion when assessing solutions. Certainly this is my opinion! And going back, I seem to see that there is ONE person who started out misapprehending this. That does not make it controversial, that makes it a misapprehension. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:43:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15402 for ; Wed, 27 Mar 2002 13:43:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29954 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:43:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29774; Wed, 27 Mar 2002 13:38:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29739 for ; Wed, 27 Mar 2002 13:38:31 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15062 for ; Wed, 27 Mar 2002 13:38:29 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id TAA28997; Wed, 27 Mar 2002 19:35:31 +0100 From: "Henrik Levkowetz" To: , Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 19:38:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, > > > > If you are so sure of this interpretation, why don't we add it to > > requirement for clarity. Why should leave the requirement text to open > > interpretation. > > Because the requirement is perfectly clear as is. > > Henrik > > [DOT] By all due respect, but this is your opinion. There is certain concern > on this mailing list that the text is not clear and allows for interpretation, > which makes it a controversial requirement. We shouldn't have those in a requirement > document, since we're going to have the same discussion when assessing solutions. Certainly this is my opinion! And going back, I seem to see that there is ONE person who started out misapprehending this. That does not make it controversial, that makes it a misapprehension. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:46:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15543 for ; Wed, 27 Mar 2002 13:46:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29859; Wed, 27 Mar 2002 13:40:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29818 for ; Wed, 27 Mar 2002 13:40:51 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15192 for ; Wed, 27 Mar 2002 13:40:50 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIeJI09414; Wed, 27 Mar 2002 10:40:19 -0800 (PST) Message-ID: <022a01c1d5be$9ef05e60$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hesham Soliman \(ERA\)'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC5B@ftmail> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:38:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit George, I do not see CAR discovery as such an issue for cellular specifically, IMHO it is more for intertechnology handover. There may be a role in intratechnology handover, but I have a hard time seeing how different routers with the same underlying radio technology would be enough different to require it. Seems better to just let the wireless layer 2 take care of the handover at that point. But this is not material to the requirements discussion I think. jak ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; Sent: Wednesday, March 27, 2002 8:57 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:48 PM > To: 'George Tsirtsis'; Hesham Soliman (ERA); 'Hemant Chaskar'; > seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (wa s: Examples of CAR discovery) > > > > > > The "extra option" on the RA may or may not be a problem. > > We will only know > > if this is a problem AFTER we know what "capabilities" mean > > i.e.: how much > > data can be in there for the list of GAARs. That does make > > me nervous, > > doesn't you? > > => I agree, but only if you assume that GAAR > discovery will cover a very large number of > GAARs. This is where I think that the assumptions are > flawed. If we limit the AR-based discovery to one > operator's network and one access tech, then we are > most likely to end up with one or two GAARs. > Right ? > > GT> In cellular deployment each AR will have up to 6 GAARs assuming ARs on > each BS/AP. What you say above is that the protocol we are talking about is > clever enough to know between which 2 or 3 ARs the MN is currently located. > In the "anticipated" mode CAR discovery takes place prior to handoff so I am > not sure your assumption will always hold. Or maybe I have misunderstood > something? > > > > > The problem of course starts from the fact that one AR is > > supposed to > > provide this list of GAARs + capabilities to the MN (which > > could be a lot of > > info). In a MN centric approach the MN knows which the > > GAARs are and gets > > their capabilities directly from them...much better IMO. > > => Can't agree more. > > GT> I suspected as much...I think that was the general feeling during the WG > meeting and after Steve's presentation. > > Thanks > George > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:46:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15553 for ; Wed, 27 Mar 2002 13:46:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00100 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:46:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29859; Wed, 27 Mar 2002 13:40:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29818 for ; Wed, 27 Mar 2002 13:40:51 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15192 for ; Wed, 27 Mar 2002 13:40:50 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIeJI09414; Wed, 27 Mar 2002 10:40:19 -0800 (PST) Message-ID: <022a01c1d5be$9ef05e60$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hesham Soliman \(ERA\)'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC5B@ftmail> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 10:38:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit George, I do not see CAR discovery as such an issue for cellular specifically, IMHO it is more for intertechnology handover. There may be a role in intratechnology handover, but I have a hard time seeing how different routers with the same underlying radio technology would be enough different to require it. Seems better to just let the wireless layer 2 take care of the handover at that point. But this is not material to the requirements discussion I think. jak ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; Sent: Wednesday, March 27, 2002 8:57 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:48 PM > To: 'George Tsirtsis'; Hesham Soliman (ERA); 'Hemant Chaskar'; > seamoby@ietf.org > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement > (wa s: Examples of CAR discovery) > > > > > > The "extra option" on the RA may or may not be a problem. > > We will only know > > if this is a problem AFTER we know what "capabilities" mean > > i.e.: how much > > data can be in there for the list of GAARs. That does make > > me nervous, > > doesn't you? > > => I agree, but only if you assume that GAAR > discovery will cover a very large number of > GAARs. This is where I think that the assumptions are > flawed. If we limit the AR-based discovery to one > operator's network and one access tech, then we are > most likely to end up with one or two GAARs. > Right ? > > GT> In cellular deployment each AR will have up to 6 GAARs assuming ARs on > each BS/AP. What you say above is that the protocol we are talking about is > clever enough to know between which 2 or 3 ARs the MN is currently located. > In the "anticipated" mode CAR discovery takes place prior to handoff so I am > not sure your assumption will always hold. Or maybe I have misunderstood > something? > > > > > The problem of course starts from the fact that one AR is > > supposed to > > provide this list of GAARs + capabilities to the MN (which > > could be a lot of > > info). In a MN centric approach the MN knows which the > > GAARs are and gets > > their capabilities directly from them...much better IMO. > > => Can't agree more. > > GT> I suspected as much...I think that was the general feeling during the WG > meeting and after Steve's presentation. > > Thanks > George > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:47:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15644 for ; Wed, 27 Mar 2002 13:47:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00063; Wed, 27 Mar 2002 13:45:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00032 for ; Wed, 27 Mar 2002 13:45:16 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15512 for ; Wed, 27 Mar 2002 13:45:15 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIjGkY023995 for ; Wed, 27 Mar 2002 19:45:16 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:45:15 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:45:15 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , George Tsirtsis , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 19:45:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > I agree with your comment about passing preferences to the > AR. It won't > scale. > > Actually, I would prefer to avoid any mention of AR based > discovery in > the requirements. To me, this is an implementation issue. I > would like > the requirements to clearly state that the MN is in charge. > If it turns > out that a network based implemention makes some sense, > then it can be > considered during the protocol design. > > This was the message I took away from Steve's talk. => Yep! And I thought there was an overwhelming concensus for that in the meeting. Hesham > > jak > > ----- Original Message ----- > From: "George Tsirtsis" > To: "'Hesham Soliman (ERA)'" ; > > Sent: Wednesday, March 27, 2002 9:01 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > For what is worth I am in full agreement with what Hesham > is saying > below > > about the scope of this. > > > > George > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, March 27, 2002 4:53 PM > > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > .... > > => I'll let you come up with the new text, but > > my curent concerns on the requirement is: > > > > - The scope of AR-based CAR should be limited > > to one operator's domain and one access technology. > > > > - The MN-based one is naturally limited by the number > > of ARs it can hear. > > > > FWIW, I don't think that passing preferences to > > the AR is a good idea or will ever scale. > > > > Hesham > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:47:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15654 for ; Wed, 27 Mar 2002 13:47:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00188 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:47:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00063; Wed, 27 Mar 2002 13:45:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00032 for ; Wed, 27 Mar 2002 13:45:16 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15512 for ; Wed, 27 Mar 2002 13:45:15 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIjGkY023995 for ; Wed, 27 Mar 2002 19:45:16 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:45:15 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:45:15 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA9@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , George Tsirtsis , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 19:45:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > I agree with your comment about passing preferences to the > AR. It won't > scale. > > Actually, I would prefer to avoid any mention of AR based > discovery in > the requirements. To me, this is an implementation issue. I > would like > the requirements to clearly state that the MN is in charge. > If it turns > out that a network based implemention makes some sense, > then it can be > considered during the protocol design. > > This was the message I took away from Steve's talk. => Yep! And I thought there was an overwhelming concensus for that in the meeting. Hesham > > jak > > ----- Original Message ----- > From: "George Tsirtsis" > To: "'Hesham Soliman (ERA)'" ; > > Sent: Wednesday, March 27, 2002 9:01 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > For what is worth I am in full agreement with what Hesham > is saying > below > > about the scope of this. > > > > George > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, March 27, 2002 4:53 PM > > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > .... > > => I'll let you come up with the new text, but > > my curent concerns on the requirement is: > > > > - The scope of AR-based CAR should be limited > > to one operator's domain and one access technology. > > > > - The MN-based one is naturally limited by the number > > of ARs it can hear. > > > > FWIW, I don't think that passing preferences to > > the AR is a good idea or will ever scale. > > > > Hesham > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 13:49:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15802 for ; Wed, 27 Mar 2002 13:49:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29995; Wed, 27 Mar 2002 13:44:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29966 for ; Wed, 27 Mar 2002 13:44:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15425 for ; Wed, 27 Mar 2002 13:44:03 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIhWI09563; Wed, 27 Mar 2002 10:43:32 -0800 (PST) Message-ID: <023401c1d5bf$11dc61d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hesham Soliman \(ERA\)'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC5C@ftmail> Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 10:41:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hesham, I agree with your comment about passing preferences to the AR. It won't scale. Actually, I would prefer to avoid any mention of AR based discovery in the requirements. To me, this is an implementation issue. I would like the requirements to clearly state that the MN is in charge. If it turns out that a network based implemention makes some sense, then it can be considered during the protocol design. This was the message I took away from Steve's talk. jak ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; Sent: Wednesday, March 27, 2002 9:01 AM Subject: RE: [Seamoby] Examples of CAR discovery > For what is worth I am in full agreement with what Hesham is saying below > about the scope of this. > > George > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:53 PM > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > Subject: RE: [Seamoby] Examples of CAR discovery > > .... > => I'll let you come up with the new text, but > my curent concerns on the requirement is: > > - The scope of AR-based CAR should be limited > to one operator's domain and one access technology. > > - The MN-based one is naturally limited by the number > of ARs it can hear. > > FWIW, I don't think that passing preferences to > the AR is a good idea or will ever scale. > > Hesham > > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:49:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15811 for ; Wed, 27 Mar 2002 13:49:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00302 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:49:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29995; Wed, 27 Mar 2002 13:44:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29966 for ; Wed, 27 Mar 2002 13:44:04 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15425 for ; Wed, 27 Mar 2002 13:44:03 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RIhWI09563; Wed, 27 Mar 2002 10:43:32 -0800 (PST) Message-ID: <023401c1d5bf$11dc61d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "'Hesham Soliman \(ERA\)'" , References: <8C92E23A3E87FB479988285F9E22BE465ABC5C@ftmail> Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 10:41:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hesham, I agree with your comment about passing preferences to the AR. It won't scale. Actually, I would prefer to avoid any mention of AR based discovery in the requirements. To me, this is an implementation issue. I would like the requirements to clearly state that the MN is in charge. If it turns out that a network based implemention makes some sense, then it can be considered during the protocol design. This was the message I took away from Steve's talk. jak ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; Sent: Wednesday, March 27, 2002 9:01 AM Subject: RE: [Seamoby] Examples of CAR discovery > For what is worth I am in full agreement with what Hesham is saying below > about the scope of this. > > George > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:53 PM > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > Subject: RE: [Seamoby] Examples of CAR discovery > > .... > => I'll let you come up with the new text, but > my curent concerns on the requirement is: > > - The scope of AR-based CAR should be limited > to one operator's domain and one access technology. > > - The MN-based one is naturally limited by the number > of ARs it can hear. > > FWIW, I don't think that passing preferences to > the AR is a good idea or will ever scale. > > Hesham > > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:58:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12065 for ; Wed, 27 Mar 2002 13:01:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24007 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:01:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23075; Wed, 27 Mar 2002 12:55:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23031 for ; Wed, 27 Mar 2002 12:54:57 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11394 for ; Wed, 27 Mar 2002 12:54:56 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RHsvoq009322 for ; Wed, 27 Mar 2002 18:54:57 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 18:54:44 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 18:44:37 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB9E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'George Tsirtsis'" , "Hesham Soliman (ERA)" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 18:54:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > => Well, the only difference is that the AR coverage > area includes several APs, so it's very unlikely > that you would end up with 6 GAARs in the same > technology. > > GT> I see, I guess because of soft handoff in cdma. But then, in > environments that can actually utilize an AR per BS/AP it > is possible to > have multiple GAARs even if you restrict this to a single > technology. So the > concern that some people have about GAAR+capabilities list > is not totally > unfounded, wouldn't you say?. > => Right, but if we restrict it to a single technology within one operator's network, then it should be fairly simple for the AR to send only one or two GAAR info. I still think that in this scenario it would be difficult to get 6 different GAARs that the MN can choose from, given that the MN is moving a certain direction. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 13:58:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12888 for ; Wed, 27 Mar 2002 13:10:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24888 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 13:10:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24486; Wed, 27 Mar 2002 13:04:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24456 for ; Wed, 27 Mar 2002 13:04:51 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12316 for ; Wed, 27 Mar 2002 13:04:50 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RI59s29369 for ; Wed, 27 Mar 2002 12:05:09 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 12:04:49 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 12:04:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 13:04:26 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVuDrxH7P+dKlIR1aOdYZOWL9q5QAADm1g To: , , X-OriginalArrivalTime: 27 Mar 2002 18:04:27.0835 (UTC) FILETIME=[D5F4F0B0:01C1D5B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA24457 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, And I pointed out the flaw in Hemant's argument: premature optimization. The requirements are supposed to say what the protocol will do, not specify it in detail. We need a strong statement that it is MN centered. Later, there may be need for optimization, but if we put the optimization in up front, we constrain the solution too much or open it up to nonviable solutions. [DOT] Assume we had a requirement saying that GAAR+capa must be sent to MN. This is a strong requirement (MUST) without knowing what's the amount of said data. Personally believing that it is not that much is not enough to justify this. Maybe, you have more clearer idea of the data we're talking about. Then please share it with the WG. [DOT] All I'm saying is that there must a possibility for the MN to say which information it wants to receive to avoid a mandatory transmission of data that might be unnecessary in large parts. If we had this addition, it would be still be MN-centered (it is the MN that says what to receive). And it does not restrict, since if the MN decides to receive everything, it can still say so. So it contains actually the original requirement (ALL information) plus it mandates possibilities for the MN to restrict the information it wants to receive. So I don't see why this constrains the solution? And I wouldn't call it opening up to nonviable solution, when I raise the concern that there should be the possibility for the MN to restrict information delivery, in particular in a stage where we actually don't know how the data looks like. I also have a hard time buying that there will be sooo much GAAR information. We are not talking about a complete list of the NASDAQ here, just whatever routers happen to be in the vicinity. [DOT] I can buy nothing from guessing, James. As long as we didn't really study what are the capabilities, what is the format, what are the scenarios, I'd like to see transmission of said data to the MN being able to limit BY THE MN. That's what I'm asking for. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:00:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16406 for ; Wed, 27 Mar 2002 14:00:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00581; Wed, 27 Mar 2002 13:54:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00552 for ; Wed, 27 Mar 2002 13:54:30 -0500 (EST) Received: from hotmail.com (f140.law9.hotmail.com [64.4.9.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15972 for ; Wed, 27 Mar 2002 13:54:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:54:00 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:54:00 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Date: Wed, 27 Mar 2002 13:54:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:54:00.0571 (UTC) FILETIME=[C1D874B0:01C1D5C0] Subject: [Seamoby] MN in charge: What does this mean? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Maybe we should clarify first what it means to say that the MN is in charge. Making some computations in the network rather than the MN while fully taking care of the MN's requirements does not mean that the MN is not in charge is it? This is essentially done for various constraints, which we have listed out ad nauseam.. so let me not repeat that again. Thanks, Govind _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:00:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16417 for ; Wed, 27 Mar 2002 14:00:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01210 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:00:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00581; Wed, 27 Mar 2002 13:54:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00552 for ; Wed, 27 Mar 2002 13:54:30 -0500 (EST) Received: from hotmail.com (f140.law9.hotmail.com [64.4.9.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15972 for ; Wed, 27 Mar 2002 13:54:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 10:54:00 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 18:54:00 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Date: Wed, 27 Mar 2002 13:54:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 18:54:00.0571 (UTC) FILETIME=[C1D874B0:01C1D5C0] Subject: [Seamoby] MN in charge: What does this mean? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Maybe we should clarify first what it means to say that the MN is in charge. Making some computations in the network rather than the MN while fully taking care of the MN's requirements does not mean that the MN is not in charge is it? This is essentially done for various constraints, which we have listed out ad nauseam.. so let me not repeat that again. Thanks, Govind _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:01:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16475 for ; Wed, 27 Mar 2002 14:01:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00413; Wed, 27 Mar 2002 13:51:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00385 for ; Wed, 27 Mar 2002 13:51:23 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15885 for ; Wed, 27 Mar 2002 13:51:21 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIpMoq027315 for ; Wed, 27 Mar 2002 19:51:22 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:51:22 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:51:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABAA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:51:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org I was saying that the MN can do the CAR > >in the intertechnology case because it > >is extremely trivial. If routers advertise > >their capabilities and the MN has the interface > >it doesn't need some other AR to tell it > >that there is a GGSN nearby does it? > > [Govind] Ofcourse, this assumes that the MN may have to connect > to each and every AP in the neighborhood and solicit. > This is fine with me. => Just to extra clarify, in the intertechnology case there is a separate interface per technology. So this is done in parallel. > > > >What I think should be limited is my GGSN/PDSN/AR > >looking for the AR in Starbucks. I really think > >it's unreasonable since the MN will know it > >anyway. > > [Govind] I totally agree that an extensive search process like what > you propose may include extensive searches over multiple > domains, which is quite infeasible. > But there may be other ways in which the MN and AR can > cooperate and help in such situations too, is it not? => i'm sure there are ways, but why? If there is a GAAR the MN will hear it, if it can't then it's not relevant for the search. Isn't this nice and simple? But I'm sure there can be more ways of doing it, I just want the simplest one. > > All I want the requirement to allow is for people to explore such > cooperation if possible in solutions. I just want > requirements should be too restrictive. Is that acceptible to you? => On a very high level, this statement is fine. Right now the requirements are restrictive, but I think we agreed on that and you said you'll update it. > Ofcourse you may always have the choice to reject it if some > one comes up with solutions that make too many impractical > assumptions. => That's my concern, so if we think it's impractical now, I'm not sure if it's woth allowing it. > But why should we say no now before we know what solutions > are possible. > Just my opinion thats all. => It might help if you give us some hints towards a simple solution for this. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:01:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16485 for ; Wed, 27 Mar 2002 14:01:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01648 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:01:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00413; Wed, 27 Mar 2002 13:51:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00385 for ; Wed, 27 Mar 2002 13:51:23 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15885 for ; Wed, 27 Mar 2002 13:51:21 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIpMoq027315 for ; Wed, 27 Mar 2002 19:51:22 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:51:22 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:51:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABAA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 19:51:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org I was saying that the MN can do the CAR > >in the intertechnology case because it > >is extremely trivial. If routers advertise > >their capabilities and the MN has the interface > >it doesn't need some other AR to tell it > >that there is a GGSN nearby does it? > > [Govind] Ofcourse, this assumes that the MN may have to connect > to each and every AP in the neighborhood and solicit. > This is fine with me. => Just to extra clarify, in the intertechnology case there is a separate interface per technology. So this is done in parallel. > > > >What I think should be limited is my GGSN/PDSN/AR > >looking for the AR in Starbucks. I really think > >it's unreasonable since the MN will know it > >anyway. > > [Govind] I totally agree that an extensive search process like what > you propose may include extensive searches over multiple > domains, which is quite infeasible. > But there may be other ways in which the MN and AR can > cooperate and help in such situations too, is it not? => i'm sure there are ways, but why? If there is a GAAR the MN will hear it, if it can't then it's not relevant for the search. Isn't this nice and simple? But I'm sure there can be more ways of doing it, I just want the simplest one. > > All I want the requirement to allow is for people to explore such > cooperation if possible in solutions. I just want > requirements should be too restrictive. Is that acceptible to you? => On a very high level, this statement is fine. Right now the requirements are restrictive, but I think we agreed on that and you said you'll update it. > Ofcourse you may always have the choice to reject it if some > one comes up with solutions that make too many impractical > assumptions. => That's my concern, so if we think it's impractical now, I'm not sure if it's woth allowing it. > But why should we say no now before we know what solutions > are possible. > Just my opinion thats all. => It might help if you give us some hints towards a simple solution for this. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:04:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16569 for ; Wed, 27 Mar 2002 14:04:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00908; Wed, 27 Mar 2002 13:58:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00838 for ; Wed, 27 Mar 2002 13:58:35 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16285 for ; Wed, 27 Mar 2002 13:58:34 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA06127 for ; Wed, 27 Mar 2002 11:58:35 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA09594 for ; Wed, 27 Mar 2002 11:46:28 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 27 Mar 2002 12:58:34 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , George Tsirtsis , "'Hesham Soliman \\(ERA\\)'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:58:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello James, I have not been actively involved in CAR discussion, but I am not sure how MN controlled CAR will really work when L2 handover is controlled by network. I do agree that in case of inter-technology or Mobile controlled handover, MN is the right candidate to select AR. But mostly in cellular where network controlled handover is used, I don't see how MN can select CAR. Won't there be inconsistency in L2 and L3 decision? Probably I might have missed some important discussion. regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 27, 2002 12:42 PM To: George Tsirtsis; 'Hesham Soliman \(ERA\)'; seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hesham, I agree with your comment about passing preferences to the AR. It won't scale. Actually, I would prefer to avoid any mention of AR based discovery in the requirements. To me, this is an implementation issue. I would like the requirements to clearly state that the MN is in charge. If it turns out that a network based implemention makes some sense, then it can be considered during the protocol design. This was the message I took away from Steve's talk. jak ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; Sent: Wednesday, March 27, 2002 9:01 AM Subject: RE: [Seamoby] Examples of CAR discovery > For what is worth I am in full agreement with what Hesham is saying below > about the scope of this. > > George > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:53 PM > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > Subject: RE: [Seamoby] Examples of CAR discovery > > .... > => I'll let you come up with the new text, but > my curent concerns on the requirement is: > > - The scope of AR-based CAR should be limited > to one operator's domain and one access technology. > > - The MN-based one is naturally limited by the number > of ARs it can hear. > > FWIW, I don't think that passing preferences to > the AR is a good idea or will ever scale. > > Hesham > > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:04:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16585 for ; Wed, 27 Mar 2002 14:04:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01970 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:04:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00908; Wed, 27 Mar 2002 13:58:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00838 for ; Wed, 27 Mar 2002 13:58:35 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16285 for ; Wed, 27 Mar 2002 13:58:34 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA06127 for ; Wed, 27 Mar 2002 11:58:35 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA09594 for ; Wed, 27 Mar 2002 11:46:28 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 27 Mar 2002 12:58:34 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , George Tsirtsis , "'Hesham Soliman \\(ERA\\)'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:58:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello James, I have not been actively involved in CAR discussion, but I am not sure how MN controlled CAR will really work when L2 handover is controlled by network. I do agree that in case of inter-technology or Mobile controlled handover, MN is the right candidate to select AR. But mostly in cellular where network controlled handover is used, I don't see how MN can select CAR. Won't there be inconsistency in L2 and L3 decision? Probably I might have missed some important discussion. regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 27, 2002 12:42 PM To: George Tsirtsis; 'Hesham Soliman \(ERA\)'; seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hesham, I agree with your comment about passing preferences to the AR. It won't scale. Actually, I would prefer to avoid any mention of AR based discovery in the requirements. To me, this is an implementation issue. I would like the requirements to clearly state that the MN is in charge. If it turns out that a network based implemention makes some sense, then it can be considered during the protocol design. This was the message I took away from Steve's talk. jak ----- Original Message ----- From: "George Tsirtsis" To: "'Hesham Soliman (ERA)'" ; Sent: Wednesday, March 27, 2002 9:01 AM Subject: RE: [Seamoby] Examples of CAR discovery > For what is worth I am in full agreement with what Hesham is saying below > about the scope of this. > > George > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 4:53 PM > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > Subject: RE: [Seamoby] Examples of CAR discovery > > .... > => I'll let you come up with the new text, but > my curent concerns on the requirement is: > > - The scope of AR-based CAR should be limited > to one operator's domain and one access technology. > > - The MN-based one is naturally limited by the number > of ARs it can hear. > > FWIW, I don't think that passing preferences to > the AR is a good idea or will ever scale. > > Hesham > > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:05:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16618 for ; Wed, 27 Mar 2002 14:05:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01839; Wed, 27 Mar 2002 14:02:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01811 for ; Wed, 27 Mar 2002 14:02:39 -0500 (EST) Received: from hotmail.com (f58.law9.hotmail.com [64.4.9.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16516 for ; Wed, 27 Mar 2002 14:02:38 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:02:09 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:02:09 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 14:02:09 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:02:09.0504 (UTC) FILETIME=[E545B600:01C1D5C1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > [Govind] Ofcourse, this assumes that the MN may have to connect > > to each and every AP in the neighborhood and solicit. > > This is fine with me. > >=> Just to extra clarify, in the intertechnology >case there is a separate interface per technology. >So this is done in parallel. [Govind] But within each interface you have to do this anyways if you have multiple APs for each interface. > > > > > > >What I think should be limited is my GGSN/PDSN/AR > > >looking for the AR in Starbucks. I really think > > >it's unreasonable since the MN will know it > > >anyway. > > > > [Govind] I totally agree that an extensive search process like what > > you propose may include extensive searches over multiple > > domains, which is quite infeasible. > > But there may be other ways in which the MN and AR can > > cooperate and help in such situations too, is it not? > >=> i'm sure there are ways, but why? If there is >a GAAR the MN will hear it, if it can't then it's >not relevant for the search. Isn't this nice and >simple? >But I'm sure there can be more ways of doing it, >I just want the simplest one. [Govind] Yes whether something is simple or not comes from looking at the solution right? > > > > > > All I want the requirement to allow is for people to explore such > > cooperation if possible in solutions. I just want > > requirements should be too restrictive. Is that acceptible to you? > >=> On a very high level, this statement is fine. >Right now the requirements are restrictive, but >I think we agreed on that and you said you'll >update it. [Govind] Thanks. > > > Ofcourse you may always have the choice to reject it if some > > one comes up with solutions that make too many impractical > > assumptions. > >=> That's my concern, so if we think it's impractical >now, I'm not sure if it's woth allowing it. [Govind] We don't know whether it is impractical unless people start going into their proposed solutions in detail. Are we willing to go into that direction right now? _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:05:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16634 for ; Wed, 27 Mar 2002 14:05:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02003 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:05:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01839; Wed, 27 Mar 2002 14:02:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01811 for ; Wed, 27 Mar 2002 14:02:39 -0500 (EST) Received: from hotmail.com (f58.law9.hotmail.com [64.4.9.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16516 for ; Wed, 27 Mar 2002 14:02:38 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:02:09 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:02:09 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 14:02:09 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:02:09.0504 (UTC) FILETIME=[E545B600:01C1D5C1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > [Govind] Ofcourse, this assumes that the MN may have to connect > > to each and every AP in the neighborhood and solicit. > > This is fine with me. > >=> Just to extra clarify, in the intertechnology >case there is a separate interface per technology. >So this is done in parallel. [Govind] But within each interface you have to do this anyways if you have multiple APs for each interface. > > > > > > >What I think should be limited is my GGSN/PDSN/AR > > >looking for the AR in Starbucks. I really think > > >it's unreasonable since the MN will know it > > >anyway. > > > > [Govind] I totally agree that an extensive search process like what > > you propose may include extensive searches over multiple > > domains, which is quite infeasible. > > But there may be other ways in which the MN and AR can > > cooperate and help in such situations too, is it not? > >=> i'm sure there are ways, but why? If there is >a GAAR the MN will hear it, if it can't then it's >not relevant for the search. Isn't this nice and >simple? >But I'm sure there can be more ways of doing it, >I just want the simplest one. [Govind] Yes whether something is simple or not comes from looking at the solution right? > > > > > > All I want the requirement to allow is for people to explore such > > cooperation if possible in solutions. I just want > > requirements should be too restrictive. Is that acceptible to you? > >=> On a very high level, this statement is fine. >Right now the requirements are restrictive, but >I think we agreed on that and you said you'll >update it. [Govind] Thanks. > > > Ofcourse you may always have the choice to reject it if some > > one comes up with solutions that make too many impractical > > assumptions. > >=> That's my concern, so if we think it's impractical >now, I'm not sure if it's woth allowing it. [Govind] We don't know whether it is impractical unless people start going into their proposed solutions in detail. Are we willing to go into that direction right now? _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:05:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16668 for ; Wed, 27 Mar 2002 14:05:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01173; Wed, 27 Mar 2002 14:00:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01130 for ; Wed, 27 Mar 2002 14:00:13 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16395 for ; Wed, 27 Mar 2002 14:00:12 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RJ0Doq001207 for ; Wed, 27 Mar 2002 20:00:13 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 20:00:12 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 20:00:12 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABAC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 20:00:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > Maybe we should clarify first what it means to say that the > MN is in charge. > Making some computations in the network rather than the MN while > fully taking care of the MN's requirements does not mean > that the MN is > not in charge is it? => People are questioning this assumption that the MN will pass some magic profile which will allow the AR to know so much about the MN, without breaking privacy, AND still scale.... just give us some examples pleaaase. This is essentially done for various > constraints, > which we have listed out ad nauseam.. so let me not repeat > that again. > => Sorry but your earlier constraints are not agreeable to all of us. In umts today, there are concersn about how often an RA should be sent, so people will just deal with that. If you carry the information in an RA, then you\re reusing an already existing mechanism with its pros and cons. Nothing new added here. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:05:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16678 for ; Wed, 27 Mar 2002 14:05:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02024 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:05:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01173; Wed, 27 Mar 2002 14:00:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01130 for ; Wed, 27 Mar 2002 14:00:13 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16395 for ; Wed, 27 Mar 2002 14:00:12 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RJ0Doq001207 for ; Wed, 27 Mar 2002 20:00:13 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 20:00:12 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 20:00:12 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABAC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 20:00:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > Maybe we should clarify first what it means to say that the > MN is in charge. > Making some computations in the network rather than the MN while > fully taking care of the MN's requirements does not mean > that the MN is > not in charge is it? => People are questioning this assumption that the MN will pass some magic profile which will allow the AR to know so much about the MN, without breaking privacy, AND still scale.... just give us some examples pleaaase. This is essentially done for various > constraints, > which we have listed out ad nauseam.. so let me not repeat > that again. > => Sorry but your earlier constraints are not agreeable to all of us. In umts today, there are concersn about how often an RA should be sent, so people will just deal with that. If you carry the information in an RA, then you\re reusing an already existing mechanism with its pros and cons. Nothing new added here. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:07:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16816 for ; Wed, 27 Mar 2002 14:07:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01690; Wed, 27 Mar 2002 14:01:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01661 for ; Wed, 27 Mar 2002 14:01:52 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16472 for ; Wed, 27 Mar 2002 14:01:47 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJ21s10619 for ; Wed, 27 Mar 2002 21:02:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 21:01:47 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 21:01:47 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:01:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 14:01:30 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHVvS7THTZrpSZLQe+fHvxhZ/hrLAAA4m6A To: , X-OriginalArrivalTime: 27 Mar 2002 19:01:32.0419 (UTC) FILETIME=[CF2AFD30:01C1D5C1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA01663 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, Govind wrote: > [Govind] There is a bias and I agree that the bias should be removed. > > But > what you are suggesting is to swing the pendulum to the opposite end > putting an MN bias. We should work toward an un-biased set of requirements, > IMHO, and thats what I will endeavor to do based on the discussions in the > mailing list. Yes, yes! That is what we are suggesting! That there *needs* to be a bias towards the MN, that whatever we design which does not give this to the MN will not provide the User with what he wants and needs, and ultimately won't be deployed and used. [DOT] Does this necessarily mean that the MN has to do the job entirely? Giving the control of the handover decision to the MN and providing information to do so through assistance of the network, is a different thing. I thought Steve was so clear in Minneapolis, and the case so clear as well, that I did not expect this resistance. [DOT] This is open to interpretation since everybody got his/her own impression. I did also take away from this presentation that it indeed makes sense to use information and functionality from the network to do the CAR discovery. I did not understand Steve's talk in a way that EVERYTHING has to be MN-based. [DOT] Another point is that we should not take Steve's talk and its interpretation by WG members as the final mandate for the definition of requirements. His presentation certainly stimulated the discussion, and that is good since we made progress in addressing certain things. But just pointing to interpretations of this talk to justify requirements and their sense is not enough for me. We still have to have a discussion and a WG consensus about this work. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:07:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16827 for ; Wed, 27 Mar 2002 14:07:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02210 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:07:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01690; Wed, 27 Mar 2002 14:01:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01661 for ; Wed, 27 Mar 2002 14:01:52 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16472 for ; Wed, 27 Mar 2002 14:01:47 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJ21s10619 for ; Wed, 27 Mar 2002 21:02:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 21:01:47 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 21:01:47 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:01:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 14:01:30 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHVvS7THTZrpSZLQe+fHvxhZ/hrLAAA4m6A To: , X-OriginalArrivalTime: 27 Mar 2002 19:01:32.0419 (UTC) FILETIME=[CF2AFD30:01C1D5C1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA01663 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, Govind wrote: > [Govind] There is a bias and I agree that the bias should be removed. > > But > what you are suggesting is to swing the pendulum to the opposite end > putting an MN bias. We should work toward an un-biased set of requirements, > IMHO, and thats what I will endeavor to do based on the discussions in the > mailing list. Yes, yes! That is what we are suggesting! That there *needs* to be a bias towards the MN, that whatever we design which does not give this to the MN will not provide the User with what he wants and needs, and ultimately won't be deployed and used. [DOT] Does this necessarily mean that the MN has to do the job entirely? Giving the control of the handover decision to the MN and providing information to do so through assistance of the network, is a different thing. I thought Steve was so clear in Minneapolis, and the case so clear as well, that I did not expect this resistance. [DOT] This is open to interpretation since everybody got his/her own impression. I did also take away from this presentation that it indeed makes sense to use information and functionality from the network to do the CAR discovery. I did not understand Steve's talk in a way that EVERYTHING has to be MN-based. [DOT] Another point is that we should not take Steve's talk and its interpretation by WG members as the final mandate for the definition of requirements. His presentation certainly stimulated the discussion, and that is good since we made progress in addressing certain things. But just pointing to interpretations of this talk to justify requirements and their sense is not enough for me. We still have to have a discussion and a WG consensus about this work. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:12:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17127 for ; Wed, 27 Mar 2002 14:12:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02098; Wed, 27 Mar 2002 14:06:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02071 for ; Wed, 27 Mar 2002 14:06:38 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16762 for ; Wed, 27 Mar 2002 14:06:37 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJ93105644 for ; Wed, 27 Mar 2002 13:09:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:06:37 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:05:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 14:05:58 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Thread-Index: AcHVvliSMG5sGl7MR5mZCtvzMaIYsQAA6lvQ To: , , , , X-OriginalArrivalTime: 27 Mar 2002 19:05:59.0486 (UTC) FILETIME=[6E5A2DE0:01C1D5C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA02072 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, Right, this is what we have been arguing about with Dirk, Hemant, and Govind. The MN should get the GAARs and decide. The requirement I posted does not say that the AR sends those to the MN, it says that the protocol should provide them to the MN. Exactly how is the task of the protocol design. Dirk, Hemant, and Govind have been making the assumption that they have to come from one specific AR, this might not be the case, but, it depends on the design. [DOT] Even if it comes from different ARs, the information might be unwanted. The interpretation that I assumed that one AR will send this information, kind of confuses me. However, I am sympathetic to the efficiency argument and have no objection to a network efficiency requirement. I posted one in a response to Hemant's message. [DOT] As I said in a previous email, what is the efficiency requirement worth if another requirement demands for sending all this information?? It is maybe useful for choosing a representation format for the transferred information that is as efficient as possible. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:12:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17145 for ; Wed, 27 Mar 2002 14:12:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02536 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:12:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02098; Wed, 27 Mar 2002 14:06:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02071 for ; Wed, 27 Mar 2002 14:06:38 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16762 for ; Wed, 27 Mar 2002 14:06:37 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJ93105644 for ; Wed, 27 Mar 2002 13:09:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:06:37 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:05:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 14:05:58 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Thread-Index: AcHVvliSMG5sGl7MR5mZCtvzMaIYsQAA6lvQ To: , , , , X-OriginalArrivalTime: 27 Mar 2002 19:05:59.0486 (UTC) FILETIME=[6E5A2DE0:01C1D5C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA02072 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, Right, this is what we have been arguing about with Dirk, Hemant, and Govind. The MN should get the GAARs and decide. The requirement I posted does not say that the AR sends those to the MN, it says that the protocol should provide them to the MN. Exactly how is the task of the protocol design. Dirk, Hemant, and Govind have been making the assumption that they have to come from one specific AR, this might not be the case, but, it depends on the design. [DOT] Even if it comes from different ARs, the information might be unwanted. The interpretation that I assumed that one AR will send this information, kind of confuses me. However, I am sympathetic to the efficiency argument and have no objection to a network efficiency requirement. I posted one in a response to Hemant's message. [DOT] As I said in a previous email, what is the efficiency requirement worth if another requirement demands for sending all this information?? It is maybe useful for choosing a representation format for the transferred information that is as efficient as possible. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:12:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17180 for ; Wed, 27 Mar 2002 14:12:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02349; Wed, 27 Mar 2002 14:10:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02318 for ; Wed, 27 Mar 2002 14:10:11 -0500 (EST) Received: from hotmail.com (f153.law9.hotmail.com [64.4.9.153]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16967 for ; Wed, 27 Mar 2002 14:10:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:09:41 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:09:40 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 14:09:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:09:41.0089 (UTC) FILETIME=[F2701D10:01C1D5C2] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > > Maybe we should clarify first what it means to say that the > > MN is in charge. > > Making some computations in the network rather than the MN while > > fully taking care of the MN's requirements does not mean > > that the MN is > > not in charge is it? > >=> People are questioning this assumption that >the MN will pass some magic profile which >will allow the AR to know so much about the >MN, without breaking privacy, AND still >scale.... just give us some examples pleaaase. [Govind] You feel that the requirements cannot be made available to the AR, which I don't necessarily agree. But apart from that what do you think about the intial question about what does it mean that the MN is in charge? > This is essentially done for various > > constraints, > > which we have listed out ad nauseam.. so let me not repeat > > that again. > > > >=> Sorry but your earlier constraints are not >agreeable to all of us. In umts today, there are >concersn about how often an RA should be sent, so >people will just deal with that. If you carry the >information in an RA, then you\re reusing an already >existing mechanism with its pros and cons. Nothing >new added here. [Govind] Well it is agreeable to some of us.. thats a start :) First regarding putting capabilities on the RAdv, whether this is feasible or not depends on the nature of capabilities and what they are. The Issues draft lists out several possibilities for capabilities. Is it possible for you take a look at that? So dependent on granularity that you want to support on each of these capabilities you may have to send it more frequently than a RAdv. Also to receive a RtrAdv you have to be connected to the AP connected to that AR. But if you have several APs connected to different ARs then how are you going to monitor all of them? _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:12:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17190 for ; Wed, 27 Mar 2002 14:12:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02574 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:12:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02349; Wed, 27 Mar 2002 14:10:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02318 for ; Wed, 27 Mar 2002 14:10:11 -0500 (EST) Received: from hotmail.com (f153.law9.hotmail.com [64.4.9.153]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16967 for ; Wed, 27 Mar 2002 14:10:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:09:41 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:09:40 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: hesham.soliman@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 14:09:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:09:41.0089 (UTC) FILETIME=[F2701D10:01C1D5C2] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hesham, > > > Maybe we should clarify first what it means to say that the > > MN is in charge. > > Making some computations in the network rather than the MN while > > fully taking care of the MN's requirements does not mean > > that the MN is > > not in charge is it? > >=> People are questioning this assumption that >the MN will pass some magic profile which >will allow the AR to know so much about the >MN, without breaking privacy, AND still >scale.... just give us some examples pleaaase. [Govind] You feel that the requirements cannot be made available to the AR, which I don't necessarily agree. But apart from that what do you think about the intial question about what does it mean that the MN is in charge? > This is essentially done for various > > constraints, > > which we have listed out ad nauseam.. so let me not repeat > > that again. > > > >=> Sorry but your earlier constraints are not >agreeable to all of us. In umts today, there are >concersn about how often an RA should be sent, so >people will just deal with that. If you carry the >information in an RA, then you\re reusing an already >existing mechanism with its pros and cons. Nothing >new added here. [Govind] Well it is agreeable to some of us.. thats a start :) First regarding putting capabilities on the RAdv, whether this is feasible or not depends on the nature of capabilities and what they are. The Issues draft lists out several possibilities for capabilities. Is it possible for you take a look at that? So dependent on granularity that you want to support on each of these capabilities you may have to send it more frequently than a RAdv. Also to receive a RtrAdv you have to be connected to the AP connected to that AR. But if you have several APs connected to different ARs then how are you going to monitor all of them? _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:13:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17225 for ; Wed, 27 Mar 2002 14:13:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02405; Wed, 27 Mar 2002 14:10:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02366 for ; Wed, 27 Mar 2002 14:10:52 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17033 for ; Wed, 27 Mar 2002 14:10:51 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJDG106235 for ; Wed, 27 Mar 2002 13:13:16 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:10:48 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:09:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:09:53 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVvpqbugfTsj7tSguh/H8EHwsXmwAA+R0A To: , X-OriginalArrivalTime: 27 Mar 2002 19:09:54.0708 (UTC) FILETIME=[FA8E3540:01C1D5C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA02367 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, > > > > If you are so sure of this interpretation, why don't we add it to > > requirement for clarity. Why should leave the requirement text to open > > interpretation. > > Because the requirement is perfectly clear as is. > > Henrik > > [DOT] By all due respect, but this is your opinion. There is certain concern > on this mailing list that the text is not clear and allows for interpretation, > which makes it a controversial requirement. We shouldn't have those in a requirement > document, since we're going to have the same discussion when assessing solutions. Certainly this is my opinion! And going back, I seem to see that there is ONE person who started out misapprehending this. That does not make it controversial, that makes it a misapprehension. [DOT] Now don't let us drift into this, ok. First, I saw Govind, George, and myself agreeing with Hemant's interpretation of this requirement. Second, the term "misapprehension" sounds to me like an assumption that you're right with your interpretation, which I don't want to comment further. The controversial point is exactly that there are different interpretations of a single requirement due to the chosen wording. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:13:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17236 for ; Wed, 27 Mar 2002 14:13:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02664 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:13:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02405; Wed, 27 Mar 2002 14:10:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02366 for ; Wed, 27 Mar 2002 14:10:52 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17033 for ; Wed, 27 Mar 2002 14:10:51 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJDG106235 for ; Wed, 27 Mar 2002 13:13:16 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:10:48 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:09:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:09:53 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVvpqbugfTsj7tSguh/H8EHwsXmwAA+R0A To: , X-OriginalArrivalTime: 27 Mar 2002 19:09:54.0708 (UTC) FILETIME=[FA8E3540:01C1D5C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA02367 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Henrik, > > > > If you are so sure of this interpretation, why don't we add it to > > requirement for clarity. Why should leave the requirement text to open > > interpretation. > > Because the requirement is perfectly clear as is. > > Henrik > > [DOT] By all due respect, but this is your opinion. There is certain concern > on this mailing list that the text is not clear and allows for interpretation, > which makes it a controversial requirement. We shouldn't have those in a requirement > document, since we're going to have the same discussion when assessing solutions. Certainly this is my opinion! And going back, I seem to see that there is ONE person who started out misapprehending this. That does not make it controversial, that makes it a misapprehension. [DOT] Now don't let us drift into this, ok. First, I saw Govind, George, and myself agreeing with Hemant's interpretation of this requirement. Second, the term "misapprehension" sounds to me like an assumption that you're right with your interpretation, which I don't want to comment further. The controversial point is exactly that there are different interpretations of a single requirement due to the chosen wording. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:21:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17511 for ; Wed, 27 Mar 2002 14:21:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02741; Wed, 27 Mar 2002 14:14:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02712 for ; Wed, 27 Mar 2002 14:14:44 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17265 for ; Wed, 27 Mar 2002 14:14:42 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RJEhkY004132 for ; Wed, 27 Mar 2002 20:14:43 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 20:14:42 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 20:14:42 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABB0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 20:14:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > [DOT] Now don't let us drift into this, ok. First, I saw > Govind, George, and myself > agreeing with Hemant's interpretation of this requirement. > Second, the term "misapprehension" > sounds to me like an assumption that you're right with your > interpretation, which I don't > want to comment further. The controversial point is exactly > that there are different > interpretations of a single requirement due to the chosen wording. > => No, it\s not the wording, it is a clear bias towards a certain model. Govind agreed that there is a bias, but you insist on keeping the discussion within the wording domain. This is not going to help. We need clear requirements and we need to distinguish between the entities invloved in the CAR discovery. We do not want requirements that can be interpreted in several ways. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:21:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17520 for ; Wed, 27 Mar 2002 14:21:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03011 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:21:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02741; Wed, 27 Mar 2002 14:14:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02712 for ; Wed, 27 Mar 2002 14:14:44 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17265 for ; Wed, 27 Mar 2002 14:14:42 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RJEhkY004132 for ; Wed, 27 Mar 2002 20:14:43 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 20:14:42 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 20:14:42 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABB0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Dirk.Trossen@nokia.com'" , henrik@levkowetz.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 20:14:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > [DOT] Now don't let us drift into this, ok. First, I saw > Govind, George, and myself > agreeing with Hemant's interpretation of this requirement. > Second, the term "misapprehension" > sounds to me like an assumption that you're right with your > interpretation, which I don't > want to comment further. The controversial point is exactly > that there are different > interpretations of a single requirement due to the chosen wording. > => No, it\s not the wording, it is a clear bias towards a certain model. Govind agreed that there is a bias, but you insist on keeping the discussion within the wording domain. This is not going to help. We need clear requirements and we need to distinguish between the entities invloved in the CAR discovery. We do not want requirements that can be interpreted in several ways. Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:22:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17553 for ; Wed, 27 Mar 2002 14:22:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02919; Wed, 27 Mar 2002 14:19:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02889 for ; Wed, 27 Mar 2002 14:19:10 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17400 for ; Wed, 27 Mar 2002 14:19:08 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJLY107364 for ; Wed, 27 Mar 2002 13:21:34 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:19:09 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:19:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:19:00 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVw60lVzvuvjJmRnij/W9oPqY0UAAABAhQ To: , , X-OriginalArrivalTime: 27 Mar 2002 19:19:01.0168 (UTC) FILETIME=[40456300:01C1D5C4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA02890 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, > [DOT] Now don't let us drift into this, ok. First, I saw > Govind, George, and myself > agreeing with Hemant's interpretation of this requirement. > Second, the term "misapprehension" > sounds to me like an assumption that you're right with your > interpretation, which I don't > want to comment further. The controversial point is exactly > that there are different > interpretations of a single requirement due to the chosen wording. > => No, it\s not the wording, it is a clear bias towards a certain model. Govind agreed that there is a bias, but you insist on keeping the discussion within the wording domain. This is not going to help. We need clear requirements and we need to distinguish between the entities invloved in the CAR discovery. We do not want requirements that can be interpreted in several ways. [DOT] Before you start offending people like this on the mailing list, start reading mails thoroughly before you answer. I did agree on the same bias and its removal from the requirements. And stating clear requirements that do not allow different interpretations is exactly what the text above was about. Since you agreed on this, too, we can start re-wording the requirement in a way that we can find consensus. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:22:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17562 for ; Wed, 27 Mar 2002 14:22:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03034 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:22:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02919; Wed, 27 Mar 2002 14:19:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02889 for ; Wed, 27 Mar 2002 14:19:10 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17400 for ; Wed, 27 Mar 2002 14:19:08 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJLY107364 for ; Wed, 27 Mar 2002 13:21:34 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:19:09 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:19:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:19:00 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVw60lVzvuvjJmRnij/W9oPqY0UAAABAhQ To: , , X-OriginalArrivalTime: 27 Mar 2002 19:19:01.0168 (UTC) FILETIME=[40456300:01C1D5C4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA02890 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, > [DOT] Now don't let us drift into this, ok. First, I saw > Govind, George, and myself > agreeing with Hemant's interpretation of this requirement. > Second, the term "misapprehension" > sounds to me like an assumption that you're right with your > interpretation, which I don't > want to comment further. The controversial point is exactly > that there are different > interpretations of a single requirement due to the chosen wording. > => No, it\s not the wording, it is a clear bias towards a certain model. Govind agreed that there is a bias, but you insist on keeping the discussion within the wording domain. This is not going to help. We need clear requirements and we need to distinguish between the entities invloved in the CAR discovery. We do not want requirements that can be interpreted in several ways. [DOT] Before you start offending people like this on the mailing list, start reading mails thoroughly before you answer. I did agree on the same bias and its removal from the requirements. And stating clear requirements that do not allow different interpretations is exactly what the text above was about. Since you agreed on this, too, we can start re-wording the requirement in a way that we can find consensus. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:26:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17789 for ; Wed, 27 Mar 2002 14:26:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03230; Wed, 27 Mar 2002 14:23:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03202 for ; Wed, 27 Mar 2002 14:23:46 -0500 (EST) Received: from hotmail.com (f128.law9.hotmail.com [64.4.9.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17648 for ; Wed, 27 Mar 2002 14:23:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:23:15 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:23:15 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:23:15 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:23:15.0893 (UTC) FILETIME=[D8195650:01C1D5C4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > > > [DOT] Now don't let us drift into this, ok. First, I saw > > Govind, George, and myself > > agreeing with Hemant's interpretation of this requirement. > > Second, the term "misapprehension" > > sounds to me like an assumption that you're right with your > > interpretation, which I don't > > want to comment further. The controversial point is exactly > > that there are different > > interpretations of a single requirement due to the chosen wording. > > > [Govind] Hesham, I think what I said earlier and what Dirk is referring to are different requirements I think. This one deals with what James posted about MNs being informed of all the detail. What I told you was 3.4 which appears that AR might be doing things and we should add something to reflect the CAR discovery done totally by the MN too. However, I do agree that James' requirement swings totally to the MN side precluding any other option and I don't want that either. >=> No, it\s not the wording, it is a clear >bias towards a certain model. Govind agreed that >there is a bias, but you insist on keeping >the discussion within the wording domain. >This is not going to help. We need clear requirements >and we need to distinguish between the entities >invloved in the CAR discovery. We do not want requirements >that can be interpreted in several ways. > >Hesham > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:26:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17799 for ; Wed, 27 Mar 2002 14:26:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03378 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:26:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03230; Wed, 27 Mar 2002 14:23:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03202 for ; Wed, 27 Mar 2002 14:23:46 -0500 (EST) Received: from hotmail.com (f128.law9.hotmail.com [64.4.9.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17648 for ; Wed, 27 Mar 2002 14:23:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:23:15 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:23:15 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:23:15 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:23:15.0893 (UTC) FILETIME=[D8195650:01C1D5C4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org > > > > > [DOT] Now don't let us drift into this, ok. First, I saw > > Govind, George, and myself > > agreeing with Hemant's interpretation of this requirement. > > Second, the term "misapprehension" > > sounds to me like an assumption that you're right with your > > interpretation, which I don't > > want to comment further. The controversial point is exactly > > that there are different > > interpretations of a single requirement due to the chosen wording. > > > [Govind] Hesham, I think what I said earlier and what Dirk is referring to are different requirements I think. This one deals with what James posted about MNs being informed of all the detail. What I told you was 3.4 which appears that AR might be doing things and we should add something to reflect the CAR discovery done totally by the MN too. However, I do agree that James' requirement swings totally to the MN side precluding any other option and I don't want that either. >=> No, it\s not the wording, it is a clear >bias towards a certain model. Govind agreed that >there is a bias, but you insist on keeping >the discussion within the wording domain. >This is not going to help. We need clear requirements >and we need to distinguish between the entities >invloved in the CAR discovery. We do not want requirements >that can be interpreted in several ways. > >Hesham > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:26:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17834 for ; Wed, 27 Mar 2002 14:26:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03144; Wed, 27 Mar 2002 14:23:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03113 for ; Wed, 27 Mar 2002 14:23:27 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17610 for ; Wed, 27 Mar 2002 14:23:25 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RJMlI11307; Wed, 27 Mar 2002 11:22:47 -0800 (PST) Message-ID: <029d01c1d5c4$8dd753d0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:21:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Drik, Yes, that was the essence of the rewording of the requirement I sent out, to remove the AR-bias. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 10:16 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi James, > > > Here's the requirement: > > The other fundamental function of CAR discovery protocols is that of > identifying the capabilities of GAARs. The protocol MUST provide > functionality to allow ARs to discover their GAAR's capabilities. > These > capabilities MUST be communicated in a secure fashion. > > [DOT] Sorry, I mixed up some numbers, you're right with this one. But this addresses > another problem, and Govind already sent this to list, namely to remove certain > AR-biased wordings. The above requirement is entirely possible without mentioning > the AR, and I assumed after Govind's comment that this will happen in the revised > version. But even if you did this, you still need means to express MN's requirements > in the sense I described. That was my point. > > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:26:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17844 for ; Wed, 27 Mar 2002 14:26:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03397 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:26:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03144; Wed, 27 Mar 2002 14:23:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03113 for ; Wed, 27 Mar 2002 14:23:27 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17610 for ; Wed, 27 Mar 2002 14:23:25 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RJMlI11307; Wed, 27 Mar 2002 11:22:47 -0800 (PST) Message-ID: <029d01c1d5c4$8dd753d0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 11:21:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Drik, Yes, that was the essence of the rewording of the requirement I sent out, to remove the AR-bias. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 10:16 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi James, > > > Here's the requirement: > > The other fundamental function of CAR discovery protocols is that of > identifying the capabilities of GAARs. The protocol MUST provide > functionality to allow ARs to discover their GAAR's capabilities. > These > capabilities MUST be communicated in a secure fashion. > > [DOT] Sorry, I mixed up some numbers, you're right with this one. But this addresses > another problem, and Govind already sent this to list, namely to remove certain > AR-biased wordings. The above requirement is entirely possible without mentioning > the AR, and I assumed after Govind's comment that this will happen in the revised > version. But even if you did this, you still need means to express MN's requirements > in the sense I described. That was my point. > > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:32:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18124 for ; Wed, 27 Mar 2002 14:32:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03440; Wed, 27 Mar 2002 14:26:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03413 for ; Wed, 27 Mar 2002 14:26:30 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17865 for ; Wed, 27 Mar 2002 14:26:28 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RJOiI11379; Wed, 27 Mar 2002 11:24:44 -0800 (PST) Message-ID: <02a701c1d5c4$d35e3f40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 11:23:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, We have to think about what the requirement is intending to accomplish. If we don't mention that, then the requirement becomes meaningless. The intent is to get the MN the information it needs to select the next AR. Thus, I believe we must mention the MN. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 10:03 AM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > James, > > >Here's the requirement: > > > > The other fundamental function of CAR discovery protocols is that of > > identifying the capabilities of GAARs. The protocol MUST provide > > functionality to allow ARs to discover their GAAR's capabilities. > >These > > capabilities MUST be communicated in a secure fashion. > > > >There is not one single mention of the MN in this requirement. > > > >How can you interpret that this requirement does NOT put the AR in > >control? This is exactly the message Steve Deering was trying to get > >across in the Minne-apple. > > [Govind] There is a bias and I agree that the bias should be removed. > > But > what you are suggesting is to swing the pendulum to the opposite end > putting an MN bias. We should work toward an un-biased set of requirements, > IMHO, and thats what I will endeavor to do based on the discussions in the > mailing list. > > Regards, > Govind. > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:32:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18134 for ; Wed, 27 Mar 2002 14:32:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04235 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:32:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03440; Wed, 27 Mar 2002 14:26:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03413 for ; Wed, 27 Mar 2002 14:26:30 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17865 for ; Wed, 27 Mar 2002 14:26:28 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RJOiI11379; Wed, 27 Mar 2002 11:24:44 -0800 (PST) Message-ID: <02a701c1d5c4$d35e3f40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 11:23:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, We have to think about what the requirement is intending to accomplish. If we don't mention that, then the requirement becomes meaningless. The intent is to get the MN the information it needs to select the next AR. Thus, I believe we must mention the MN. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 10:03 AM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > James, > > >Here's the requirement: > > > > The other fundamental function of CAR discovery protocols is that of > > identifying the capabilities of GAARs. The protocol MUST provide > > functionality to allow ARs to discover their GAAR's capabilities. > >These > > capabilities MUST be communicated in a secure fashion. > > > >There is not one single mention of the MN in this requirement. > > > >How can you interpret that this requirement does NOT put the AR in > >control? This is exactly the message Steve Deering was trying to get > >across in the Minne-apple. > > [Govind] There is a bias and I agree that the bias should be removed. > > But > what you are suggesting is to swing the pendulum to the opposite end > putting an MN bias. We should work toward an un-biased set of requirements, > IMHO, and thats what I will endeavor to do based on the discussions in the > mailing list. > > Regards, > Govind. > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:43:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18560 for ; Wed, 27 Mar 2002 14:43:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04406; Wed, 27 Mar 2002 14:37:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04377 for ; Wed, 27 Mar 2002 14:37:01 -0500 (EST) Received: from hotmail.com (f176.law9.hotmail.com [64.4.9.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18343 for ; Wed, 27 Mar 2002 14:37:00 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:36:31 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:36:31 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 14:36:31 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:36:31.0767 (UTC) FILETIME=[B27A1270:01C1D5C6] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I agree that an incompletely stated requirement is meaningless. But I just don't seem to understand why you claim that an AR based scheme which can take the MN's requirement totally into consideration cannot do the job which you illustrate? Note that I have never said what you propose is not feasible but the feasibility of what I propose is also true. Can't we have a happy medium? :) Thanks, -Govind. >Govind, > >We have to think about what the requirement is intending to accomplish. >If we don't mention that, then the requirement becomes meaningless. The >intent is to get the MN the information it needs to select the next AR. >Thus, I believe we must mention the MN. > > jak > >----- Original Message ----- >From: "Govind Krishnamurthi" >To: >Sent: Wednesday, March 27, 2002 10:03 AM >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of > > > > James, > > > > >Here's the requirement: > > > > > > The other fundamental function of CAR discovery protocols is >that of > > > identifying the capabilities of GAARs. The protocol MUST provide > > > functionality to allow ARs to discover their GAAR's >capabilities. > > >These > > > capabilities MUST be communicated in a secure fashion. > > > > > >There is not one single mention of the MN in this requirement. > > > > > >How can you interpret that this requirement does NOT put the AR in > > >control? This is exactly the message Steve Deering was trying to get > > >across in the Minne-apple. > > > > [Govind] There is a bias and I agree that the bias should be removed. > > > > But > > what you are suggesting is to swing the pendulum to the opposite end > > putting an MN bias. We should work toward an un-biased set of >requirements, > > IMHO, and thats what I will endeavor to do based on the discussions in >the > > mailing list. > > > > Regards, > > Govind. > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:43:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18569 for ; Wed, 27 Mar 2002 14:43:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04627 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:43:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04406; Wed, 27 Mar 2002 14:37:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04377 for ; Wed, 27 Mar 2002 14:37:01 -0500 (EST) Received: from hotmail.com (f176.law9.hotmail.com [64.4.9.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18343 for ; Wed, 27 Mar 2002 14:37:00 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 11:36:31 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 19:36:31 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 14:36:31 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 19:36:31.0767 (UTC) FILETIME=[B27A1270:01C1D5C6] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I agree that an incompletely stated requirement is meaningless. But I just don't seem to understand why you claim that an AR based scheme which can take the MN's requirement totally into consideration cannot do the job which you illustrate? Note that I have never said what you propose is not feasible but the feasibility of what I propose is also true. Can't we have a happy medium? :) Thanks, -Govind. >Govind, > >We have to think about what the requirement is intending to accomplish. >If we don't mention that, then the requirement becomes meaningless. The >intent is to get the MN the information it needs to select the next AR. >Thus, I believe we must mention the MN. > > jak > >----- Original Message ----- >From: "Govind Krishnamurthi" >To: >Sent: Wednesday, March 27, 2002 10:03 AM >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of > > > > James, > > > > >Here's the requirement: > > > > > > The other fundamental function of CAR discovery protocols is >that of > > > identifying the capabilities of GAARs. The protocol MUST provide > > > functionality to allow ARs to discover their GAAR's >capabilities. > > >These > > > capabilities MUST be communicated in a secure fashion. > > > > > >There is not one single mention of the MN in this requirement. > > > > > >How can you interpret that this requirement does NOT put the AR in > > >control? This is exactly the message Steve Deering was trying to get > > >across in the Minne-apple. > > > > [Govind] There is a bias and I agree that the bias should be removed. > > > > But > > what you are suggesting is to swing the pendulum to the opposite end > > putting an MN bias. We should work toward an un-biased set of >requirements, > > IMHO, and thats what I will endeavor to do based on the discussions in >the > > mailing list. > > > > Regards, > > Govind. > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:43:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18607 for ; Wed, 27 Mar 2002 14:43:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04556; Wed, 27 Mar 2002 14:40:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04531 for ; Wed, 27 Mar 2002 14:40:02 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18451 for ; Wed, 27 Mar 2002 14:40:00 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJgN109361 for ; Wed, 27 Mar 2002 13:42:23 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:39:57 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:39:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 14:39:34 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHVxVYWFAPNNN0fT/iefIz4ddXJPQAAUolw To: , , X-OriginalArrivalTime: 27 Mar 2002 19:39:35.0246 (UTC) FILETIME=[1FD6BEE0:01C1D5C7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA04532 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Govind, We have to think about what the requirement is intending to accomplish. If we don't mention that, then the requirement becomes meaningless. The intent is to get the MN the information it needs to select the next AR. Thus, I believe we must mention the MN. [DOT] But isn't that the disagreement, namely the amount of information the MN needs to select? Assuming that MN could, by any means, connect/handover to x ARs, does it really mean that the MN has to get the entire information of all these x ARs? What if only y ARs satify the MN's requirements? It still sufficient (and even MN-controlled) to choose out of these y since the other ones are worthless. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:43:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18615 for ; Wed, 27 Mar 2002 14:43:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04697 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:43:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04556; Wed, 27 Mar 2002 14:40:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04531 for ; Wed, 27 Mar 2002 14:40:02 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18451 for ; Wed, 27 Mar 2002 14:40:00 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJgN109361 for ; Wed, 27 Mar 2002 13:42:23 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:39:57 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:39:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 14:39:34 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHVxVYWFAPNNN0fT/iefIz4ddXJPQAAUolw To: , , X-OriginalArrivalTime: 27 Mar 2002 19:39:35.0246 (UTC) FILETIME=[1FD6BEE0:01C1D5C7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA04532 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Govind, We have to think about what the requirement is intending to accomplish. If we don't mention that, then the requirement becomes meaningless. The intent is to get the MN the information it needs to select the next AR. Thus, I believe we must mention the MN. [DOT] But isn't that the disagreement, namely the amount of information the MN needs to select? Assuming that MN could, by any means, connect/handover to x ARs, does it really mean that the MN has to get the entire information of all these x ARs? What if only y ARs satify the MN's requirements? It still sufficient (and even MN-controlled) to choose out of these y since the other ones are worthless. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 14:59:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19253 for ; Wed, 27 Mar 2002 14:59:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05051; Wed, 27 Mar 2002 14:52:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05022 for ; Wed, 27 Mar 2002 14:52:42 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18959 for ; Wed, 27 Mar 2002 14:52:40 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJqxs05948 for ; Wed, 27 Mar 2002 13:52:59 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:52:40 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:51:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:51:46 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVxwFK0sozt+0xR7GYRKq2zeOnfgAAEzXg To: , , , X-OriginalArrivalTime: 27 Mar 2002 19:51:47.0064 (UTC) FILETIME=[D4094F80:01C1D5C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA05023 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, Actually, I would prefer to avoid any mention of AR based discovery in the requirements. To me, this is an implementation issue. I would like the requirements to clearly state that the MN is in charge. If it turns out that a network based implemention makes some sense, then it can be considered during the protocol design. [DOT] If we could word the requirements in a way that it still allows network assistance, keeping in mind that the MN's requirements are the overall constraint of the design, this would be fine. But the way it has been proposed so far does not suffice to me. But at least I sense a common understanding that it should still be possible to involve the network in parts where it "makes sense", which could be related to avoiding unnecessary information transfer for instance. The point in the current discussion is, at least from my part, that we shouldn't replace AR-biased wordings by MN-biased ones. It is the theme that counts, namely that it is the MN that makes the final decision. Everything that does not allow this is not a good solution. But every requirement that does not allow solutions that would be compliant to this "theme" is not a good one either. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 14:59:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19263 for ; Wed, 27 Mar 2002 14:59:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05704 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 14:59:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05051; Wed, 27 Mar 2002 14:52:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05022 for ; Wed, 27 Mar 2002 14:52:42 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18959 for ; Wed, 27 Mar 2002 14:52:40 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJqxs05948 for ; Wed, 27 Mar 2002 13:52:59 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:52:40 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:51:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 14:51:46 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHVxwFK0sozt+0xR7GYRKq2zeOnfgAAEzXg To: , , , X-OriginalArrivalTime: 27 Mar 2002 19:51:47.0064 (UTC) FILETIME=[D4094F80:01C1D5C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA05023 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, Actually, I would prefer to avoid any mention of AR based discovery in the requirements. To me, this is an implementation issue. I would like the requirements to clearly state that the MN is in charge. If it turns out that a network based implemention makes some sense, then it can be considered during the protocol design. [DOT] If we could word the requirements in a way that it still allows network assistance, keeping in mind that the MN's requirements are the overall constraint of the design, this would be fine. But the way it has been proposed so far does not suffice to me. But at least I sense a common understanding that it should still be possible to involve the network in parts where it "makes sense", which could be related to avoiding unnecessary information transfer for instance. The point in the current discussion is, at least from my part, that we shouldn't replace AR-biased wordings by MN-biased ones. It is the theme that counts, namely that it is the MN that makes the final decision. Everything that does not allow this is not a good solution. But every requirement that does not allow solutions that would be compliant to this "theme" is not a good one either. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:01:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19385 for ; Wed, 27 Mar 2002 15:01:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05245; Wed, 27 Mar 2002 14:55:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05213 for ; Wed, 27 Mar 2002 14:55:09 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19049 for ; Wed, 27 Mar 2002 14:55:07 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJvR111768 for ; Wed, 27 Mar 2002 13:57:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:54:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:54:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 14:54:47 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Thread-Index: AcHVxwRw1Yty98niROK8JaB9FOGgPgAAefhg To: , , X-OriginalArrivalTime: 27 Mar 2002 19:54:49.0149 (UTC) FILETIME=[409146D0:01C1D5C9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA05214 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, => i'm sure there are ways, but why? If there is a GAAR the MN will hear it, if it can't then it's not relevant for the search. Isn't this nice and simple? But I'm sure there can be more ways of doing it, I just want the simplest one. [DOT] The simplest solution is not only the one that has a simple RA extension. If the solution involves exchange of data that is in large parts not necessary, then another solution with more messages but less traffic might be better, in particular over wireless interfaces. But again, which one is the simplest (regarding several measures such as complexity and efficiency) can be assessed once the solutions are there. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 15:01:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19395 for ; Wed, 27 Mar 2002 15:01:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06130 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:01:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05245; Wed, 27 Mar 2002 14:55:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05213 for ; Wed, 27 Mar 2002 14:55:09 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19049 for ; Wed, 27 Mar 2002 14:55:07 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RJvR111768 for ; Wed, 27 Mar 2002 13:57:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 13:54:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 13:54:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Wed, 27 Mar 2002 14:54:47 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Thread-Index: AcHVxwRw1Yty98niROK8JaB9FOGgPgAAefhg To: , , X-OriginalArrivalTime: 27 Mar 2002 19:54:49.0149 (UTC) FILETIME=[409146D0:01C1D5C9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA05214 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hesham, => i'm sure there are ways, but why? If there is a GAAR the MN will hear it, if it can't then it's not relevant for the search. Isn't this nice and simple? But I'm sure there can be more ways of doing it, I just want the simplest one. [DOT] The simplest solution is not only the one that has a simple RA extension. If the solution involves exchange of data that is in large parts not necessary, then another solution with more messages but less traffic might be better, in particular over wireless interfaces. But again, which one is the simplest (regarding several measures such as complexity and efficiency) can be assessed once the solutions are there. Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:28:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21033 for ; Wed, 27 Mar 2002 15:28:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06747; Wed, 27 Mar 2002 15:12:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06720 for ; Wed, 27 Mar 2002 15:12:07 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19840 for ; Wed, 27 Mar 2002 15:12:04 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKB1I13173; Wed, 27 Mar 2002 12:11:01 -0800 (PST) Message-ID: <02b701c1d5cb$4abf1a40$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:09:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Drik, The exact definition of "optimal use" is to be determined by the protocol design. In other words, it is solution space. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 10:23 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > James, > > > > I think that's the essence of it. Do you oppose this? Why? Do you > > want to make things more complicated than they have to be? > > > > [DOT] Avoiding flooding of MN with unnecessary information might > complicate > > the design but might also be a worthwhile goal of a protocol design? > > > > If this is such a big issue then why not a simple requirement that says > the protocol should make optimal use of network bandwidth, with no > wording in it about whether the network or MN is in control? > > [DOT] What is "optimal use"? If we demanded for sending all information to > MNs, then the optimal use would be bounded to maybe compressing the content, but > the optimal use would not consider sending unwanted information if another > requirement demanded it, right? > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 15:28:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21043 for ; Wed, 27 Mar 2002 15:28:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07648 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:28:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06747; Wed, 27 Mar 2002 15:12:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06720 for ; Wed, 27 Mar 2002 15:12:07 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19840 for ; Wed, 27 Mar 2002 15:12:04 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKB1I13173; Wed, 27 Mar 2002 12:11:01 -0800 (PST) Message-ID: <02b701c1d5cb$4abf1a40$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:09:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Drik, The exact definition of "optimal use" is to be determined by the protocol design. In other words, it is solution space. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 10:23 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > James, > > > > I think that's the essence of it. Do you oppose this? Why? Do you > > want to make things more complicated than they have to be? > > > > [DOT] Avoiding flooding of MN with unnecessary information might > complicate > > the design but might also be a worthwhile goal of a protocol design? > > > > If this is such a big issue then why not a simple requirement that says > the protocol should make optimal use of network bandwidth, with no > wording in it about whether the network or MN is in control? > > [DOT] What is "optimal use"? If we demanded for sending all information to > MNs, then the optimal use would be bounded to maybe compressing the content, but > the optimal use would not consider sending unwanted information if another > requirement demanded it, right? > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:29:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21091 for ; Wed, 27 Mar 2002 15:29:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07289; Wed, 27 Mar 2002 15:21:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07223 for ; Wed, 27 Mar 2002 15:21:51 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20708 for ; Wed, 27 Mar 2002 15:21:49 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKLHI13592; Wed, 27 Mar 2002 12:21:17 -0800 (PST) Message-ID: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , "George Tsirtsis" , "'Hesham Soliman \\\(ERA\\\)'" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:19:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Ajoy, You are right, CAR discovery won't be needed if the handover is network controlled. It will only be needed if the handover is mobile controlled, and it is really most needed for intertechnology handover. If the handover is network controlled, the Layer 2 protocol basically knows where the MN is going, since it is determined by power levels, and the MN gets moved. That's one reason why I am having a hard time understanding why people want anything at all in the requirements about network controlled handover. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'James Kempf'" ; "George Tsirtsis" ; "'Hesham Soliman \(ERA\)'" ; Sent: Wednesday, March 27, 2002 10:58 AM Subject: RE: [Seamoby] Examples of CAR discovery > Hello James, > I have not been actively involved in CAR discussion, but > I am not sure how MN controlled CAR will really work when L2 handover > is controlled by network. I do agree that in case of > inter-technology or Mobile controlled handover, MN is the right > candidate to select AR. But mostly in cellular where network controlled > handover is used, I don't see how MN can select CAR. Won't > there be inconsistency in L2 and L3 decision? Probably I might > have missed some important discussion. > regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 27, 2002 12:42 PM > To: George Tsirtsis; 'Hesham Soliman \(ERA\)'; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hesham, > > I agree with your comment about passing preferences to the AR. It won't > scale. > > Actually, I would prefer to avoid any mention of AR based discovery in > the requirements. To me, this is an implementation issue. I would like > the requirements to clearly state that the MN is in charge. If it turns > out that a network based implemention makes some sense, then it can be > considered during the protocol design. > > This was the message I took away from Steve's talk. > > jak > > ----- Original Message ----- > From: "George Tsirtsis" > To: "'Hesham Soliman (ERA)'" ; > > Sent: Wednesday, March 27, 2002 9:01 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > For what is worth I am in full agreement with what Hesham is saying > below > > about the scope of this. > > > > George > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, March 27, 2002 4:53 PM > > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > .... > > => I'll let you come up with the new text, but > > my curent concerns on the requirement is: > > > > - The scope of AR-based CAR should be limited > > to one operator's domain and one access technology. > > > > - The MN-based one is naturally limited by the number > > of ARs it can hear. > > > > FWIW, I don't think that passing preferences to > > the AR is a good idea or will ever scale. > > > > Hesham > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:29:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21126 for ; Wed, 27 Mar 2002 15:29:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07375; Wed, 27 Mar 2002 15:23:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07346 for ; Wed, 27 Mar 2002 15:23:53 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20766 for ; Wed, 27 Mar 2002 15:23:51 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKNLI13691; Wed, 27 Mar 2002 12:23:21 -0800 (PST) Message-ID: <030e01c1d5cd$03b5c2a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 12:21:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, What about the requirement I posted: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. Exactly how this is implemented is solution space and therefore out of scope for the requirements. We keep coming back to this. :-) jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 10:54 AM Subject: [Seamoby] MN in charge: What does this mean? > Maybe we should clarify first what it means to say that the MN is in charge. > Making some computations in the network rather than the MN while > fully taking care of the MN's requirements does not mean that the MN is > not in charge is it? This is essentially done for various constraints, > which we have listed out ad nauseam.. so let me not repeat that again. > > Thanks, > Govind > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 15:29:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21135 for ; Wed, 27 Mar 2002 15:29:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07699 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:29:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07375; Wed, 27 Mar 2002 15:23:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07346 for ; Wed, 27 Mar 2002 15:23:53 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20766 for ; Wed, 27 Mar 2002 15:23:51 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKNLI13691; Wed, 27 Mar 2002 12:23:21 -0800 (PST) Message-ID: <030e01c1d5cd$03b5c2a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 12:21:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, What about the requirement I posted: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. Exactly how this is implemented is solution space and therefore out of scope for the requirements. We keep coming back to this. :-) jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 10:54 AM Subject: [Seamoby] MN in charge: What does this mean? > Maybe we should clarify first what it means to say that the MN is in charge. > Making some computations in the network rather than the MN while > fully taking care of the MN's requirements does not mean that the MN is > not in charge is it? This is essentially done for various constraints, > which we have listed out ad nauseam.. so let me not repeat that again. > > Thanks, > Govind > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:33:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21318 for ; Wed, 27 Mar 2002 15:33:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07599; Wed, 27 Mar 2002 15:28:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07568 for ; Wed, 27 Mar 2002 15:28:03 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21009 for ; Wed, 27 Mar 2002 15:28:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKRRI13822; Wed, 27 Mar 2002 12:27:27 -0800 (PST) Message-ID: <032e01c1d5cd$968c65c0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:25:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > However, I am sympathetic to the efficiency argument and have no > objection to a network efficiency requirement. I posted one in a > response to Hemant's message. > > [DOT] As I said in a previous email, what is the efficiency requirement > worth if another requirement demands for sending all this information?? > It is maybe useful for choosing a representation format for the transferred > information that is as efficient as possible. > It means that the protocol must be as efficient as possible. Full stop. Anything else is solution space. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 15:33:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21329 for ; Wed, 27 Mar 2002 15:33:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08343 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:33:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07599; Wed, 27 Mar 2002 15:28:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07568 for ; Wed, 27 Mar 2002 15:28:03 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21009 for ; Wed, 27 Mar 2002 15:28:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKRRI13822; Wed, 27 Mar 2002 12:27:27 -0800 (PST) Message-ID: <032e01c1d5cd$968c65c0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of CAR discovery) Date: Wed, 27 Mar 2002 12:25:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > However, I am sympathetic to the efficiency argument and have no > objection to a network efficiency requirement. I posted one in a > response to Hemant's message. > > [DOT] As I said in a previous email, what is the efficiency requirement > worth if another requirement demands for sending all this information?? > It is maybe useful for choosing a representation format for the transferred > information that is as efficient as possible. > It means that the protocol must be as efficient as possible. Full stop. Anything else is solution space. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:35:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21380 for ; Wed, 27 Mar 2002 15:35:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08270; Wed, 27 Mar 2002 15:31:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08231 for ; Wed, 27 Mar 2002 15:31:55 -0500 (EST) Received: from hotmail.com (f118.law9.hotmail.com [64.4.9.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21262 for ; Wed, 27 Mar 2002 15:31:53 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:31:25 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:31:24 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 15:31:24 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:31:25.0026 (UTC) FILETIME=[5D698420:01C1D5CE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I think the main point of contention is that why I started this thread. What you say that the MN MUST physically get all the GAARs and their capabilities. I think that is a little to restrictive. I don't think that is necessary to accomplish the goal. I think the reason why we are coming back to this requirement is because I guess we don't see eye to eye on this :). But I sure hope we can soon. Regards, Govind. > >Govind, > >What about the requirement I posted: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > >Exactly how this is implemented is solution space and therefore out of >scope for the requirements. > >We keep coming back to this. :-) > > jak _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 15:35:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21390 for ; Wed, 27 Mar 2002 15:35:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08541 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:35:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08270; Wed, 27 Mar 2002 15:31:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08231 for ; Wed, 27 Mar 2002 15:31:55 -0500 (EST) Received: from hotmail.com (f118.law9.hotmail.com [64.4.9.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21262 for ; Wed, 27 Mar 2002 15:31:53 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:31:25 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:31:24 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 15:31:24 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:31:25.0026 (UTC) FILETIME=[5D698420:01C1D5CE] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, I think the main point of contention is that why I started this thread. What you say that the MN MUST physically get all the GAARs and their capabilities. I think that is a little to restrictive. I don't think that is necessary to accomplish the goal. I think the reason why we are coming back to this requirement is because I guess we don't see eye to eye on this :). But I sure hope we can soon. Regards, Govind. > >Govind, > >What about the requirement I posted: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. > >Exactly how this is implemented is solution space and therefore out of >scope for the requirements. > >We keep coming back to this. :-) > > jak _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:38:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21537 for ; Wed, 27 Mar 2002 15:38:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08730; Wed, 27 Mar 2002 15:36:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08699 for ; Wed, 27 Mar 2002 15:36:32 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21474 for ; Wed, 27 Mar 2002 15:36:30 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKZRI14144; Wed, 27 Mar 2002 12:35:27 -0800 (PST) Message-ID: <035f01c1d5ce$b43891b0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:33:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Guys, Let's try to keep the tone at a high level and avoid accusations, OK? Perhaps we need to slow down the discussion and give Govind a chance to digest the discourse so far. I'll make a proposal this afternoon. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 11:19 AM Subject: RE: [Seamoby] Examples of CAR discovery > Hesham, > > > [DOT] Now don't let us drift into this, ok. First, I saw > > Govind, George, and myself > > agreeing with Hemant's interpretation of this requirement. > > Second, the term "misapprehension" > > sounds to me like an assumption that you're right with your > > interpretation, which I don't > > want to comment further. The controversial point is exactly > > that there are different > > interpretations of a single requirement due to the chosen wording. > > > > => No, it\s not the wording, it is a clear > bias towards a certain model. Govind agreed that > there is a bias, but you insist on keeping > the discussion within the wording domain. > This is not going to help. We need clear requirements > and we need to distinguish between the entities > invloved in the CAR discovery. We do not want requirements > that can be interpreted in several ways. > > [DOT] Before you start offending people like this on the mailing list, > start reading mails thoroughly before you answer. I did agree on the same > bias and its removal from the requirements. And stating clear requirements that do not > allow different interpretations is exactly what the text above was about. Since you > agreed on this, too, we can start re-wording the requirement in a way that we can find > consensus. > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 15:38:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21549 for ; Wed, 27 Mar 2002 15:38:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08896 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:38:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08730; Wed, 27 Mar 2002 15:36:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08699 for ; Wed, 27 Mar 2002 15:36:32 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21474 for ; Wed, 27 Mar 2002 15:36:30 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKZRI14144; Wed, 27 Mar 2002 12:35:27 -0800 (PST) Message-ID: <035f01c1d5ce$b43891b0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:33:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Guys, Let's try to keep the tone at a high level and avoid accusations, OK? Perhaps we need to slow down the discussion and give Govind a chance to digest the discourse so far. I'll make a proposal this afternoon. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 11:19 AM Subject: RE: [Seamoby] Examples of CAR discovery > Hesham, > > > [DOT] Now don't let us drift into this, ok. First, I saw > > Govind, George, and myself > > agreeing with Hemant's interpretation of this requirement. > > Second, the term "misapprehension" > > sounds to me like an assumption that you're right with your > > interpretation, which I don't > > want to comment further. The controversial point is exactly > > that there are different > > interpretations of a single requirement due to the chosen wording. > > > > => No, it\s not the wording, it is a clear > bias towards a certain model. Govind agreed that > there is a bias, but you insist on keeping > the discussion within the wording domain. > This is not going to help. We need clear requirements > and we need to distinguish between the entities > invloved in the CAR discovery. We do not want requirements > that can be interpreted in several ways. > > [DOT] Before you start offending people like this on the mailing list, > start reading mails thoroughly before you answer. I did agree on the same > bias and its removal from the requirements. And stating clear requirements that do not > allow different interpretations is exactly what the text above was about. Since you > agreed on this, too, we can start re-wording the requirement in a way that we can find > consensus. > > Dirk > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21822 for ; Wed, 27 Mar 2002 15:42:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09181; Wed, 27 Mar 2002 15:40:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09147 for ; Wed, 27 Mar 2002 15:40:33 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21769 for ; Wed, 27 Mar 2002 15:40:31 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKdwI14290; Wed, 27 Mar 2002 12:39:58 -0800 (PST) Message-ID: <037b01c1d5cf$55bcd5f0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 12:38:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, This is solution space. Without examining this in detail, we can't say. The intent of the requirements is to constrain the solution through high level goals, not specify them in detail. The information could be handled by a 16 bit bit vector, or it could require an ASN.1 LDAP query, we cannot say at this point. That's why I and others think that we need to clearly state that the MN gets the information it needs. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 11:39 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > > Govind, > > We have to think about what the requirement is intending to accomplish. > If we don't mention that, then the requirement becomes meaningless. The > intent is to get the MN the information it needs to select the next AR. > Thus, I believe we must mention the MN. > > [DOT] But isn't that the disagreement, namely the amount of information > the MN needs to select? Assuming that MN could, by any means, connect/handover > to x ARs, does it really mean that the MN has to get the entire information > of all these x ARs? What if only y ARs satify the MN's requirements? It still > sufficient (and even MN-controlled) to choose out of these y since the other > ones are worthless. > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:44:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21917 for ; Wed, 27 Mar 2002 15:44:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09263; Wed, 27 Mar 2002 15:41:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09235 for ; Wed, 27 Mar 2002 15:41:37 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21796 for ; Wed, 27 Mar 2002 15:41:34 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKf6I14334; Wed, 27 Mar 2002 12:41:06 -0800 (PST) Message-ID: <038101c1d5cf$7e53c410$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 12:39:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Because this is a solution, not a requirement. The requirement is that the MN get the information it needs. How that is implemented is up to the protocol. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 11:36 AM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > James, > I agree that an incompletely stated requirement is meaningless. > > But I just don't seem to understand why you claim that an AR based scheme > which can take the MN's requirement totally into consideration cannot do the > job which you illustrate? Note that I have never > said what you propose is not feasible but the feasibility of what I propose > is also true. Can't we have a happy medium? :) > > Thanks, > -Govind. > > > > > >Govind, > > > >We have to think about what the requirement is intending to accomplish. > >If we don't mention that, then the requirement becomes meaningless. The > >intent is to get the MN the information it needs to select the next AR. > >Thus, I believe we must mention the MN. > > > > jak > > > >----- Original Message ----- > >From: "Govind Krishnamurthi" > >To: > >Sent: Wednesday, March 27, 2002 10:03 AM > >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of > > > > > > > James, > > > > > > >Here's the requirement: > > > > > > > > The other fundamental function of CAR discovery protocols is > >that of > > > > identifying the capabilities of GAARs. The protocol MUST provide > > > > functionality to allow ARs to discover their GAAR's > >capabilities. > > > >These > > > > capabilities MUST be communicated in a secure fashion. > > > > > > > >There is not one single mention of the MN in this requirement. > > > > > > > >How can you interpret that this requirement does NOT put the AR in > > > >control? This is exactly the message Steve Deering was trying to get > > > >across in the Minne-apple. > > > > > > [Govind] There is a bias and I agree that the bias should be removed. > > > > > > But > > > what you are suggesting is to swing the pendulum to the opposite end > > > putting an MN bias. We should work toward an un-biased set of > >requirements, > > > IMHO, and thats what I will endeavor to do based on the discussions in > >the > > > mailing list. > > > > > > Regards, > > > Govind. > > > > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 15:55:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22361 for ; Wed, 27 Mar 2002 15:55:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09676; Wed, 27 Mar 2002 15:49:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09646 for ; Wed, 27 Mar 2002 15:49:19 -0500 (EST) Received: from hotmail.com (f216.law9.hotmail.com [64.4.9.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22127 for ; Wed, 27 Mar 2002 15:49:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:48:49 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:48:48 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 15:48:48 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:48:49.0145 (UTC) FILETIME=[CBC16E90:01C1D5D0] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, I don't completely understand your mail. Let me make clear my concern. What are you referring to as a solution? The objective of CAR discovery is to match the GAARs capabilities to the MN's requirements to come up with a set of CARs. That is a requirement. I would say pushing GAARs and their capabilities to the MN is a solution as it describes a way to do it. Regards, Govind. > >Govind, > >Because this is a solution, not a requirement. > >The requirement is that the MN get the information it needs. How that is >implemented is up to the protocol. > > jak > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 15:55:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22371 for ; Wed, 27 Mar 2002 15:55:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10058 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:55:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09676; Wed, 27 Mar 2002 15:49:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09646 for ; Wed, 27 Mar 2002 15:49:19 -0500 (EST) Received: from hotmail.com (f216.law9.hotmail.com [64.4.9.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22127 for ; Wed, 27 Mar 2002 15:49:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:48:49 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:48:48 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 15:48:48 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:48:49.0145 (UTC) FILETIME=[CBC16E90:01C1D5D0] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Govind, I don't completely understand your mail. Let me make clear my concern. What are you referring to as a solution? The objective of CAR discovery is to match the GAARs capabilities to the MN's requirements to come up with a set of CARs. That is a requirement. I would say pushing GAARs and their capabilities to the MN is a solution as it describes a way to do it. Regards, Govind. > >Govind, > >Because this is a solution, not a requirement. > >The requirement is that the MN get the information it needs. How that is >implemented is up to the protocol. > > jak > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:00:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22574 for ; Wed, 27 Mar 2002 16:00:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09818; Wed, 27 Mar 2002 15:52:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09787 for ; Wed, 27 Mar 2002 15:52:38 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22250 for ; Wed, 27 Mar 2002 15:52:34 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RKqis12640 for ; Wed, 27 Mar 2002 22:52:45 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 22:52:30 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 22:52:29 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 14:51:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 15:51:06 -0500 Message-ID: Thread-Topic: [Seamoby] MN in charge: What does this mean? Thread-Index: AcHVzVmVmmc++i21Sni4XDD/cZfcKgAAJA5w To: , , X-OriginalArrivalTime: 27 Mar 2002 20:51:07.0055 (UTC) FILETIME=[1DF4D3F0:01C1D5D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA09788 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, What about the requirement I posted: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. [DOT] The MN being 'in charge' should not imply that it receives information it probably doesn't need. MN 'in charge' can also mean that it can express what information it wants to receive. After receiving information, the MN is still 'in charge' of the final decision though. [DOT] Just to make some progress on this issue, may I propose the following wording: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. The information provision MUST/SHOULD avoid the transmission of unnecessary information. [DOT] Does this accomplish your efficiency statement? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:00:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22584 for ; Wed, 27 Mar 2002 16:00:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10542 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:00:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09818; Wed, 27 Mar 2002 15:52:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09787 for ; Wed, 27 Mar 2002 15:52:38 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22250 for ; Wed, 27 Mar 2002 15:52:34 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RKqis12640 for ; Wed, 27 Mar 2002 22:52:45 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 22:52:30 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 22:52:29 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 14:51:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 15:51:06 -0500 Message-ID: Thread-Topic: [Seamoby] MN in charge: What does this mean? Thread-Index: AcHVzVmVmmc++i21Sni4XDD/cZfcKgAAJA5w To: , , X-OriginalArrivalTime: 27 Mar 2002 20:51:07.0055 (UTC) FILETIME=[1DF4D3F0:01C1D5D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA09788 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, What about the requirement I posted: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. [DOT] The MN being 'in charge' should not imply that it receives information it probably doesn't need. MN 'in charge' can also mean that it can express what information it wants to receive. After receiving information, the MN is still 'in charge' of the final decision though. [DOT] Just to make some progress on this issue, may I propose the following wording: The CAR discovery protocol MUST provide the MN with GAAR information, along with capabilities. The information provision MUST/SHOULD avoid the transmission of unnecessary information. [DOT] Does this accomplish your efficiency statement? Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:01:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22650 for ; Wed, 27 Mar 2002 16:01:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09958; Wed, 27 Mar 2002 15:54:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09908 for ; Wed, 27 Mar 2002 15:54:39 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22275 for ; Wed, 27 Mar 2002 15:54:36 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKs6I14770; Wed, 27 Mar 2002 12:54:06 -0800 (PST) Message-ID: <03cc01c1d5d1$4fa662b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 12:52:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit So propose a requirement that you think addresses our concerns. I've proposed what I like, and from the response there look as if at least 2 and possibly 4 other working group members agree with me. There is clearly a contingent of people that have spoken on the list who do not agree with the way the current requirement is phrased, and I've gotten private email from some people who can't speak out on the list but agree with our position. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 12:31 PM Subject: Re: [Seamoby] MN in charge: What does this mean? > James, > I think the main point of contention is that why I started this thread. > What you say that the MN MUST physically get all the GAARs and their > capabilities. I think that is a little to restrictive. I don't think > that is necessary to accomplish the goal. I think the reason why > we are coming back to this requirement is because I guess we don't > see eye to eye on this :). But I sure hope we can soon. > > Regards, > Govind. > > > > > >Govind, > > > >What about the requirement I posted: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > >Exactly how this is implemented is solution space and therefore out of > >scope for the requirements. > > > >We keep coming back to this. :-) > > > > jak > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:01:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22659 for ; Wed, 27 Mar 2002 16:01:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10900 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:02:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09958; Wed, 27 Mar 2002 15:54:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09908 for ; Wed, 27 Mar 2002 15:54:39 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22275 for ; Wed, 27 Mar 2002 15:54:36 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKs6I14770; Wed, 27 Mar 2002 12:54:06 -0800 (PST) Message-ID: <03cc01c1d5d1$4fa662b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 12:52:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit So propose a requirement that you think addresses our concerns. I've proposed what I like, and from the response there look as if at least 2 and possibly 4 other working group members agree with me. There is clearly a contingent of people that have spoken on the list who do not agree with the way the current requirement is phrased, and I've gotten private email from some people who can't speak out on the list but agree with our position. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 12:31 PM Subject: Re: [Seamoby] MN in charge: What does this mean? > James, > I think the main point of contention is that why I started this thread. > What you say that the MN MUST physically get all the GAARs and their > capabilities. I think that is a little to restrictive. I don't think > that is necessary to accomplish the goal. I think the reason why > we are coming back to this requirement is because I guess we don't > see eye to eye on this :). But I sure hope we can soon. > > Regards, > Govind. > > > > > >Govind, > > > >What about the requirement I posted: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > >Exactly how this is implemented is solution space and therefore out of > >scope for the requirements. > > > >We keep coming back to this. :-) > > > > jak > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:04:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22798 for ; Wed, 27 Mar 2002 16:04:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10116; Wed, 27 Mar 2002 15:56:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10071 for ; Wed, 27 Mar 2002 15:56:02 -0500 (EST) Received: from frascone.com (goaway@adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22388 for ; Wed, 27 Mar 2002 15:55:59 -0500 (EST) Received: (qmail 8523 invoked by uid 500); 27 Mar 2002 20:55:59 -0000 Date: Wed, 27 Mar 2002 14:55:59 -0600 From: David Frascone To: Govind Krishnamurthi Cc: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Message-ID: <20020327205559.GI4284@newman.frascone.com> Mail-Followup-To: Govind Krishnamurthi , seamoby@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org I've been lurking for most of this thread, but I really have to stop now and ask where you are getting the extra text that you are paraphrasing. I see "MUST provide the MN with GAAR information". You paraphrase, "MUST physically get all the GAARs and their capabilities". I think if you re-read Jim's sentence, you'll see that you are somehow misunderstanding it. Personally, I say leave the line as it is. -Dave On Wednesday, 27 Mar 2002, Govind Krishnamurthi wrote: > James, > I think the main point of contention is that why I started this thread. > What you say that the MN MUST physically get all the GAARs and their > capabilities. I think that is a little to restrictive. I don't think > that is necessary to accomplish the goal. I think the reason why > we are coming back to this requirement is because I guess we don't > see eye to eye on this :). But I sure hope we can soon. > > Regards, > Govind. > > > > > >Govind, > > > >What about the requirement I posted: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > >Exactly how this is implemented is solution space and therefore out of > >scope for the requirements. > > > >We keep coming back to this. :-) > > > > jak -- David Frascone Black Holes are Out of Sight _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:04:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22807 for ; Wed, 27 Mar 2002 16:04:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11296 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:04:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10116; Wed, 27 Mar 2002 15:56:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10071 for ; Wed, 27 Mar 2002 15:56:02 -0500 (EST) Received: from frascone.com (goaway@adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22388 for ; Wed, 27 Mar 2002 15:55:59 -0500 (EST) Received: (qmail 8523 invoked by uid 500); 27 Mar 2002 20:55:59 -0000 Date: Wed, 27 Mar 2002 14:55:59 -0600 From: David Frascone To: Govind Krishnamurthi Cc: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Message-ID: <20020327205559.GI4284@newman.frascone.com> Mail-Followup-To: Govind Krishnamurthi , seamoby@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org I've been lurking for most of this thread, but I really have to stop now and ask where you are getting the extra text that you are paraphrasing. I see "MUST provide the MN with GAAR information". You paraphrase, "MUST physically get all the GAARs and their capabilities". I think if you re-read Jim's sentence, you'll see that you are somehow misunderstanding it. Personally, I say leave the line as it is. -Dave On Wednesday, 27 Mar 2002, Govind Krishnamurthi wrote: > James, > I think the main point of contention is that why I started this thread. > What you say that the MN MUST physically get all the GAARs and their > capabilities. I think that is a little to restrictive. I don't think > that is necessary to accomplish the goal. I think the reason why > we are coming back to this requirement is because I guess we don't > see eye to eye on this :). But I sure hope we can soon. > > Regards, > Govind. > > > > > >Govind, > > > >What about the requirement I posted: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > >Exactly how this is implemented is solution space and therefore out of > >scope for the requirements. > > > >We keep coming back to this. :-) > > > > jak -- David Frascone Black Holes are Out of Sight _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:04:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22835 for ; Wed, 27 Mar 2002 16:04:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10208; Wed, 27 Mar 2002 15:57:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10177 for ; Wed, 27 Mar 2002 15:56:59 -0500 (EST) Received: from hotmail.com (f181.law7.hotmail.com [216.33.237.181]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22413 for ; Wed, 27 Mar 2002 15:56:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:56:28 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:56:28 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 20:56:28 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:56:28.0949 (UTC) FILETIME=[DDD1F450:01C1D5D1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: The problem statement says "load balancing" as one example. How is router load information obtained from layer 2? Hemant >From: "James Kempf" >To: "Singh Ajoy-ASINGH1" , "George Tsirtsis" >, "'Hesham Soliman \\\(ERA\\\)'" >, >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 12:19:40 -0800 > >Ajoy, > >You are right, CAR discovery won't be needed if the handover is network >controlled. It will only be needed if the handover is mobile controlled, >and it is really most needed for intertechnology handover. If the >handover is network controlled, the Layer 2 protocol basically knows >where the MN is going, since it is determined by power levels, and the >MN gets moved. > >That's one reason why I am having a hard time understanding why people >want anything at all in the requirements about network controlled >handover. > > jak > >----- Original Message ----- >From: "Singh Ajoy-ASINGH1" >To: "'James Kempf'" ; "George Tsirtsis" >; "'Hesham Soliman \(ERA\)'" >; >Sent: Wednesday, March 27, 2002 10:58 AM >Subject: RE: [Seamoby] Examples of CAR discovery > > > > Hello James, > > I have not been actively involved in CAR discussion, but > > I am not sure how MN controlled CAR will really work when L2 handover > > is controlled by network. I do agree that in case of > > inter-technology or Mobile controlled handover, MN is the right > > candidate to select AR. But mostly in cellular where network >controlled > > handover is used, I don't see how MN can select CAR. Won't > > there be inconsistency in L2 and L3 decision? Probably I might > > have missed some important discussion. > > regards, > > ajoy > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, March 27, 2002 12:42 PM > > To: George Tsirtsis; 'Hesham Soliman \(ERA\)'; seamoby@ietf.org > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hesham, > > > > I agree with your comment about passing preferences to the AR. It >won't > > scale. > > > > Actually, I would prefer to avoid any mention of AR based discovery in > > the requirements. To me, this is an implementation issue. I would like > > the requirements to clearly state that the MN is in charge. If it >turns > > out that a network based implemention makes some sense, then it can be > > considered during the protocol design. > > > > This was the message I took away from Steve's talk. > > > > jak > > > > ----- Original Message ----- > > From: "George Tsirtsis" > > To: "'Hesham Soliman (ERA)'" ; > > > > Sent: Wednesday, March 27, 2002 9:01 AM > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > For what is worth I am in full agreement with what Hesham is saying > > below > > > about the scope of this. > > > > > > George > > > > > > -----Original Message----- > > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > > Sent: Wednesday, March 27, 2002 4:53 PM > > > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > .... > > > => I'll let you come up with the new text, but > > > my curent concerns on the requirement is: > > > > > > - The scope of AR-based CAR should be limited > > > to one operator's domain and one access technology. > > > > > > - The MN-based one is naturally limited by the number > > > of ARs it can hear. > > > > > > FWIW, I don't think that passing preferences to > > > the AR is a good idea or will ever scale. > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:04:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22849 for ; Wed, 27 Mar 2002 16:04:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11345 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:04:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10208; Wed, 27 Mar 2002 15:57:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10177 for ; Wed, 27 Mar 2002 15:56:59 -0500 (EST) Received: from hotmail.com (f181.law7.hotmail.com [216.33.237.181]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22413 for ; Wed, 27 Mar 2002 15:56:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:56:28 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:56:28 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 20:56:28 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:56:28.0949 (UTC) FILETIME=[DDD1F450:01C1D5D1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: The problem statement says "load balancing" as one example. How is router load information obtained from layer 2? Hemant >From: "James Kempf" >To: "Singh Ajoy-ASINGH1" , "George Tsirtsis" >, "'Hesham Soliman \\\(ERA\\\)'" >, >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Wed, 27 Mar 2002 12:19:40 -0800 > >Ajoy, > >You are right, CAR discovery won't be needed if the handover is network >controlled. It will only be needed if the handover is mobile controlled, >and it is really most needed for intertechnology handover. If the >handover is network controlled, the Layer 2 protocol basically knows >where the MN is going, since it is determined by power levels, and the >MN gets moved. > >That's one reason why I am having a hard time understanding why people >want anything at all in the requirements about network controlled >handover. > > jak > >----- Original Message ----- >From: "Singh Ajoy-ASINGH1" >To: "'James Kempf'" ; "George Tsirtsis" >; "'Hesham Soliman \(ERA\)'" >; >Sent: Wednesday, March 27, 2002 10:58 AM >Subject: RE: [Seamoby] Examples of CAR discovery > > > > Hello James, > > I have not been actively involved in CAR discussion, but > > I am not sure how MN controlled CAR will really work when L2 handover > > is controlled by network. I do agree that in case of > > inter-technology or Mobile controlled handover, MN is the right > > candidate to select AR. But mostly in cellular where network >controlled > > handover is used, I don't see how MN can select CAR. Won't > > there be inconsistency in L2 and L3 decision? Probably I might > > have missed some important discussion. > > regards, > > ajoy > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, March 27, 2002 12:42 PM > > To: George Tsirtsis; 'Hesham Soliman \(ERA\)'; seamoby@ietf.org > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hesham, > > > > I agree with your comment about passing preferences to the AR. It >won't > > scale. > > > > Actually, I would prefer to avoid any mention of AR based discovery in > > the requirements. To me, this is an implementation issue. I would like > > the requirements to clearly state that the MN is in charge. If it >turns > > out that a network based implemention makes some sense, then it can be > > considered during the protocol design. > > > > This was the message I took away from Steve's talk. > > > > jak > > > > ----- Original Message ----- > > From: "George Tsirtsis" > > To: "'Hesham Soliman (ERA)'" ; > > > > Sent: Wednesday, March 27, 2002 9:01 AM > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > For what is worth I am in full agreement with what Hesham is saying > > below > > > about the scope of this. > > > > > > George > > > > > > -----Original Message----- > > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > > Sent: Wednesday, March 27, 2002 4:53 PM > > > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > .... > > > => I'll let you come up with the new text, but > > > my curent concerns on the requirement is: > > > > > > - The scope of AR-based CAR should be limited > > > to one operator's domain and one access technology. > > > > > > - The MN-based one is naturally limited by the number > > > of ARs it can hear. > > > > > > FWIW, I don't think that passing preferences to > > > the AR is a good idea or will ever scale. > > > > > > Hesham > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > MSN Photos is the easiest way to share and print your photos: > > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:04:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22888 for ; Wed, 27 Mar 2002 16:04:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10297; Wed, 27 Mar 2002 15:59:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10267 for ; Wed, 27 Mar 2002 15:58:59 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22480 for ; Wed, 27 Mar 2002 15:58:56 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RL0w118140 for ; Wed, 27 Mar 2002 15:00:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 14:58:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 14:57:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 15:57:14 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHVz57RltRwV0aITviqjxxyxmZ2vgAAdGrA To: , , X-OriginalArrivalTime: 27 Mar 2002 20:57:15.0448 (UTC) FILETIME=[F9892380:01C1D5D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA10268 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, This is solution space. Without examining this in detail, we can't say. The intent of the requirements is to constrain the solution through high level goals, not specify them in detail. The information could be handled by a 16 bit bit vector, or it could require an ASN.1 LDAP query, we cannot say at this point. That's why I and others think that we need to clearly state that the MN gets the information it needs. [DOT] The reason of contention is simply that I want to avoid a requirement that reads like providing unnecessary information to the MN. We're totally in agreement that the MN should get the information to make the decision. See my proposed wording in my other mail to address this. I just want to avoid that someone is coming back later saying "hey, your solution is not giving me ALL GAAR info that you have, hence it is not compliant to the requirements". Dirk ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 11:39 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > > Govind, > > We have to think about what the requirement is intending to accomplish. > If we don't mention that, then the requirement becomes meaningless. The > intent is to get the MN the information it needs to select the next AR. > Thus, I believe we must mention the MN. > > [DOT] But isn't that the disagreement, namely the amount of information > the MN needs to select? Assuming that MN could, by any means, connect/handover > to x ARs, does it really mean that the MN has to get the entire information > of all these x ARs? What if only y ARs satify the MN's requirements? It still > sufficient (and even MN-controlled) to choose out of these y since the other > ones are worthless. > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22899 for ; Wed, 27 Mar 2002 16:04:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11469 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:04:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10297; Wed, 27 Mar 2002 15:59:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10267 for ; Wed, 27 Mar 2002 15:58:59 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22480 for ; Wed, 27 Mar 2002 15:58:56 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RL0w118140 for ; Wed, 27 Mar 2002 15:00:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 14:58:32 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 14:57:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 15:57:14 -0500 Message-ID: Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHVz57RltRwV0aITviqjxxyxmZ2vgAAdGrA To: , , X-OriginalArrivalTime: 27 Mar 2002 20:57:15.0448 (UTC) FILETIME=[F9892380:01C1D5D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA10268 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, This is solution space. Without examining this in detail, we can't say. The intent of the requirements is to constrain the solution through high level goals, not specify them in detail. The information could be handled by a 16 bit bit vector, or it could require an ASN.1 LDAP query, we cannot say at this point. That's why I and others think that we need to clearly state that the MN gets the information it needs. [DOT] The reason of contention is simply that I want to avoid a requirement that reads like providing unnecessary information to the MN. We're totally in agreement that the MN should get the information to make the decision. See my proposed wording in my other mail to address this. I just want to avoid that someone is coming back later saying "hey, your solution is not giving me ALL GAAR info that you have, hence it is not compliant to the requirements". Dirk ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 11:39 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > > Govind, > > We have to think about what the requirement is intending to accomplish. > If we don't mention that, then the requirement becomes meaningless. The > intent is to get the MN the information it needs to select the next AR. > Thus, I believe we must mention the MN. > > [DOT] But isn't that the disagreement, namely the amount of information > the MN needs to select? Assuming that MN could, by any means, connect/handover > to x ARs, does it really mean that the MN has to get the entire information > of all these x ARs? What if only y ARs satify the MN's requirements? It still > sufficient (and even MN-controlled) to choose out of these y since the other > ones are worthless. > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:05:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22942 for ; Wed, 27 Mar 2002 16:05:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09966; Wed, 27 Mar 2002 15:54:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09913 for ; Wed, 27 Mar 2002 15:54:40 -0500 (EST) Received: from hotmail.com (f149.law7.hotmail.com [216.33.237.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22276 for ; Wed, 27 Mar 2002 15:54:36 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:54:08 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:54:08 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 20:54:08 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:54:08.0512 (UTC) FILETIME=[8A1CF800:01C1D5D1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: To get around the possible interpretation of forced physical delivery part of it, how do you like: "The GAARs and their capabilities MUST be made available to the entity performs comparison of MN's requirements and capabilities of GAARs. When this comparison is done in MN, the GAARs and their capabilities MUST be made available to MN. MN MUST be given full control of deciding about the entity that performs this comparison." If you do not like it, ignore it. Thanks. Hemant >From: "James Kempf" >To: , , >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of >Date: Wed, 27 Mar 2002 12:38:21 -0800 > >Dirk, > >This is solution space. Without examining this in detail, we can't say. >The intent of the requirements is to constrain the solution through high >level goals, not specify them in detail. The information could be >handled by a 16 bit bit vector, or it could require an ASN.1 LDAP query, >we cannot say at this point. > >That's why I and others think that we need to clearly state that the MN >gets the information it needs. > > jak > >----- Original Message ----- >From: >To: ; ; >Sent: Wednesday, March 27, 2002 11:39 AM >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of > > > > > > Govind, > > > > We have to think about what the requirement is intending to >accomplish. > > If we don't mention that, then the requirement becomes meaningless. >The > > intent is to get the MN the information it needs to select the next >AR. > > Thus, I believe we must mention the MN. > > > > [DOT] But isn't that the disagreement, namely the amount of >information > > the MN needs to select? Assuming that MN could, by any means, >connect/handover > > to x ARs, does it really mean that the MN has to get the entire >information > > of all these x ARs? What if only y ARs satify the MN's requirements? >It still > > sufficient (and even MN-controlled) to choose out of these y since the >other > > ones are worthless. > > > > Dirk > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:05:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22951 for ; Wed, 27 Mar 2002 16:05:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11582 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:05:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09966; Wed, 27 Mar 2002 15:54:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09913 for ; Wed, 27 Mar 2002 15:54:40 -0500 (EST) Received: from hotmail.com (f149.law7.hotmail.com [216.33.237.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22276 for ; Wed, 27 Mar 2002 15:54:36 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 12:54:08 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 20:54:08 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 20:54:08 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 20:54:08.0512 (UTC) FILETIME=[8A1CF800:01C1D5D1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: To get around the possible interpretation of forced physical delivery part of it, how do you like: "The GAARs and their capabilities MUST be made available to the entity performs comparison of MN's requirements and capabilities of GAARs. When this comparison is done in MN, the GAARs and their capabilities MUST be made available to MN. MN MUST be given full control of deciding about the entity that performs this comparison." If you do not like it, ignore it. Thanks. Hemant >From: "James Kempf" >To: , , >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of >Date: Wed, 27 Mar 2002 12:38:21 -0800 > >Dirk, > >This is solution space. Without examining this in detail, we can't say. >The intent of the requirements is to constrain the solution through high >level goals, not specify them in detail. The information could be >handled by a 16 bit bit vector, or it could require an ASN.1 LDAP query, >we cannot say at this point. > >That's why I and others think that we need to clearly state that the MN >gets the information it needs. > > jak > >----- Original Message ----- >From: >To: ; ; >Sent: Wednesday, March 27, 2002 11:39 AM >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement >(was: Examples of > > > > > > Govind, > > > > We have to think about what the requirement is intending to >accomplish. > > If we don't mention that, then the requirement becomes meaningless. >The > > intent is to get the MN the information it needs to select the next >AR. > > Thus, I believe we must mention the MN. > > > > [DOT] But isn't that the disagreement, namely the amount of >information > > the MN needs to select? Assuming that MN could, by any means, >connect/handover > > to x ARs, does it really mean that the MN has to get the entire >information > > of all these x ARs? What if only y ARs satify the MN's requirements? >It still > > sufficient (and even MN-controlled) to choose out of these y since the >other > > ones are worthless. > > > > Dirk > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:09:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23290 for ; Wed, 27 Mar 2002 16:09:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11277; Wed, 27 Mar 2002 16:03:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11206 for ; Wed, 27 Mar 2002 16:03:52 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22789 for ; Wed, 27 Mar 2002 16:03:50 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RL4gA29970 for ; Wed, 27 Mar 2002 23:04:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 23:03:49 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 23:03:51 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 15:03:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 16:03:47 -0500 Message-ID: Thread-Topic: [Seamoby] MN in charge: What does this mean? Thread-Index: AcHV0a1BAFxXQygOTzmF+OitpFdO9gAAH5AA To: , , X-OriginalArrivalTime: 27 Mar 2002 21:03:48.0544 (UTC) FILETIME=[E3D6D400:01C1D5D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA11207 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, So propose a requirement that you think addresses our concerns. I've proposed what I like, and from the response there look as if at least 2 and possibly 4 other working group members agree with me. There is clearly a contingent of people that have spoken on the list who do not agree with the way the current requirement is phrased, and I've gotten private email from some people who can't speak out on the list but agree with our position. [DOT] Frankly, private emails are of no concern to the WG. However, please have a look at my wording that addresses the avoidance of unnecessary information provision. This is the key issue at stake that is controversial among a set of people that spoke out on the list. Dirk ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 12:31 PM Subject: Re: [Seamoby] MN in charge: What does this mean? > James, > I think the main point of contention is that why I started this thread. > What you say that the MN MUST physically get all the GAARs and their > capabilities. I think that is a little to restrictive. I don't think > that is necessary to accomplish the goal. I think the reason why > we are coming back to this requirement is because I guess we don't > see eye to eye on this :). But I sure hope we can soon. > > Regards, > Govind. > > > > > >Govind, > > > >What about the requirement I posted: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > >Exactly how this is implemented is solution space and therefore out of > >scope for the requirements. > > > >We keep coming back to this. :-) > > > > jak > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:09:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23299 for ; Wed, 27 Mar 2002 16:09:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12224 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:09:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11277; Wed, 27 Mar 2002 16:03:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11206 for ; Wed, 27 Mar 2002 16:03:52 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22789 for ; Wed, 27 Mar 2002 16:03:50 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RL4gA29970 for ; Wed, 27 Mar 2002 23:04:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Mar 2002 23:03:49 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 23:03:51 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 15:03:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 16:03:47 -0500 Message-ID: Thread-Topic: [Seamoby] MN in charge: What does this mean? Thread-Index: AcHV0a1BAFxXQygOTzmF+OitpFdO9gAAH5AA To: , , X-OriginalArrivalTime: 27 Mar 2002 21:03:48.0544 (UTC) FILETIME=[E3D6D400:01C1D5D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA11207 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit James, So propose a requirement that you think addresses our concerns. I've proposed what I like, and from the response there look as if at least 2 and possibly 4 other working group members agree with me. There is clearly a contingent of people that have spoken on the list who do not agree with the way the current requirement is phrased, and I've gotten private email from some people who can't speak out on the list but agree with our position. [DOT] Frankly, private emails are of no concern to the WG. However, please have a look at my wording that addresses the avoidance of unnecessary information provision. This is the key issue at stake that is controversial among a set of people that spoke out on the list. Dirk ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 12:31 PM Subject: Re: [Seamoby] MN in charge: What does this mean? > James, > I think the main point of contention is that why I started this thread. > What you say that the MN MUST physically get all the GAARs and their > capabilities. I think that is a little to restrictive. I don't think > that is necessary to accomplish the goal. I think the reason why > we are coming back to this requirement is because I guess we don't > see eye to eye on this :). But I sure hope we can soon. > > Regards, > Govind. > > > > > >Govind, > > > >What about the requirement I posted: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > > >Exactly how this is implemented is solution space and therefore out of > >scope for the requirements. > > > >We keep coming back to this. :-) > > > > jak > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:09:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23369 for ; Wed, 27 Mar 2002 16:09:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11415; Wed, 27 Mar 2002 16:04:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11371 for ; Wed, 27 Mar 2002 16:04:22 -0500 (EST) Received: from hotmail.com (f244.law9.hotmail.com [64.4.9.244]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22861 for ; Wed, 27 Mar 2002 16:04:20 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 13:03:51 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 21:03:51 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 16:03:51 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 21:03:51.0458 (UTC) FILETIME=[E5937820:01C1D5D2] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, There have been several who haven't agreed too. Regarding others who don't essentially make their opinions here on the list. Do we really have to take them into consideration? I could point out several like that too, is it not? I really hope we don't go in that direction. I would think of making this sending the info the MN as an option requested by the MN as proposed by Hemant is a good start. It takes care of your case when the MN wants it and it takes care of our case when the MN does not also. What do you think? Regards, Govind. > >So propose a requirement that you think addresses our concerns. I've >proposed what I like, and from the response there look as if at least 2 >and possibly 4 other working group members agree with me. There is >clearly a contingent of people that have spoken on the list who do not >agree with the way the current requirement is phrased, and I've gotten >private email from some people who can't speak out on the list but agree >with our position. > > jak > >----- Original Message ----- >From: "Govind Krishnamurthi" >To: >Sent: Wednesday, March 27, 2002 12:31 PM >Subject: Re: [Seamoby] MN in charge: What does this mean? > > > > James, > > I think the main point of contention is that why I started this >thread. > > What you say that the MN MUST physically get all the GAARs and their > > capabilities. I think that is a little to restrictive. I don't think > > that is necessary to accomplish the goal. I think the reason why > > we are coming back to this requirement is because I guess we don't > > see eye to eye on this :). But I sure hope we can soon. > > > > Regards, > > Govind. > > > > > > > > > >Govind, > > > > > >What about the requirement I posted: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > >Exactly how this is implemented is solution space and therefore out >of > > >scope for the requirements. > > > > > >We keep coming back to this. :-) > > > > > > jak > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:09:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23389 for ; Wed, 27 Mar 2002 16:09:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12343 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:09:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11415; Wed, 27 Mar 2002 16:04:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11371 for ; Wed, 27 Mar 2002 16:04:22 -0500 (EST) Received: from hotmail.com (f244.law9.hotmail.com [64.4.9.244]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22861 for ; Wed, 27 Mar 2002 16:04:20 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 13:03:51 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 21:03:51 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 16:03:51 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 21:03:51.0458 (UTC) FILETIME=[E5937820:01C1D5D2] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org James, There have been several who haven't agreed too. Regarding others who don't essentially make their opinions here on the list. Do we really have to take them into consideration? I could point out several like that too, is it not? I really hope we don't go in that direction. I would think of making this sending the info the MN as an option requested by the MN as proposed by Hemant is a good start. It takes care of your case when the MN wants it and it takes care of our case when the MN does not also. What do you think? Regards, Govind. > >So propose a requirement that you think addresses our concerns. I've >proposed what I like, and from the response there look as if at least 2 >and possibly 4 other working group members agree with me. There is >clearly a contingent of people that have spoken on the list who do not >agree with the way the current requirement is phrased, and I've gotten >private email from some people who can't speak out on the list but agree >with our position. > > jak > >----- Original Message ----- >From: "Govind Krishnamurthi" >To: >Sent: Wednesday, March 27, 2002 12:31 PM >Subject: Re: [Seamoby] MN in charge: What does this mean? > > > > James, > > I think the main point of contention is that why I started this >thread. > > What you say that the MN MUST physically get all the GAARs and their > > capabilities. I think that is a little to restrictive. I don't think > > that is necessary to accomplish the goal. I think the reason why > > we are coming back to this requirement is because I guess we don't > > see eye to eye on this :). But I sure hope we can soon. > > > > Regards, > > Govind. > > > > > > > > > >Govind, > > > > > >What about the requirement I posted: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > >Exactly how this is implemented is solution space and therefore out >of > > >scope for the requirements. > > > > > >We keep coming back to this. :-) > > > > > > jak > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:17:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23943 for ; Wed, 27 Mar 2002 16:17:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12433; Wed, 27 Mar 2002 16:10:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12404 for ; Wed, 27 Mar 2002 16:10:13 -0500 (EST) Received: from hotmail.com (f168.law9.hotmail.com [64.4.9.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23439 for ; Wed, 27 Mar 2002 16:10:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 13:09:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 21:09:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: dave@frascone.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 16:09:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 21:09:42.0480 (UTC) FILETIME=[B6CD2D00:01C1D5D3] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org David, I will be very happy to accept that this is a mis-interpretation on my behalf if that is the case. Advance apologies if that is the case. I thought that was the main point of contention with all the bandwidth and power constraint discussion. Maybe if you point out to me why th "MUST provide MN with GAAR and capabilities" does not imply transmitting this information over the wireless interface to the MN (always), then maybe it would be more clear to me. Regards, Govind. >I've been lurking for most of this thread, but I really have to stop >now and ask where you are getting the extra text that you are paraphrasing. > >I see "MUST provide the MN with GAAR information". > >You paraphrase, "MUST physically get all the GAARs and their capabilities". > >I think if you re-read Jim's sentence, you'll see that you are somehow >misunderstanding it. > >Personally, I say leave the line as it is. > >-Dave > >On Wednesday, 27 Mar 2002, Govind Krishnamurthi wrote: > > James, > > I think the main point of contention is that why I started this thread. > > What you say that the MN MUST physically get all the GAARs and their > > capabilities. I think that is a little to restrictive. I don't think > > that is necessary to accomplish the goal. I think the reason why > > we are coming back to this requirement is because I guess we don't > > see eye to eye on this :). But I sure hope we can soon. > > > > Regards, > > Govind. > > > > > > > > > >Govind, > > > > > >What about the requirement I posted: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > >Exactly how this is implemented is solution space and therefore out of > > >scope for the requirements. > > > > > >We keep coming back to this. :-) > > > > > > jak > >-- >David Frascone > > Black Holes are Out of Sight > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:17:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23954 for ; Wed, 27 Mar 2002 16:17:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13321 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:17:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12433; Wed, 27 Mar 2002 16:10:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12404 for ; Wed, 27 Mar 2002 16:10:13 -0500 (EST) Received: from hotmail.com (f168.law9.hotmail.com [64.4.9.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23439 for ; Wed, 27 Mar 2002 16:10:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 13:09:42 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 21:09:42 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: dave@frascone.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 16:09:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 21:09:42.0480 (UTC) FILETIME=[B6CD2D00:01C1D5D3] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org David, I will be very happy to accept that this is a mis-interpretation on my behalf if that is the case. Advance apologies if that is the case. I thought that was the main point of contention with all the bandwidth and power constraint discussion. Maybe if you point out to me why th "MUST provide MN with GAAR and capabilities" does not imply transmitting this information over the wireless interface to the MN (always), then maybe it would be more clear to me. Regards, Govind. >I've been lurking for most of this thread, but I really have to stop >now and ask where you are getting the extra text that you are paraphrasing. > >I see "MUST provide the MN with GAAR information". > >You paraphrase, "MUST physically get all the GAARs and their capabilities". > >I think if you re-read Jim's sentence, you'll see that you are somehow >misunderstanding it. > >Personally, I say leave the line as it is. > >-Dave > >On Wednesday, 27 Mar 2002, Govind Krishnamurthi wrote: > > James, > > I think the main point of contention is that why I started this thread. > > What you say that the MN MUST physically get all the GAARs and their > > capabilities. I think that is a little to restrictive. I don't think > > that is necessary to accomplish the goal. I think the reason why > > we are coming back to this requirement is because I guess we don't > > see eye to eye on this :). But I sure hope we can soon. > > > > Regards, > > Govind. > > > > > > > > > >Govind, > > > > > >What about the requirement I posted: > > > > > > The CAR discovery protocol MUST provide the MN with GAAR > > > information, along with capabilities. > > > > > >Exactly how this is implemented is solution space and therefore out of > > >scope for the requirements. > > > > > >We keep coming back to this. :-) > > > > > > jak > >-- >David Frascone > > Black Holes are Out of Sight > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:25:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21097 for ; Wed, 27 Mar 2002 15:29:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07684 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:29:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07289; Wed, 27 Mar 2002 15:21:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07223 for ; Wed, 27 Mar 2002 15:21:51 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20708 for ; Wed, 27 Mar 2002 15:21:49 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKLHI13592; Wed, 27 Mar 2002 12:21:17 -0800 (PST) Message-ID: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , "George Tsirtsis" , "'Hesham Soliman \\\(ERA\\\)'" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 12:19:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Ajoy, You are right, CAR discovery won't be needed if the handover is network controlled. It will only be needed if the handover is mobile controlled, and it is really most needed for intertechnology handover. If the handover is network controlled, the Layer 2 protocol basically knows where the MN is going, since it is determined by power levels, and the MN gets moved. That's one reason why I am having a hard time understanding why people want anything at all in the requirements about network controlled handover. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'James Kempf'" ; "George Tsirtsis" ; "'Hesham Soliman \(ERA\)'" ; Sent: Wednesday, March 27, 2002 10:58 AM Subject: RE: [Seamoby] Examples of CAR discovery > Hello James, > I have not been actively involved in CAR discussion, but > I am not sure how MN controlled CAR will really work when L2 handover > is controlled by network. I do agree that in case of > inter-technology or Mobile controlled handover, MN is the right > candidate to select AR. But mostly in cellular where network controlled > handover is used, I don't see how MN can select CAR. Won't > there be inconsistency in L2 and L3 decision? Probably I might > have missed some important discussion. > regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 27, 2002 12:42 PM > To: George Tsirtsis; 'Hesham Soliman \(ERA\)'; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hesham, > > I agree with your comment about passing preferences to the AR. It won't > scale. > > Actually, I would prefer to avoid any mention of AR based discovery in > the requirements. To me, this is an implementation issue. I would like > the requirements to clearly state that the MN is in charge. If it turns > out that a network based implemention makes some sense, then it can be > considered during the protocol design. > > This was the message I took away from Steve's talk. > > jak > > ----- Original Message ----- > From: "George Tsirtsis" > To: "'Hesham Soliman (ERA)'" ; > > Sent: Wednesday, March 27, 2002 9:01 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > For what is worth I am in full agreement with what Hesham is saying > below > > about the scope of this. > > > > George > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, March 27, 2002 4:53 PM > > To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); seamoby@ietf.org > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > .... > > => I'll let you come up with the new text, but > > my curent concerns on the requirement is: > > > > - The scope of AR-based CAR should be limited > > to one operator's domain and one access technology. > > > > - The MN-based one is naturally limited by the number > > of ARs it can hear. > > > > FWIW, I don't think that passing preferences to > > the AR is a good idea or will ever scale. > > > > Hesham > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 16:26:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24594 for ; Wed, 27 Mar 2002 16:26:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14113; Wed, 27 Mar 2002 16:23:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14082 for ; Wed, 27 Mar 2002 16:23:29 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24328 for ; Wed, 27 Mar 2002 16:23:22 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RLMnI15891; Wed, 27 Mar 2002 13:22:49 -0800 (PST) Message-ID: <03ef01c1d5d5$52599f00$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 13:21:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, Good, looks like we are making progress. > [DOT] Just to make some progress on this issue, may I propose the following wording: > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. The information provision > MUST/SHOULD avoid the transmission of unnecessary information. > > [DOT] Does this accomplish your efficiency statement? > I still think we need a network efficiency requirement. For example, a protocol that multicasts once a second may be finding necessary information, but it sure isn't network efficient. How about: 3.4 The CAR discovery protocol MUST provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST make efficient use of the network bandwidth and SHOULD avoid the transmission of unnecessary information. This puts both aspects of efficiency in one statement. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:26:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24603 for ; Wed, 27 Mar 2002 16:26:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14236 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 16:26:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14113; Wed, 27 Mar 2002 16:23:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14082 for ; Wed, 27 Mar 2002 16:23:29 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24328 for ; Wed, 27 Mar 2002 16:23:22 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RLMnI15891; Wed, 27 Mar 2002 13:22:49 -0800 (PST) Message-ID: <03ef01c1d5d5$52599f00$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 13:21:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, Good, looks like we are making progress. > [DOT] Just to make some progress on this issue, may I propose the following wording: > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. The information provision > MUST/SHOULD avoid the transmission of unnecessary information. > > [DOT] Does this accomplish your efficiency statement? > I still think we need a network efficiency requirement. For example, a protocol that multicasts once a second may be finding necessary information, but it sure isn't network efficient. How about: 3.4 The CAR discovery protocol MUST provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST make efficient use of the network bandwidth and SHOULD avoid the transmission of unnecessary information. This puts both aspects of efficiency in one statement. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:28:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21830 for ; Wed, 27 Mar 2002 15:42:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09317 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:42:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09181; Wed, 27 Mar 2002 15:40:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09147 for ; Wed, 27 Mar 2002 15:40:33 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21769 for ; Wed, 27 Mar 2002 15:40:31 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKdwI14290; Wed, 27 Mar 2002 12:39:58 -0800 (PST) Message-ID: <037b01c1d5cf$55bcd5f0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 12:38:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dirk, This is solution space. Without examining this in detail, we can't say. The intent of the requirements is to constrain the solution through high level goals, not specify them in detail. The information could be handled by a 16 bit bit vector, or it could require an ASN.1 LDAP query, we cannot say at this point. That's why I and others think that we need to clearly state that the MN gets the information it needs. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, March 27, 2002 11:39 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > > Govind, > > We have to think about what the requirement is intending to accomplish. > If we don't mention that, then the requirement becomes meaningless. The > intent is to get the MN the information it needs to select the next AR. > Thus, I believe we must mention the MN. > > [DOT] But isn't that the disagreement, namely the amount of information > the MN needs to select? Assuming that MN could, by any means, connect/handover > to x ARs, does it really mean that the MN has to get the entire information > of all these x ARs? What if only y ARs satify the MN's requirements? It still > sufficient (and even MN-controlled) to choose out of these y since the other > ones are worthless. > > Dirk > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 16:43:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21925 for ; Wed, 27 Mar 2002 15:44:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09389 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 15:44:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09263; Wed, 27 Mar 2002 15:41:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09235 for ; Wed, 27 Mar 2002 15:41:37 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21796 for ; Wed, 27 Mar 2002 15:41:34 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKf6I14334; Wed, 27 Mar 2002 12:41:06 -0800 (PST) Message-ID: <038101c1d5cf$7e53c410$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 27 Mar 2002 12:39:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, Because this is a solution, not a requirement. The requirement is that the MN get the information it needs. How that is implemented is up to the protocol. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 11:36 AM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > James, > I agree that an incompletely stated requirement is meaningless. > > But I just don't seem to understand why you claim that an AR based scheme > which can take the MN's requirement totally into consideration cannot do the > job which you illustrate? Note that I have never > said what you propose is not feasible but the feasibility of what I propose > is also true. Can't we have a happy medium? :) > > Thanks, > -Govind. > > > > > >Govind, > > > >We have to think about what the requirement is intending to accomplish. > >If we don't mention that, then the requirement becomes meaningless. The > >intent is to get the MN the information it needs to select the next AR. > >Thus, I believe we must mention the MN. > > > > jak > > > >----- Original Message ----- > >From: "Govind Krishnamurthi" > >To: > >Sent: Wednesday, March 27, 2002 10:03 AM > >Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement > >(was: Examples of > > > > > > > James, > > > > > > >Here's the requirement: > > > > > > > > The other fundamental function of CAR discovery protocols is > >that of > > > > identifying the capabilities of GAARs. The protocol MUST provide > > > > functionality to allow ARs to discover their GAAR's > >capabilities. > > > >These > > > > capabilities MUST be communicated in a secure fashion. > > > > > > > >There is not one single mention of the MN in this requirement. > > > > > > > >How can you interpret that this requirement does NOT put the AR in > > > >control? This is exactly the message Steve Deering was trying to get > > > >across in the Minne-apple. > > > > > > [Govind] There is a bias and I agree that the bias should be removed. > > > > > > But > > > what you are suggesting is to swing the pendulum to the opposite end > > > putting an MN bias. We should work toward an un-biased set of > >requirements, > > > IMHO, and thats what I will endeavor to do based on the discussions in > >the > > > mailing list. > > > > > > Regards, > > > Govind. > > > > > > > > > _________________________________________________________________ > > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 17:14:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27028 for ; Wed, 27 Mar 2002 17:14:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18458; Wed, 27 Mar 2002 17:08:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18429 for ; Wed, 27 Mar 2002 17:08:13 -0500 (EST) Received: from hotmail.com (f225.law7.hotmail.com [216.33.237.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26879 for ; Wed, 27 Mar 2002 17:08:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 14:07:36 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 22:07:36 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 22:07:36 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 22:07:36.0771 (UTC) FILETIME=[CDA3E930:01C1D5DB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Count me on the agreement side for the requirement you have proposed as 3.4 and 3.x. I don't mean to nitpick, but one small thing. Can we say network "resources" instead of "bandwidth". Resources will include MN power too, as MN is a part of network anyway. But, I don't mean to stimulate discussion on this issue. We can move along without that if you think this is too much attention to detail. BR, Hemant ----------------------------------snip------------------------------- > >How about: > > 3.4 The CAR discovery protocol MUST provide the MN with GAAR >information along with capabilities. > > 3.x The CAR discovery protocol MUST make efficient use of the >network bandwidth and SHOULD avoid the transmission of unnecessary >information. > >This puts both aspects of efficiency in one statement. > > jak > --------------------------------------------------------------------- > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 17:14:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27037 for ; Wed, 27 Mar 2002 17:14:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18924 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 17:14:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18458; Wed, 27 Mar 2002 17:08:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18429 for ; Wed, 27 Mar 2002 17:08:13 -0500 (EST) Received: from hotmail.com (f225.law7.hotmail.com [216.33.237.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26879 for ; Wed, 27 Mar 2002 17:08:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 14:07:36 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 22:07:36 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 22:07:36 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 22:07:36.0771 (UTC) FILETIME=[CDA3E930:01C1D5DB] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi James: Count me on the agreement side for the requirement you have proposed as 3.4 and 3.x. I don't mean to nitpick, but one small thing. Can we say network "resources" instead of "bandwidth". Resources will include MN power too, as MN is a part of network anyway. But, I don't mean to stimulate discussion on this issue. We can move along without that if you think this is too much attention to detail. BR, Hemant ----------------------------------snip------------------------------- > >How about: > > 3.4 The CAR discovery protocol MUST provide the MN with GAAR >information along with capabilities. > > 3.x The CAR discovery protocol MUST make efficient use of the >network bandwidth and SHOULD avoid the transmission of unnecessary >information. > >This puts both aspects of efficiency in one statement. > > jak > --------------------------------------------------------------------- > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 17:20:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27223 for ; Wed, 27 Mar 2002 17:20:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19244; Wed, 27 Mar 2002 17:17:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19217 for ; Wed, 27 Mar 2002 17:17:51 -0500 (EST) Received: from hotmail.com (f242.law9.hotmail.com [64.4.9.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27139 for ; Wed, 27 Mar 2002 17:17:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 14:17:20 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 22:17:20 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 17:17:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 22:17:20.0938 (UTC) FILETIME=[29D4B8A0:01C1D5DD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello all, If this is settled, I will incorporate these changes into the requirement draft. Thanks, Govind. >Hi James: > >Count me on the agreement side for the requirement you have proposed as 3.4 >and 3.x. > >I don't mean to nitpick, but one small thing. Can we say network >"resources" >instead of "bandwidth". Resources will include MN power too, as MN is a >part >of network anyway. But, I don't mean to stimulate discussion on this issue. >We can move along without that if you think this is too much attention to >detail. > >BR, >Hemant > >----------------------------------snip------------------------------- > >> >>How about: >> >> 3.4 The CAR discovery protocol MUST provide the MN with GAAR >>information along with capabilities. >> >> 3.x The CAR discovery protocol MUST make efficient use of the >>network bandwidth and SHOULD avoid the transmission of unnecessary >>information. >> >>This puts both aspects of efficiency in one statement. >> >> jak >> >--------------------------------------------------------------------- > > > >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world?s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 17:20:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27233 for ; Wed, 27 Mar 2002 17:20:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19425 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 17:20:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19244; Wed, 27 Mar 2002 17:17:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19217 for ; Wed, 27 Mar 2002 17:17:51 -0500 (EST) Received: from hotmail.com (f242.law9.hotmail.com [64.4.9.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27139 for ; Wed, 27 Mar 2002 17:17:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 14:17:20 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 27 Mar 2002 22:17:20 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 17:17:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2002 22:17:20.0938 (UTC) FILETIME=[29D4B8A0:01C1D5DD] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello all, If this is settled, I will incorporate these changes into the requirement draft. Thanks, Govind. >Hi James: > >Count me on the agreement side for the requirement you have proposed as 3.4 >and 3.x. > >I don't mean to nitpick, but one small thing. Can we say network >"resources" >instead of "bandwidth". Resources will include MN power too, as MN is a >part >of network anyway. But, I don't mean to stimulate discussion on this issue. >We can move along without that if you think this is too much attention to >detail. > >BR, >Hemant > >----------------------------------snip------------------------------- > >> >>How about: >> >> 3.4 The CAR discovery protocol MUST provide the MN with GAAR >>information along with capabilities. >> >> 3.x The CAR discovery protocol MUST make efficient use of the >>network bandwidth and SHOULD avoid the transmission of unnecessary >>information. >> >>This puts both aspects of efficiency in one statement. >> >> jak >> >--------------------------------------------------------------------- > > > >> >>_______________________________________________ >>Seamoby mailing list >>Seamoby@ietf.org >>https://www1.ietf.org/mailman/listinfo/seamoby > > >_________________________________________________________________ >Join the world?s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 18:27:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29341 for ; Wed, 27 Mar 2002 18:27:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23950; Wed, 27 Mar 2002 18:18:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23924 for ; Wed, 27 Mar 2002 18:18:34 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29120 for ; Wed, 27 Mar 2002 18:18:30 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA24597 for ; Wed, 27 Mar 2002 15:18:02 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2RNI1V06748 for ; Wed, 27 Mar 2002 15:18:01 -0800 X-mProtect:  Wed, 27 Mar 2002 15:18:01 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.20.249, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdblgg1q; Wed, 27 Mar 2002 15:17:46 PST Message-ID: <3CA25303.B4585FC3@iprg.nokia.com> Date: Wed, 27 Mar 2002 15:17:23 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello, I am a lurker only, but occasionally I read the messages in this thread. If somehow things have progressed past my original understanding, I'd like to find that out. So, a question: James Kempf wrote: > Ajoy, > > You are right, CAR discovery won't be needed if the handover is network > controlled. It will only be needed if the handover is mobile controlled, > and it is really most needed for intertechnology handover. Does this mean that the access points themselves cannot use CAR to prepare for a network-controlled handover? Darn ...! > If the handover is network controlled, the Layer 2 protocol basically > knows > where the MN is going, since it is determined by power levels, and the > MN gets moved. Handover can be controlled by things other than power levels! As someone noted, it would be better to frame handover considerations more general "resource consumption" requirements... Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 18:27:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29351 for ; Wed, 27 Mar 2002 18:27:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24344 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 18:27:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23950; Wed, 27 Mar 2002 18:18:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23924 for ; Wed, 27 Mar 2002 18:18:34 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29120 for ; Wed, 27 Mar 2002 18:18:30 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA24597 for ; Wed, 27 Mar 2002 15:18:02 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2RNI1V06748 for ; Wed, 27 Mar 2002 15:18:01 -0800 X-mProtect:  Wed, 27 Mar 2002 15:18:01 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.20.249, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdblgg1q; Wed, 27 Mar 2002 15:17:46 PST Message-ID: <3CA25303.B4585FC3@iprg.nokia.com> Date: Wed, 27 Mar 2002 15:17:23 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello, I am a lurker only, but occasionally I read the messages in this thread. If somehow things have progressed past my original understanding, I'd like to find that out. So, a question: James Kempf wrote: > Ajoy, > > You are right, CAR discovery won't be needed if the handover is network > controlled. It will only be needed if the handover is mobile controlled, > and it is really most needed for intertechnology handover. Does this mean that the access points themselves cannot use CAR to prepare for a network-controlled handover? Darn ...! > If the handover is network controlled, the Layer 2 protocol basically > knows > where the MN is going, since it is determined by power levels, and the > MN gets moved. Handover can be controlled by things other than power levels! As someone noted, it would be better to frame handover considerations more general "resource consumption" requirements... Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 18:30:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29416 for ; Wed, 27 Mar 2002 18:30:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24176; Wed, 27 Mar 2002 18:22:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24151 for ; Wed, 27 Mar 2002 18:22:17 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29201 for ; Wed, 27 Mar 2002 18:22:13 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id AAA00961; Thu, 28 Mar 2002 00:19:05 +0100 From: "Henrik Levkowetz" To: "James Kempf" , Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Thu, 28 Mar 2002 00:21:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <03ef01c1d5d5$52599f00$7e6015ac@T23KEMPF> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James wrote: > I still think we need a network efficiency requirement. For example, a > protocol that multicasts once a second may be finding necessary > information, but it sure isn't network efficient. > > How about: > > 3.4 The CAR discovery protocol MUST provide the MN with GAAR > information along with capabilities. > > 3.x The CAR discovery protocol MUST make efficient use of the > network bandwidth and SHOULD avoid the transmission of unnecessary > information. > > This puts both aspects of efficiency in one statement. This looks good to me. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 18:30:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29442 for ; Wed, 27 Mar 2002 18:30:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24696 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 18:30:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24176; Wed, 27 Mar 2002 18:22:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24151 for ; Wed, 27 Mar 2002 18:22:17 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29201 for ; Wed, 27 Mar 2002 18:22:13 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id AAA00961; Thu, 28 Mar 2002 00:19:05 +0100 From: "Henrik Levkowetz" To: "James Kempf" , Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Thu, 28 Mar 2002 00:21:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <03ef01c1d5d5$52599f00$7e6015ac@T23KEMPF> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit James wrote: > I still think we need a network efficiency requirement. For example, a > protocol that multicasts once a second may be finding necessary > information, but it sure isn't network efficient. > > How about: > > 3.4 The CAR discovery protocol MUST provide the MN with GAAR > information along with capabilities. > > 3.x The CAR discovery protocol MUST make efficient use of the > network bandwidth and SHOULD avoid the transmission of unnecessary > information. > > This puts both aspects of efficiency in one statement. This looks good to me. Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 18:34:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29510 for ; Wed, 27 Mar 2002 18:34:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24874; Wed, 27 Mar 2002 18:31:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24836 for ; Wed, 27 Mar 2002 18:31:05 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29488 for ; Wed, 27 Mar 2002 18:31:02 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RNURI20164; Wed, 27 Mar 2002 15:30:27 -0800 (PST) Message-ID: <047a01c1d5e7$26ec3320$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 15:28:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, I would say "provisionally." The Europeans are off line at the moment, so we may see some traffic tomorrow when they are back up. I will post these under a separate heading. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 2:17 PM Subject: Re: [Seamoby] MN in charge: What does this mean? > > > > Hello all, > If this is settled, I will incorporate these changes into > the requirement draft. > > Thanks, > Govind. > > >Hi James: > > > >Count me on the agreement side for the requirement you have proposed as 3.4 > >and 3.x. > > > >I don't mean to nitpick, but one small thing. Can we say network > >"resources" > >instead of "bandwidth". Resources will include MN power too, as MN is a > >part > >of network anyway. But, I don't mean to stimulate discussion on this issue. > >We can move along without that if you think this is too much attention to > >detail. > > > >BR, > >Hemant > > > >----------------------------------snip------------------------------- > > > >> > >>How about: > >> > >> 3.4 The CAR discovery protocol MUST provide the MN with GAAR > >>information along with capabilities. > >> > >> 3.x The CAR discovery protocol MUST make efficient use of the > >>network bandwidth and SHOULD avoid the transmission of unnecessary > >>information. > >> > >>This puts both aspects of efficiency in one statement. > >> > >> jak > >> > >--------------------------------------------------------------------- > > > > > > > >> > >>_______________________________________________ > >>Seamoby mailing list > >>Seamoby@ietf.org > >>https://www1.ietf.org/mailman/listinfo/seamoby > > > > > >_________________________________________________________________ > >Join the world?s largest e-mail service with MSN Hotmail. > >http://www.hotmail.com > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 18:34:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29519 for ; Wed, 27 Mar 2002 18:34:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25106 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 18:34:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24874; Wed, 27 Mar 2002 18:31:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24836 for ; Wed, 27 Mar 2002 18:31:05 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29488 for ; Wed, 27 Mar 2002 18:31:02 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RNURI20164; Wed, 27 Mar 2002 15:30:27 -0800 (PST) Message-ID: <047a01c1d5e7$26ec3320$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] MN in charge: What does this mean? Date: Wed, 27 Mar 2002 15:28:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Govind, I would say "provisionally." The Europeans are off line at the moment, so we may see some traffic tomorrow when they are back up. I will post these under a separate heading. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 2:17 PM Subject: Re: [Seamoby] MN in charge: What does this mean? > > > > Hello all, > If this is settled, I will incorporate these changes into > the requirement draft. > > Thanks, > Govind. > > >Hi James: > > > >Count me on the agreement side for the requirement you have proposed as 3.4 > >and 3.x. > > > >I don't mean to nitpick, but one small thing. Can we say network > >"resources" > >instead of "bandwidth". Resources will include MN power too, as MN is a > >part > >of network anyway. But, I don't mean to stimulate discussion on this issue. > >We can move along without that if you think this is too much attention to > >detail. > > > >BR, > >Hemant > > > >----------------------------------snip------------------------------- > > > >> > >>How about: > >> > >> 3.4 The CAR discovery protocol MUST provide the MN with GAAR > >>information along with capabilities. > >> > >> 3.x The CAR discovery protocol MUST make efficient use of the > >>network bandwidth and SHOULD avoid the transmission of unnecessary > >>information. > >> > >>This puts both aspects of efficiency in one statement. > >> > >> jak > >> > >--------------------------------------------------------------------- > > > > > > > >> > >>_______________________________________________ > >>Seamoby mailing list > >>Seamoby@ietf.org > >>https://www1.ietf.org/mailman/listinfo/seamoby > > > > > >_________________________________________________________________ > >Join the world?s largest e-mail service with MSN Hotmail. > >http://www.hotmail.com > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 18:40:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29607 for ; Wed, 27 Mar 2002 18:40:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25080; Wed, 27 Mar 2002 18:33:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25045 for ; Wed, 27 Mar 2002 18:33:05 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29500 for ; Wed, 27 Mar 2002 18:33:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RNWYI20281 for ; Wed, 27 Mar 2002 15:32:34 -0800 (PST) Message-ID: <048201c1d5e7$727f1fa0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 27 Mar 2002 15:30:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Debate Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, So after debating these issues, I believe we have agreement on the following requirements: 3.4 The CAR discovery protocol MUST provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST make efficient use of the network resources and SHOULD avoid the transmission of unnecessary information. If there are no objections, Govind will incorporate these into an update of the requirements draft. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 18:40:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29618 for ; Wed, 27 Mar 2002 18:40:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25392 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 18:40:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25080; Wed, 27 Mar 2002 18:33:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25045 for ; Wed, 27 Mar 2002 18:33:05 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29500 for ; Wed, 27 Mar 2002 18:33:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RNWYI20281 for ; Wed, 27 Mar 2002 15:32:34 -0800 (PST) Message-ID: <048201c1d5e7$727f1fa0$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Wed, 27 Mar 2002 15:30:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Debate Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Folks, So after debating these issues, I believe we have agreement on the following requirements: 3.4 The CAR discovery protocol MUST provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST make efficient use of the network resources and SHOULD avoid the transmission of unnecessary information. If there are no objections, Govind will incorporate these into an update of the requirements draft. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 18:44:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29758 for ; Wed, 27 Mar 2002 18:44:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25449; Wed, 27 Mar 2002 18:42:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25424 for ; Wed, 27 Mar 2002 18:42:08 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29697 for ; Wed, 27 Mar 2002 18:42:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RNfNI20600; Wed, 27 Mar 2002 15:41:23 -0800 (PST) Message-ID: <04be01c1d5e8$ad804c40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" , References: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> <3CA25303.B4585FC3@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 15:39:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Charlie, > > You are right, CAR discovery won't be needed if the handover is network > > controlled. It will only be needed if the handover is mobile controlled, > > and it is really most needed for intertechnology handover. > > Does this mean that the access points themselves cannot use CAR to > prepare for a network-controlled handover? Darn ...! > They can, but in a typical cellular system, they won't. The access points don't move around much, so this can be preprogrammed into tables. > > > If the handover is network controlled, the Layer 2 protocol basically > > knows > > where the MN is going, since it is determined by power levels, and the > > MN gets moved. > > Handover can be controlled by things other than power levels! > As someone noted, it would be better to frame handover considerations > more general "resource consumption" requirements... > Creative, new Layer 2 solutions are always possible, of course. I was speaking about how it typically works in existing cellular systems. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 18:44:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29767 for ; Wed, 27 Mar 2002 18:44:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25607 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 18:44:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25449; Wed, 27 Mar 2002 18:42:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25424 for ; Wed, 27 Mar 2002 18:42:08 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29697 for ; Wed, 27 Mar 2002 18:42:01 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RNfNI20600; Wed, 27 Mar 2002 15:41:23 -0800 (PST) Message-ID: <04be01c1d5e8$ad804c40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" , References: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> <3CA25303.B4585FC3@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 27 Mar 2002 15:39:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Charlie, > > You are right, CAR discovery won't be needed if the handover is network > > controlled. It will only be needed if the handover is mobile controlled, > > and it is really most needed for intertechnology handover. > > Does this mean that the access points themselves cannot use CAR to > prepare for a network-controlled handover? Darn ...! > They can, but in a typical cellular system, they won't. The access points don't move around much, so this can be preprogrammed into tables. > > > If the handover is network controlled, the Layer 2 protocol basically > > knows > > where the MN is going, since it is determined by power levels, and the > > MN gets moved. > > Handover can be controlled by things other than power levels! > As someone noted, it would be better to frame handover considerations > more general "resource consumption" requirements... > Creative, new Layer 2 solutions are always possible, of course. I was speaking about how it typically works in existing cellular systems. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 23:34:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06584 for ; Wed, 27 Mar 2002 23:34:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09080; Wed, 27 Mar 2002 23:32:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09051 for ; Wed, 27 Mar 2002 23:32:04 -0500 (EST) Received: from hotmail.com (oe16.law4.hotmail.com [216.33.148.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06565 for ; Wed, 27 Mar 2002 23:32:02 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 20:31:34 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 13:36:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 04:31:34.0268 (UTC) FILETIME=[710EFBC0:01C1D611] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, My comment in inline. Thanks. Eunsoo ----- Original Message ----- From: To: ; Sent: Wednesday, March 27, 2002 11:01 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > Henrik, > > Govind wrote: > > [Govind] There is a bias and I agree that the bias should be removed. > > > > But > > what you are suggesting is to swing the pendulum to the opposite end > > putting an MN bias. We should work toward an un-biased set of requirements, > > IMHO, and thats what I will endeavor to do based on the discussions in the > > mailing list. > > Yes, yes! > > That is what we are suggesting! That there *needs* to be a bias > towards the MN, that whatever we design which does not give this to the > MN will not provide the User with what he wants and needs, and ultimately won't > be deployed and used. > > [DOT] Does this necessarily mean that the MN has to do the job entirely? Giving > the control of the handover decision to the MN and providing information to do > so through assistance of the network, is a different thing. > > I thought Steve was so clear in Minneapolis, and the case so clear as > well, that I did not expect this resistance. > > [DOT] This is open to interpretation since everybody got his/her own impression. > I did also take away from this presentation that it indeed makes sense to use information > and functionality from the network to do the CAR discovery. I did not understand Steve's > talk in a way that EVERYTHING has to be MN-based. > > [DOT] Another point is that we should not take Steve's talk and its interpretation by > WG members as the final mandate for the definition of requirements. His presentation > certainly stimulated the discussion, and that is good since we made progress in > addressing certain things. But just pointing to interpretations of this talk to justify > requirements and their sense is not enough for me. We still have to have a discussion > and a WG consensus about this work. > [eunsoo] I'd like back this opinion. I remember that it was said that the discussion on the mailing list should play a critical role in the IETF. I am not saying we should ignore what has been discussed in the meetings. But I'd like to point out that there are many people who could not attend the meeting and thus did not hear the presentation. > Regards, > > > Dirk > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 23:34:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06593 for ; Wed, 27 Mar 2002 23:34:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA09148 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 23:34:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09080; Wed, 27 Mar 2002 23:32:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09051 for ; Wed, 27 Mar 2002 23:32:04 -0500 (EST) Received: from hotmail.com (oe16.law4.hotmail.com [216.33.148.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06565 for ; Wed, 27 Mar 2002 23:32:02 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 20:31:34 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: , , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 13:36:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 04:31:34.0268 (UTC) FILETIME=[710EFBC0:01C1D611] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi, My comment in inline. Thanks. Eunsoo ----- Original Message ----- From: To: ; Sent: Wednesday, March 27, 2002 11:01 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > Henrik, > > Govind wrote: > > [Govind] There is a bias and I agree that the bias should be removed. > > > > But > > what you are suggesting is to swing the pendulum to the opposite end > > putting an MN bias. We should work toward an un-biased set of requirements, > > IMHO, and thats what I will endeavor to do based on the discussions in the > > mailing list. > > Yes, yes! > > That is what we are suggesting! That there *needs* to be a bias > towards the MN, that whatever we design which does not give this to the > MN will not provide the User with what he wants and needs, and ultimately won't > be deployed and used. > > [DOT] Does this necessarily mean that the MN has to do the job entirely? Giving > the control of the handover decision to the MN and providing information to do > so through assistance of the network, is a different thing. > > I thought Steve was so clear in Minneapolis, and the case so clear as > well, that I did not expect this resistance. > > [DOT] This is open to interpretation since everybody got his/her own impression. > I did also take away from this presentation that it indeed makes sense to use information > and functionality from the network to do the CAR discovery. I did not understand Steve's > talk in a way that EVERYTHING has to be MN-based. > > [DOT] Another point is that we should not take Steve's talk and its interpretation by > WG members as the final mandate for the definition of requirements. His presentation > certainly stimulated the discussion, and that is good since we made progress in > addressing certain things. But just pointing to interpretations of this talk to justify > requirements and their sense is not enough for me. We still have to have a discussion > and a WG consensus about this work. > [eunsoo] I'd like back this opinion. I remember that it was said that the discussion on the mailing list should play a critical role in the IETF. I am not saying we should ignore what has been discussed in the meetings. But I'd like to point out that there are many people who could not attend the meeting and thus did not hear the presentation. > Regards, > > > Dirk > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Mar 27 23:51:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06834 for ; Wed, 27 Mar 2002 23:51:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09337; Wed, 27 Mar 2002 23:45:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09309 for ; Wed, 27 Mar 2002 23:45:37 -0500 (EST) Received: from hotmail.com (oe39.law4.hotmail.com [216.33.148.76]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06779 for ; Wed, 27 Mar 2002 23:45:34 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 20:45:06 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Thu, 28 Mar 2002 13:50:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 04:45:06.0974 (UTC) FILETIME=[557813E0:01C1D613] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 10:10 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of > Hesham, > > >- I always said, limit it to the same operator > >and the same access technology. I didn't say > >one or two. I said it is unlikely to get more > >than two if you apply the limitation above. > >I might be wrong and more than happy to hear > >that, but the discussion seems to be going towards > >picking words rather than picking technical reasons. > > > [Govind] Well this is new. Iam curious :) > Intertechnology part is a MUST and it was deemed an > uncontroversial requirement in MPLS and put towards the end > of the presentation as this requirement did not raise ANY > discussion prior to MPLS and even prior to today. > If you had an objection > always, why did you not raise any objection at MPLS? Nor > did you raise any in our quite extensive discussions in GPRS to WLAN > handovers. > [eunsoo] I agree that the inter-technology part is a MUST. I'd like to remind us again that one of the important results of CAR discovery is mapping of L2 ID to IP address of the GAAR/CARs for fast handoff. And obviously we know that the mapping information better be available before the MN can hear the target AR. And we want fast handoff even for inter-domain handoffs. So I believe CAR discovery should be applied to the inter-domain case as well. And I believe we had many statements about benefits of doing CAR discovery for the inter-technology case, which is that the MN can save power if it can get the information without actively communicating with the ARs which are NOT the one the MN is attached to. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Mar 27 23:51:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06843 for ; Wed, 27 Mar 2002 23:51:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA09460 for seamoby-archive@odin.ietf.org; Wed, 27 Mar 2002 23:51:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09337; Wed, 27 Mar 2002 23:45:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09309 for ; Wed, 27 Mar 2002 23:45:37 -0500 (EST) Received: from hotmail.com (oe39.law4.hotmail.com [216.33.148.76]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06779 for ; Wed, 27 Mar 2002 23:45:34 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 20:45:06 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Thu, 28 Mar 2002 13:50:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 04:45:06.0974 (UTC) FILETIME=[557813E0:01C1D613] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Wednesday, March 27, 2002 10:10 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of > Hesham, > > >- I always said, limit it to the same operator > >and the same access technology. I didn't say > >one or two. I said it is unlikely to get more > >than two if you apply the limitation above. > >I might be wrong and more than happy to hear > >that, but the discussion seems to be going towards > >picking words rather than picking technical reasons. > > > [Govind] Well this is new. Iam curious :) > Intertechnology part is a MUST and it was deemed an > uncontroversial requirement in MPLS and put towards the end > of the presentation as this requirement did not raise ANY > discussion prior to MPLS and even prior to today. > If you had an objection > always, why did you not raise any objection at MPLS? Nor > did you raise any in our quite extensive discussions in GPRS to WLAN > handovers. > [eunsoo] I agree that the inter-technology part is a MUST. I'd like to remind us again that one of the important results of CAR discovery is mapping of L2 ID to IP address of the GAAR/CARs for fast handoff. And obviously we know that the mapping information better be available before the MN can hear the target AR. And we want fast handoff even for inter-domain handoffs. So I believe CAR discovery should be applied to the inter-domain case as well. And I believe we had many statements about benefits of doing CAR discovery for the inter-technology case, which is that the MN can save power if it can get the information without actively communicating with the ARs which are NOT the one the MN is attached to. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 02:53:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17564 for ; Thu, 28 Mar 2002 02:53:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27458; Thu, 28 Mar 2002 02:49:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27426 for ; Thu, 28 Mar 2002 02:49:45 -0500 (EST) Received: from hotmail.com (oe55.law4.hotmail.com [216.33.148.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17536 for ; Thu, 28 Mar 2002 02:49:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 23:49:15 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Thu, 28 Mar 2002 16:54:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 07:49:15.0134 (UTC) FILETIME=[0EAF81E0:01C1D62D] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I added clarification of one statement in my previous email. Thanks. Eunsoo ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Thursday, March 28, 2002 1:50 PM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of > > ----- Original Message ----- > From: "Govind Krishnamurthi" > To: > Sent: Wednesday, March 27, 2002 10:10 AM > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa > s: Examples of > > > > Hesham, > > > > >- I always said, limit it to the same operator > > >and the same access technology. I didn't say > > >one or two. I said it is unlikely to get more > > >than two if you apply the limitation above. > > >I might be wrong and more than happy to hear > > >that, but the discussion seems to be going towards > > >picking words rather than picking technical reasons. > > > > > > [Govind] Well this is new. Iam curious :) > > Intertechnology part is a MUST and it was deemed an > > uncontroversial requirement in MPLS and put towards the end > > of the presentation as this requirement did not raise ANY > > discussion prior to MPLS and even prior to today. > > If you had an objection > > always, why did you not raise any objection at MPLS? Nor > > did you raise any in our quite extensive discussions in GPRS to WLAN > > handovers. > > > [eunsoo] I agree that the inter-technology part is a MUST. I'd like to > remind us again that one of the important results of CAR discovery is > mapping of L2 ID to IP address of the GAAR/CARs for fast handoff. And > obviously we know that the mapping information better be available before > the MN can hear the target AR. And we want fast handoff even for > inter-domain handoffs. So I believe CAR discovery should be applied to the > inter-domain case as well. [eunsoo] One clarification. I meant "before the MN can communicate with the target AR" by "before the MN can hear the target AR". Certainly we need the mapping information when the MN can receive L2 beacons of the base station associated with the target AR. > And I believe we had many statements about benefits of doing CAR discovery > for the inter-technology case, which is that the MN can save power if it can > get the information without actively communicating with the ARs which are > NOT the one the MN is attached to. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 02:53:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17578 for ; Thu, 28 Mar 2002 02:53:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA27518 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 02:53:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27458; Thu, 28 Mar 2002 02:49:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27426 for ; Thu, 28 Mar 2002 02:49:45 -0500 (EST) Received: from hotmail.com (oe55.law4.hotmail.com [216.33.148.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17536 for ; Thu, 28 Mar 2002 02:49:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Mar 2002 23:49:15 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of Date: Thu, 28 Mar 2002 16:54:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 07:49:15.0134 (UTC) FILETIME=[0EAF81E0:01C1D62D] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit I added clarification of one statement in my previous email. Thanks. Eunsoo ----- Original Message ----- From: "Eunsoo Shim" To: Sent: Thursday, March 28, 2002 1:50 PM Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of > > ----- Original Message ----- > From: "Govind Krishnamurthi" > To: > Sent: Wednesday, March 27, 2002 10:10 AM > Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa > s: Examples of > > > > Hesham, > > > > >- I always said, limit it to the same operator > > >and the same access technology. I didn't say > > >one or two. I said it is unlikely to get more > > >than two if you apply the limitation above. > > >I might be wrong and more than happy to hear > > >that, but the discussion seems to be going towards > > >picking words rather than picking technical reasons. > > > > > > [Govind] Well this is new. Iam curious :) > > Intertechnology part is a MUST and it was deemed an > > uncontroversial requirement in MPLS and put towards the end > > of the presentation as this requirement did not raise ANY > > discussion prior to MPLS and even prior to today. > > If you had an objection > > always, why did you not raise any objection at MPLS? Nor > > did you raise any in our quite extensive discussions in GPRS to WLAN > > handovers. > > > [eunsoo] I agree that the inter-technology part is a MUST. I'd like to > remind us again that one of the important results of CAR discovery is > mapping of L2 ID to IP address of the GAAR/CARs for fast handoff. And > obviously we know that the mapping information better be available before > the MN can hear the target AR. And we want fast handoff even for > inter-domain handoffs. So I believe CAR discovery should be applied to the > inter-domain case as well. [eunsoo] One clarification. I meant "before the MN can communicate with the target AR" by "before the MN can hear the target AR". Certainly we need the mapping information when the MN can receive L2 beacons of the base station associated with the target AR. > And I believe we had many statements about benefits of doing CAR discovery > for the inter-technology case, which is that the MN can save power if it can > get the information without actively communicating with the ARs which are > NOT the one the MN is attached to. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 03:19:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18332 for ; Thu, 28 Mar 2002 03:19:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28719; Thu, 28 Mar 2002 03:16:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28692 for ; Thu, 28 Mar 2002 03:16:07 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18228 for ; Thu, 28 Mar 2002 03:16:03 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id JAA07653; Thu, 28 Mar 2002 09:13:08 +0100 From: "Henrik Levkowetz" To: "Eunsoo Shim" , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 09:15:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Eunsoo wrote: > > [DOT] Another point is that we should not take Steve's talk and its > interpretation by > > WG members as the final mandate for the definition of requirements. His > presentation > > certainly stimulated the discussion, and that is good since we made > progress in > > addressing certain things. But just pointing to interpretations of this > talk to justify > > requirements and their sense is not enough for me. We still have to have a > discussion > > and a WG consensus about this work. > > > [eunsoo] I'd like back this opinion. I remember that it was said that the > discussion on the mailing list should play a critical role in the IETF. I am > not saying we should ignore what has been discussed in the meetings. But I'd > like to point out that there are many people who could not attend the > meeting and thus did not hear the presentation. > True. But we also cannot ignore the strong consensus in favour of the points in Steve's presentation. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 03:19:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18355 for ; Thu, 28 Mar 2002 03:19:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA28807 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 03:19:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28719; Thu, 28 Mar 2002 03:16:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28692 for ; Thu, 28 Mar 2002 03:16:07 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18228 for ; Thu, 28 Mar 2002 03:16:03 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id JAA07653; Thu, 28 Mar 2002 09:13:08 +0100 From: "Henrik Levkowetz" To: "Eunsoo Shim" , Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 09:15:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Eunsoo wrote: > > [DOT] Another point is that we should not take Steve's talk and its > interpretation by > > WG members as the final mandate for the definition of requirements. His > presentation > > certainly stimulated the discussion, and that is good since we made > progress in > > addressing certain things. But just pointing to interpretations of this > talk to justify > > requirements and their sense is not enough for me. We still have to have a > discussion > > and a WG consensus about this work. > > > [eunsoo] I'd like back this opinion. I remember that it was said that the > discussion on the mailing list should play a critical role in the IETF. I am > not saying we should ignore what has been discussed in the meetings. But I'd > like to point out that there are many people who could not attend the > meeting and thus did not hear the presentation. > True. But we also cannot ignore the strong consensus in favour of the points in Steve's presentation. Regards, Henrik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 03:29:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18555 for ; Thu, 28 Mar 2002 03:29:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28950; Thu, 28 Mar 2002 03:23:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28921 for ; Thu, 28 Mar 2002 03:22:59 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18453 for ; Thu, 28 Mar 2002 03:22:56 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2S8MCG10359 for ; Thu, 28 Mar 2002 10:22:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Mar 2002 10:22:57 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 10:22:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Thu, 28 Mar 2002 10:22:48 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D2F@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVH/jfymAjlQjLSfiaUUHNqTQyrwBEXMmQ To: , , X-OriginalArrivalTime: 28 Mar 2002 08:22:57.0845 (UTC) FILETIME=[C450B650:01C1D631] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA28922 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, A small suggestion on the requirement > No, that it sends all, along with the capabilities. Let me repeat the > requirement I would like to see (and Henrik apparently > agrees) so we are clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. See the text between the *'s: The CAR discovery protocol MUST *be able to provide* the MN with GAAR information, along with capabilities. I think this might make the requirement acceptable to all parties. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 03:29:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18564 for ; Thu, 28 Mar 2002 03:29:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA29284 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 03:29:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28950; Thu, 28 Mar 2002 03:23:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28921 for ; Thu, 28 Mar 2002 03:22:59 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18453 for ; Thu, 28 Mar 2002 03:22:56 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2S8MCG10359 for ; Thu, 28 Mar 2002 10:22:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Mar 2002 10:22:57 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 10:22:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Thu, 28 Mar 2002 10:22:48 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D2F@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Thread-Index: AcHVH/jfymAjlQjLSfiaUUHNqTQyrwBEXMmQ To: , , X-OriginalArrivalTime: 28 Mar 2002 08:22:57.0845 (UTC) FILETIME=[C450B650:01C1D631] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA28922 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 8bit Hi James, A small suggestion on the requirement > No, that it sends all, along with the capabilities. Let me repeat the > requirement I would like to see (and Henrik apparently > agrees) so we are clear on this: > > The CAR discovery protocol MUST provide the MN with GAAR > information, along with capabilities. See the text between the *'s: The CAR discovery protocol MUST *be able to provide* the MN with GAAR information, along with capabilities. I think this might make the requirement acceptable to all parties. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 03:38:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18705 for ; Thu, 28 Mar 2002 03:38:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29933; Thu, 28 Mar 2002 03:32:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29864 for ; Thu, 28 Mar 2002 03:32:20 -0500 (EST) Received: from hotmail.com (oe19.law4.hotmail.com [216.33.148.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18609 for ; Thu, 28 Mar 2002 03:32:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Mar 2002 00:31:49 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "Henrik Levkowetz" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 17:36:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 08:31:49.0459 (UTC) FILETIME=[012E9230:01C1D633] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Henrik Levkowetz" To: "Eunsoo Shim" ; Sent: Thursday, March 28, 2002 12:15 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > Eunsoo wrote: > > > [DOT] Another point is that we should not take Steve's talk and its > > interpretation by > > > WG members as the final mandate for the definition of requirements. His > > presentation > > > certainly stimulated the discussion, and that is good since we made > > progress in > > > addressing certain things. But just pointing to interpretations of this > > talk to justify > > > requirements and their sense is not enough for me. We still have to have a > > discussion > > > and a WG consensus about this work. > > > > > [eunsoo] I'd like back this opinion. I remember that it was said that the > > discussion on the mailing list should play a critical role in the IETF. I am > > not saying we should ignore what has been discussed in the meetings. But I'd > > like to point out that there are many people who could not attend the > > meeting and thus did not hear the presentation. > > > > True. But we also cannot ignore the strong consensus in favour of the points > in Steve's presentation. > [eunsoo] If the presentation is so influential on our issues, could anyone make it available for the people who did not attend the Minneapolis meeting? > Regards, > Henrik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 03:38:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18714 for ; Thu, 28 Mar 2002 03:38:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00148 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 03:38:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29933; Thu, 28 Mar 2002 03:32:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29864 for ; Thu, 28 Mar 2002 03:32:20 -0500 (EST) Received: from hotmail.com (oe19.law4.hotmail.com [216.33.148.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18609 for ; Thu, 28 Mar 2002 03:32:17 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Mar 2002 00:31:49 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "Henrik Levkowetz" , References: Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 17:36:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 08:31:49.0459 (UTC) FILETIME=[012E9230:01C1D633] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Henrik Levkowetz" To: "Eunsoo Shim" ; Sent: Thursday, March 28, 2002 12:15 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > Eunsoo wrote: > > > [DOT] Another point is that we should not take Steve's talk and its > > interpretation by > > > WG members as the final mandate for the definition of requirements. His > > presentation > > > certainly stimulated the discussion, and that is good since we made > > progress in > > > addressing certain things. But just pointing to interpretations of this > > talk to justify > > > requirements and their sense is not enough for me. We still have to have a > > discussion > > > and a WG consensus about this work. > > > > > [eunsoo] I'd like back this opinion. I remember that it was said that the > > discussion on the mailing list should play a critical role in the IETF. I am > > not saying we should ignore what has been discussed in the meetings. But I'd > > like to point out that there are many people who could not attend the > > meeting and thus did not hear the presentation. > > > > True. But we also cannot ignore the strong consensus in favour of the points > in Steve's presentation. > [eunsoo] If the presentation is so influential on our issues, could anyone make it available for the people who did not attend the Minneapolis meeting? > Regards, > Henrik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 04:06:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19352 for ; Thu, 28 Mar 2002 04:06:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01573; Thu, 28 Mar 2002 04:00:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01536 for ; Thu, 28 Mar 2002 04:00:32 -0500 (EST) Received: from hotmail.com (oe62.law4.hotmail.com [216.33.148.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19272 for ; Thu, 28 Mar 2002 04:00:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Mar 2002 01:00:02 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: , , , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D2F@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Thu, 28 Mar 2002 18:05:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 09:00:02.0009 (UTC) FILETIME=[F2053490:01C1D636] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: ; ; Sent: Thursday, March 28, 2002 12:22 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi James, > > A small suggestion on the requirement > > > No, that it sends all, along with the capabilities. Let me repeat the > > requirement I would like to see (and Henrik apparently > > agrees) so we are clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > See the text between the *'s: > > The CAR discovery protocol MUST *be able to provide* the MN with GAAR > information, along with capabilities. > > I think this might make the requirement acceptable to all parties. > [eunsoo] It is acceptable at least for me. :-) Actually it is good. Thanks. Eunsoo > John > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 04:06:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19361 for ; Thu, 28 Mar 2002 04:06:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02223 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 04:06:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01573; Thu, 28 Mar 2002 04:00:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01536 for ; Thu, 28 Mar 2002 04:00:32 -0500 (EST) Received: from hotmail.com (oe62.law4.hotmail.com [216.33.148.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19272 for ; Thu, 28 Mar 2002 04:00:29 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Mar 2002 01:00:02 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: , , , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D2F@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) Date: Thu, 28 Mar 2002 18:05:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 28 Mar 2002 09:00:02.0009 (UTC) FILETIME=[F2053490:01C1D636] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: ; ; Sent: Thursday, March 28, 2002 12:22 AM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery) > Hi James, > > A small suggestion on the requirement > > > No, that it sends all, along with the capabilities. Let me repeat the > > requirement I would like to see (and Henrik apparently > > agrees) so we are clear on this: > > > > The CAR discovery protocol MUST provide the MN with GAAR > > information, along with capabilities. > > See the text between the *'s: > > The CAR discovery protocol MUST *be able to provide* the MN with GAAR > information, along with capabilities. > > I think this might make the requirement acceptable to all parties. > [eunsoo] It is acceptable at least for me. :-) Actually it is good. Thanks. Eunsoo > John > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 11:55:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05181 for ; Thu, 28 Mar 2002 11:55:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27221; Thu, 28 Mar 2002 11:48:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27193 for ; Thu, 28 Mar 2002 11:48:55 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04615 for ; Thu, 28 Mar 2002 11:48:49 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2SGmq3G005026 for ; Thu, 28 Mar 2002 17:48:52 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 17:48:51 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 17:38:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABCF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Deb ate Date: Thu, 28 Mar 2002 17:48:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Agree Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 28, 2002 12:31 AM > To: seamoby@ietf.org > Subject: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery > Debate > > > Folks, > > So after debating these issues, I believe we have agreement on the > following requirements: > > 3.4 The CAR discovery protocol MUST provide the MN with GAAR > information along with capabilities. > > 3.x The CAR discovery protocol MUST make efficient > use of the > network resources and SHOULD avoid the transmission of unnecessary > information. > > If there are no objections, Govind will incorporate these > into an update > of the requirements draft. > > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 11:55:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05191 for ; Thu, 28 Mar 2002 11:55:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27439 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 11:55:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27221; Thu, 28 Mar 2002 11:48:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27193 for ; Thu, 28 Mar 2002 11:48:55 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04615 for ; Thu, 28 Mar 2002 11:48:49 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2SGmq3G005026 for ; Thu, 28 Mar 2002 17:48:52 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 17:48:51 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 17:38:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABCF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Deb ate Date: Thu, 28 Mar 2002 17:48:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Agree Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 28, 2002 12:31 AM > To: seamoby@ietf.org > Subject: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery > Debate > > > Folks, > > So after debating these issues, I believe we have agreement on the > following requirements: > > 3.4 The CAR discovery protocol MUST provide the MN with GAAR > information along with capabilities. > > 3.x The CAR discovery protocol MUST make efficient > use of the > network resources and SHOULD avoid the transmission of unnecessary > information. > > If there are no objections, Govind will incorporate these > into an update > of the requirements draft. > > > jak > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 11:56:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05380 for ; Thu, 28 Mar 2002 11:56:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27180; Thu, 28 Mar 2002 11:48:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27151 for ; Thu, 28 Mar 2002 11:48:44 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04605 for ; Thu, 28 Mar 2002 11:48:35 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2SGmb3G004965 for ; Thu, 28 Mar 2002 17:48:37 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 17:48:36 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 17:38:28 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABCE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Govind Krishnamurthi , seamoby@ietf.org Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Thu, 28 Mar 2002 17:48:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org I agree with the text James sent below. Cheers, Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 28, 2002 12:29 AM > To: Govind Krishnamurthi; seamoby@ietf.org > Subject: Re: [Seamoby] MN in charge: What does this mean? > > > Govind, > > I would say "provisionally." The Europeans are off line at > the moment, > so we may see some traffic tomorrow when they are back up. > > I will post these under a separate heading. > > jak > > ----- Original Message ----- > From: "Govind Krishnamurthi" > To: > Sent: Wednesday, March 27, 2002 2:17 PM > Subject: Re: [Seamoby] MN in charge: What does this mean? > > > > > > > > > > Hello all, > > If this is settled, I will incorporate these changes into > > the requirement draft. > > > > Thanks, > > Govind. > > > > >Hi James: > > > > > >Count me on the agreement side for the requirement you > have proposed > as 3.4 > > >and 3.x. > > > > > >I don't mean to nitpick, but one small thing. Can we say network > > >"resources" > > >instead of "bandwidth". Resources will include MN power > too, as MN is > a > > >part > > >of network anyway. But, I don't mean to stimulate > discussion on this > issue. > > >We can move along without that if you think this is too much > attention to > > >detail. > > > > > >BR, > > >Hemant > > > > > > >----------------------------------snip--------------------- > ---------- > > > > > >> > > >>How about: > > >> > > >> 3.4 The CAR discovery protocol MUST provide the MN with > GAAR > > >>information along with capabilities. > > >> > > >> 3.x The CAR discovery protocol MUST make > efficient use of > the > > >>network bandwidth and SHOULD avoid the transmission of > unnecessary > > >>information. > > >> > > >>This puts both aspects of efficiency in one statement. > > >> > > >> jak > > >> > > > >----------------------------------------------------------- > ---------- > > > > > > > > > > > >> > > >>_______________________________________________ > > >>Seamoby mailing list > > >>Seamoby@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > >_________________________________________________________________ > > >Join the world?s largest e-mail service with MSN Hotmail. > > >http://www.hotmail.com > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 11:56:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05387 for ; Thu, 28 Mar 2002 11:56:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27534 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 11:56:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27180; Thu, 28 Mar 2002 11:48:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27151 for ; Thu, 28 Mar 2002 11:48:44 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04605 for ; Thu, 28 Mar 2002 11:48:35 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2SGmb3G004965 for ; Thu, 28 Mar 2002 17:48:37 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 17:48:36 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 17:38:28 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABCE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Govind Krishnamurthi , seamoby@ietf.org Subject: RE: [Seamoby] MN in charge: What does this mean? Date: Thu, 28 Mar 2002 17:48:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org I agree with the text James sent below. Cheers, Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 28, 2002 12:29 AM > To: Govind Krishnamurthi; seamoby@ietf.org > Subject: Re: [Seamoby] MN in charge: What does this mean? > > > Govind, > > I would say "provisionally." The Europeans are off line at > the moment, > so we may see some traffic tomorrow when they are back up. > > I will post these under a separate heading. > > jak > > ----- Original Message ----- > From: "Govind Krishnamurthi" > To: > Sent: Wednesday, March 27, 2002 2:17 PM > Subject: Re: [Seamoby] MN in charge: What does this mean? > > > > > > > > > > Hello all, > > If this is settled, I will incorporate these changes into > > the requirement draft. > > > > Thanks, > > Govind. > > > > >Hi James: > > > > > >Count me on the agreement side for the requirement you > have proposed > as 3.4 > > >and 3.x. > > > > > >I don't mean to nitpick, but one small thing. Can we say network > > >"resources" > > >instead of "bandwidth". Resources will include MN power > too, as MN is > a > > >part > > >of network anyway. But, I don't mean to stimulate > discussion on this > issue. > > >We can move along without that if you think this is too much > attention to > > >detail. > > > > > >BR, > > >Hemant > > > > > > >----------------------------------snip--------------------- > ---------- > > > > > >> > > >>How about: > > >> > > >> 3.4 The CAR discovery protocol MUST provide the MN with > GAAR > > >>information along with capabilities. > > >> > > >> 3.x The CAR discovery protocol MUST make > efficient use of > the > > >>network bandwidth and SHOULD avoid the transmission of > unnecessary > > >>information. > > >> > > >>This puts both aspects of efficiency in one statement. > > >> > > >> jak > > >> > > > >----------------------------------------------------------- > ---------- > > > > > > > > > > > >> > > >>_______________________________________________ > > >>Seamoby mailing list > > >>Seamoby@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > >_________________________________________________________________ > > >Join the world?s largest e-mail service with MSN Hotmail. > > >http://www.hotmail.com > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 12:14:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06437 for ; Thu, 28 Mar 2002 12:14:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29815; Thu, 28 Mar 2002 12:07:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29786 for ; Thu, 28 Mar 2002 12:07:18 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06203 for ; Thu, 28 Mar 2002 12:07:13 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 12:06:42 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC7C@ftmail> From: George Tsirtsis To: seamoby@ietf.org Subject: RE: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Deb ate Date: Thu, 28 Mar 2002 12:06:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org All, I am not going to object to this....BUT.... I would like to point out that this is a typical compromize that ends up producing meaningless requirements documents...and it is not the first time it is happening but we do not seem to learn from past mistakes. 3.x in this case is meaningless and impossible to measure. "efficient use" of something is very relative and it depends on how important/useful is the thing that you try to do. e.g.: 1bit of useless info is very inefficient. The avoidance of transmission of unnecessary information is also extremely meaningless....for obvious reasons. Anyway, I do not have enough cycles to attempt to argue for other text so I do not have the right to be complaining too much. It is just that I hoped people would have learned by the experiance with the CT requirements and would not repeat the same mistakes. If everybody was just a litle bit more open to other people's opinions and had the good of the community in mind we would all do much better. Well, sorry for the mumble...and obviously this is not pointed to any one person; I also have been responsible for similar compromizes in other docs..... With respect George -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 27, 2002 11:31 PM To: seamoby@ietf.org Subject: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Debate Folks, So after debating these issues, I believe we have agreement on the following requirements: 3.4 The CAR discovery protocol MUST provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST make efficient use of the network resources and SHOULD avoid the transmission of unnecessary information. If there are no objections, Govind will incorporate these into an update of the requirements draft. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 12:14:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06454 for ; Thu, 28 Mar 2002 12:14:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00029 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 12:14:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29815; Thu, 28 Mar 2002 12:07:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29786 for ; Thu, 28 Mar 2002 12:07:18 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06203 for ; Thu, 28 Mar 2002 12:07:13 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 12:06:42 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC7C@ftmail> From: George Tsirtsis To: seamoby@ietf.org Subject: RE: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Deb ate Date: Thu, 28 Mar 2002 12:06:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org All, I am not going to object to this....BUT.... I would like to point out that this is a typical compromize that ends up producing meaningless requirements documents...and it is not the first time it is happening but we do not seem to learn from past mistakes. 3.x in this case is meaningless and impossible to measure. "efficient use" of something is very relative and it depends on how important/useful is the thing that you try to do. e.g.: 1bit of useless info is very inefficient. The avoidance of transmission of unnecessary information is also extremely meaningless....for obvious reasons. Anyway, I do not have enough cycles to attempt to argue for other text so I do not have the right to be complaining too much. It is just that I hoped people would have learned by the experiance with the CT requirements and would not repeat the same mistakes. If everybody was just a litle bit more open to other people's opinions and had the good of the community in mind we would all do much better. Well, sorry for the mumble...and obviously this is not pointed to any one person; I also have been responsible for similar compromizes in other docs..... With respect George -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 27, 2002 11:31 PM To: seamoby@ietf.org Subject: [Seamoby] Resolution of Network v.s. Mobile CAR Discovery Debate Folks, So after debating these issues, I believe we have agreement on the following requirements: 3.4 The CAR discovery protocol MUST provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST make efficient use of the network resources and SHOULD avoid the transmission of unnecessary information. If there are no objections, Govind will incorporate these into an update of the requirements draft. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 15:06:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13207 for ; Thu, 28 Mar 2002 15:06:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10155; Thu, 28 Mar 2002 15:01:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10130 for ; Thu, 28 Mar 2002 15:01:21 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13036 for ; Thu, 28 Mar 2002 15:01:18 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA03121 for ; Thu, 28 Mar 2002 13:01:19 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA25710 for ; Thu, 28 Mar 2002 13:01:18 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 28 Mar 2002 14:01:18 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Charlie Perkins'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Thu, 28 Mar 2002 14:01:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Charlie, Please find my in line clarification/question. regards, ajoy -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, March 27, 2002 5:17 PM To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hello, I am a lurker only, but occasionally I read the messages in this thread. If somehow things have progressed past my original understanding, I'd like to find that out. So, a question: James Kempf wrote: > Ajoy, > > You are right, CAR discovery won't be needed if the handover is network > controlled. It will only be needed if the handover is mobile controlled, > and it is really most needed for intertechnology handover. Does this mean that the access points themselves cannot use CAR to prepare for a network-controlled handover? Darn ...! > If the handover is network controlled, the Layer 2 protocol basically > knows > where the MN is going, since it is determined by power levels, and the > MN gets moved. Handover can be controlled by things other than power levels! As someone noted, it would be better to frame handover considerations more general "resource consumption" requirements... ajoy: Sure, you are correct. Handover can be initiated due to other reasons such as to optimize the radio and network resource consumption. But I think my question was regarding the applicability of mobile controlled access router discovery in a network that can only support network controlled L2 handover. I am still not sure how mobile controlled access router discovery will really work in these networks ? BTW, I am not talking about selecting one AR from a pool of ARs in a particular subnet. Please correct me if I am missing something here. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 15:06:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13217 for ; Thu, 28 Mar 2002 15:06:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10426 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 15:06:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10155; Thu, 28 Mar 2002 15:01:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10130 for ; Thu, 28 Mar 2002 15:01:21 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13036 for ; Thu, 28 Mar 2002 15:01:18 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA03121 for ; Thu, 28 Mar 2002 13:01:19 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA25710 for ; Thu, 28 Mar 2002 13:01:18 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 28 Mar 2002 14:01:18 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Charlie Perkins'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Thu, 28 Mar 2002 14:01:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hello Charlie, Please find my in line clarification/question. regards, ajoy -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, March 27, 2002 5:17 PM To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hello, I am a lurker only, but occasionally I read the messages in this thread. If somehow things have progressed past my original understanding, I'd like to find that out. So, a question: James Kempf wrote: > Ajoy, > > You are right, CAR discovery won't be needed if the handover is network > controlled. It will only be needed if the handover is mobile controlled, > and it is really most needed for intertechnology handover. Does this mean that the access points themselves cannot use CAR to prepare for a network-controlled handover? Darn ...! > If the handover is network controlled, the Layer 2 protocol basically > knows > where the MN is going, since it is determined by power levels, and the > MN gets moved. Handover can be controlled by things other than power levels! As someone noted, it would be better to frame handover considerations more general "resource consumption" requirements... ajoy: Sure, you are correct. Handover can be initiated due to other reasons such as to optimize the radio and network resource consumption. But I think my question was regarding the applicability of mobile controlled access router discovery in a network that can only support network controlled L2 handover. I am still not sure how mobile controlled access router discovery will really work in these networks ? BTW, I am not talking about selecting one AR from a pool of ARs in a particular subnet. Please correct me if I am missing something here. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 17:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18776 for ; Thu, 28 Mar 2002 17:55:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19843; Thu, 28 Mar 2002 17:49:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19814 for ; Thu, 28 Mar 2002 17:49:07 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18680 for ; Thu, 28 Mar 2002 17:49:02 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2SMmYV08729; Thu, 28 Mar 2002 16:48:34 -0600 (CST) Message-ID: <3CA39DBD.6040300@alcatel.com> Date: Thu, 28 Mar 2002 16:48:29 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Launcing ip-paging mailing list Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dear all, I am pleased to announce the mailing list to discuss IP Paging at ip-paging@alcatel.com To subscribe send an email to the mailing list administrator at: behcet.sarikaya@alcatel.com We expect to post more info next Tuesday after Easter. Have a Happy Easter. -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 17:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18785 for ; Thu, 28 Mar 2002 17:55:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20078 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 17:55:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19843; Thu, 28 Mar 2002 17:49:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19814 for ; Thu, 28 Mar 2002 17:49:07 -0500 (EST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18680 for ; Thu, 28 Mar 2002 17:49:02 -0500 (EST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g2SMmYV08729; Thu, 28 Mar 2002 16:48:34 -0600 (CST) Message-ID: <3CA39DBD.6040300@alcatel.com> Date: Thu, 28 Mar 2002 16:48:29 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Launcing ip-paging mailing list Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Dear all, I am pleased to announce the mailing list to discuss IP Paging at ip-paging@alcatel.com To subscribe send an email to the mailing list administrator at: behcet.sarikaya@alcatel.com We expect to post more info next Tuesday after Easter. Have a Happy Easter. -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 19:00:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19550 for ; Thu, 28 Mar 2002 19:00:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22567; Thu, 28 Mar 2002 18:55:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22538 for ; Thu, 28 Mar 2002 18:55:38 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19482 for ; Thu, 28 Mar 2002 18:55:35 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA11202 for ; Thu, 28 Mar 2002 16:55:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA27593 for ; Thu, 28 Mar 2002 16:55:36 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 28 Mar 2002 17:55:37 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FFE4@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 17:55:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org [eunsoo] If the presentation is so influential on our issues, could anyone make it available for the people who did not attend the Minneapolis meeting? Madjid>> That plus the meeting minutes, thank you, Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 19:00:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19577 for ; Thu, 28 Mar 2002 19:00:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA23029 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 19:00:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22567; Thu, 28 Mar 2002 18:55:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22538 for ; Thu, 28 Mar 2002 18:55:38 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19482 for ; Thu, 28 Mar 2002 18:55:35 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA11202 for ; Thu, 28 Mar 2002 16:55:37 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA27593 for ; Thu, 28 Mar 2002 16:55:36 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 28 Mar 2002 17:55:37 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FFE4@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: seamoby@ietf.org Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Thu, 28 Mar 2002 17:55:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org [eunsoo] If the presentation is so influential on our issues, could anyone make it available for the people who did not attend the Minneapolis meeting? Madjid>> That plus the meeting minutes, thank you, Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Mar 28 21:36:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22027 for ; Thu, 28 Mar 2002 21:36:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28337; Thu, 28 Mar 2002 21:26:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28308 for ; Thu, 28 Mar 2002 21:26:49 -0500 (EST) Received: from hotmail.com (oe27.law4.hotmail.com [216.33.148.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21927 for ; Thu, 28 Mar 2002 21:26:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Mar 2002 18:26:17 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'Charlie Perkins'" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 11:31:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 29 Mar 2002 02:26:17.0293 (UTC) FILETIME=[1B015FD0:01C1D6C9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'Charlie Perkins'" ; Sent: Thursday, March 28, 2002 12:01 PM Subject: RE: [Seamoby] Examples of CAR discovery > Hello Charlie, > Please find my in line clarification/question. > regards, > ajoy > > > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Wednesday, March 27, 2002 5:17 PM > To: seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hello, > > I am a lurker only, but occasionally I read the messages in this thread. > If somehow things have progressed past my original understanding, > I'd like to find that out. So, a question: > > James Kempf wrote: > > > Ajoy, > > > > You are right, CAR discovery won't be needed if the handover is network > > controlled. It will only be needed if the handover is mobile controlled, > > and it is really most needed for intertechnology handover. > > Does this mean that the access points themselves cannot use CAR to > prepare for a network-controlled handover? Darn ...! > [eunsoo] I don't think we should close the door for network-controlled handoffs or something like network-assisted handoffs. Thanks. Eunsoo > > > If the handover is network controlled, the Layer 2 protocol basically > > knows > > where the MN is going, since it is determined by power levels, and the > > MN gets moved. > > Handover can be controlled by things other than power levels! > As someone noted, it would be better to frame handover considerations > more general "resource consumption" requirements... > > ajoy: Sure, you are correct. Handover can be initiated due to other > reasons such as to optimize the radio and network resource > consumption. But I think my question was regarding the applicability > of mobile controlled access router discovery in a > network that can only support network controlled L2 handover. > I am still not sure how mobile controlled access router discovery > will really work in these networks ? BTW, I am not talking > about selecting one AR from a pool of ARs in a particular subnet. > Please correct me if I am missing something here. > > Regards, > Charlie P. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Mar 28 22:28:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22034 for ; Thu, 28 Mar 2002 21:36:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29093 for seamoby-archive@odin.ietf.org; Thu, 28 Mar 2002 21:36:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28337; Thu, 28 Mar 2002 21:26:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28308 for ; Thu, 28 Mar 2002 21:26:49 -0500 (EST) Received: from hotmail.com (oe27.law4.hotmail.com [216.33.148.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21927 for ; Thu, 28 Mar 2002 21:26:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Mar 2002 18:26:17 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "'Charlie Perkins'" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 11:31:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 29 Mar 2002 02:26:17.0293 (UTC) FILETIME=[1B015FD0:01C1D6C9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'Charlie Perkins'" ; Sent: Thursday, March 28, 2002 12:01 PM Subject: RE: [Seamoby] Examples of CAR discovery > Hello Charlie, > Please find my in line clarification/question. > regards, > ajoy > > > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Wednesday, March 27, 2002 5:17 PM > To: seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hello, > > I am a lurker only, but occasionally I read the messages in this thread. > If somehow things have progressed past my original understanding, > I'd like to find that out. So, a question: > > James Kempf wrote: > > > Ajoy, > > > > You are right, CAR discovery won't be needed if the handover is network > > controlled. It will only be needed if the handover is mobile controlled, > > and it is really most needed for intertechnology handover. > > Does this mean that the access points themselves cannot use CAR to > prepare for a network-controlled handover? Darn ...! > [eunsoo] I don't think we should close the door for network-controlled handoffs or something like network-assisted handoffs. Thanks. Eunsoo > > > If the handover is network controlled, the Layer 2 protocol basically > > knows > > where the MN is going, since it is determined by power levels, and the > > MN gets moved. > > Handover can be controlled by things other than power levels! > As someone noted, it would be better to frame handover considerations > more general "resource consumption" requirements... > > ajoy: Sure, you are correct. Handover can be initiated due to other > reasons such as to optimize the radio and network resource > consumption. But I think my question was regarding the applicability > of mobile controlled access router discovery in a > network that can only support network controlled L2 handover. > I am still not sure how mobile controlled access router discovery > will really work in these networks ? BTW, I am not talking > about selecting one AR from a pool of ARs in a particular subnet. > Please correct me if I am missing something here. > > Regards, > Charlie P. > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 05:40:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08175 for ; Fri, 29 Mar 2002 05:40:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29737; Fri, 29 Mar 2002 05:37:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29705 for ; Fri, 29 Mar 2002 05:37:09 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08129 for ; Fri, 29 Mar 2002 05:37:04 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id CAA00645; Fri, 29 Mar 2002 02:36:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2TAaa212126; Fri, 29 Mar 2002 02:36:36 -0800 X-mProtect:  Fri, 29 Mar 2002 02:36:36 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmJRd1O; Fri, 29 Mar 2002 02:36:34 PST Message-ID: <3CA443BD.1D651B0E@iprg.nokia.com> Date: Fri, 29 Mar 2002 02:36:45 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> <3CA25303.B4585FC3@iprg.nokia.com> <04be01c1d5e8$ad804c40$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello again, James Kempf wrote: > > Does this mean that the access points themselves cannot use CAR to > > prepare for a network-controlled handover? Darn ...! > > They can, but in a typical cellular system, they won't. The access points > > don't move around much, so this can be preprogrammed into tables. I'd like it if, eventually, availability of QoS would be considered a "Capability", and discoverable by way of this CAR protocol that is under discussion. Such information is not static. Indeed, I'd like it if the actual qualifications for candidacy of an access router were _data_, separated from the actual discovery protocol, as far as possible. > > Handover can be controlled by things other than power levels! > > As someone noted, it would be better to frame handover considerations > > more general "resource consumption" requirements... > > Creative, new Layer 2 solutions are always possible, of course. I was > speaking about how it typically works in existing cellular systems. It would be interesting to determine whether existing cellular operation will define the protocol requirements for CAR. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 05:40:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08186 for ; Fri, 29 Mar 2002 05:40:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29828 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 05:40:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29737; Fri, 29 Mar 2002 05:37:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29705 for ; Fri, 29 Mar 2002 05:37:09 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08129 for ; Fri, 29 Mar 2002 05:37:04 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id CAA00645; Fri, 29 Mar 2002 02:36:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2TAaa212126; Fri, 29 Mar 2002 02:36:36 -0800 X-mProtect:  Fri, 29 Mar 2002 02:36:36 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmJRd1O; Fri, 29 Mar 2002 02:36:34 PST Message-ID: <3CA443BD.1D651B0E@iprg.nokia.com> Date: Fri, 29 Mar 2002 02:36:45 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <030001c1d5cc$b9bc3ad0$7e6015ac@T23KEMPF> <3CA25303.B4585FC3@iprg.nokia.com> <04be01c1d5e8$ad804c40$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello again, James Kempf wrote: > > Does this mean that the access points themselves cannot use CAR to > > prepare for a network-controlled handover? Darn ...! > > They can, but in a typical cellular system, they won't. The access points > > don't move around much, so this can be preprogrammed into tables. I'd like it if, eventually, availability of QoS would be considered a "Capability", and discoverable by way of this CAR protocol that is under discussion. Such information is not static. Indeed, I'd like it if the actual qualifications for candidacy of an access router were _data_, separated from the actual discovery protocol, as far as possible. > > Handover can be controlled by things other than power levels! > > As someone noted, it would be better to frame handover considerations > > more general "resource consumption" requirements... > > Creative, new Layer 2 solutions are always possible, of course. I was > speaking about how it typically works in existing cellular systems. It would be interesting to determine whether existing cellular operation will define the protocol requirements for CAR. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 11:19:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20867 for ; Fri, 29 Mar 2002 11:19:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13962; Fri, 29 Mar 2002 11:12:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13934 for ; Fri, 29 Mar 2002 11:12:35 -0500 (EST) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20680 for ; Fri, 29 Mar 2002 11:12:32 -0500 (EST) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 11:12:24 -0500 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Charlie Perkins'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 11:12:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi, Don't want to be a butinsky, but oh well. > Hello again, > > James Kempf wrote: > > > > Does this mean that the access points themselves cannot use CAR to > > > prepare for a network-controlled handover? Darn ...! > > > > They can, but in a typical cellular system, they won't. The > access points > > > > don't move around much, so this can be preprogrammed into tables. > > I'd like it if, eventually, availability of QoS would be considered > a "Capability", and discoverable by way of this CAR protocol that > is under discussion. Such information is not static. > > Indeed, I'd like it if the actual qualifications for candidacy of an > access router were _data_, separated from the actual discovery > protocol, as far as possible. I like what Charlie is saying here and that was my original thoughts with contract NET protocols (CNP) being used to decide on the best handoff candidate based on vectors of metrics exchanged between the mobile and the AR/AP (watcha callits). Cheers, phil **************************************************************************** This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 12:13:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20876 for ; Fri, 29 Mar 2002 11:19:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14209 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 11:19:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13962; Fri, 29 Mar 2002 11:12:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13934 for ; Fri, 29 Mar 2002 11:12:35 -0500 (EST) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20680 for ; Fri, 29 Mar 2002 11:12:32 -0500 (EST) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 11:12:24 -0500 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'Charlie Perkins'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 11:12:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi, Don't want to be a butinsky, but oh well. > Hello again, > > James Kempf wrote: > > > > Does this mean that the access points themselves cannot use CAR to > > > prepare for a network-controlled handover? Darn ...! > > > > They can, but in a typical cellular system, they won't. The > access points > > > > don't move around much, so this can be preprogrammed into tables. > > I'd like it if, eventually, availability of QoS would be considered > a "Capability", and discoverable by way of this CAR protocol that > is under discussion. Such information is not static. > > Indeed, I'd like it if the actual qualifications for candidacy of an > access router were _data_, separated from the actual discovery > protocol, as far as possible. I like what Charlie is saying here and that was my original thoughts with contract NET protocols (CNP) being used to decide on the best handoff candidate based on vectors of metrics exchanged between the mobile and the AR/AP (watcha callits). Cheers, phil **************************************************************************** This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 12:16:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24040 for ; Fri, 29 Mar 2002 12:16:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18394; Fri, 29 Mar 2002 12:13:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18365 for ; Fri, 29 Mar 2002 12:13:27 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23947 for ; Fri, 29 Mar 2002 12:13:23 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2THCjI19596; Fri, 29 Mar 2002 09:12:45 -0800 (PST) Message-ID: <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phillip Neumiller" , "'Charlie Perkins'" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 09:11:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit OK, I wasn't going to respond to this in an attempt to reduce my email volume, but what the hey... > > I'd like it if, eventually, availability of QoS would be considered > > a "Capability", and discoverable by way of this CAR protocol that > > is under discussion. Such information is not static. > > > > Indeed, I'd like it if the actual qualifications for candidacy of an > > access router were _data_, separated from the actual discovery > > protocol, as far as possible. > > I like what Charlie is saying here and that was my original thoughts with > contract NET protocols (CNP) being used to decide on the best handoff > candidate based on vectors of metrics exchanged between the mobile and the > AR/AP (watcha callits). > So the problem I have with this is that, given one (1) specific wireless link protocol, I can't see why the QoS or any other characteristic should differ between one access point and another. There is an issue about link congestion, of course, but I'm not sure if the IP level is really the right place to handle issues of link congestion (for end to end congestion, of course, the situation is quite different). Some wireless protocols have more effective ways of handling link congestion. For intertechnology handover, I agree that there are differences, but I wonder where to draw the line between dynamic, quickly changing characteristics like QoS and static qualities, such as the link media type. For static qualities, I can see an obvious benefit, but for more dynamic qualities, the characteristics may change so quickly that the information is out of date by the time the MN has made the decision to move. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 12:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24050 for ; Fri, 29 Mar 2002 12:16:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18583 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 12:16:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18394; Fri, 29 Mar 2002 12:13:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18365 for ; Fri, 29 Mar 2002 12:13:27 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23947 for ; Fri, 29 Mar 2002 12:13:23 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2THCjI19596; Fri, 29 Mar 2002 09:12:45 -0800 (PST) Message-ID: <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phillip Neumiller" , "'Charlie Perkins'" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 09:11:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit OK, I wasn't going to respond to this in an attempt to reduce my email volume, but what the hey... > > I'd like it if, eventually, availability of QoS would be considered > > a "Capability", and discoverable by way of this CAR protocol that > > is under discussion. Such information is not static. > > > > Indeed, I'd like it if the actual qualifications for candidacy of an > > access router were _data_, separated from the actual discovery > > protocol, as far as possible. > > I like what Charlie is saying here and that was my original thoughts with > contract NET protocols (CNP) being used to decide on the best handoff > candidate based on vectors of metrics exchanged between the mobile and the > AR/AP (watcha callits). > So the problem I have with this is that, given one (1) specific wireless link protocol, I can't see why the QoS or any other characteristic should differ between one access point and another. There is an issue about link congestion, of course, but I'm not sure if the IP level is really the right place to handle issues of link congestion (for end to end congestion, of course, the situation is quite different). Some wireless protocols have more effective ways of handling link congestion. For intertechnology handover, I agree that there are differences, but I wonder where to draw the line between dynamic, quickly changing characteristics like QoS and static qualities, such as the link media type. For static qualities, I can see an obvious benefit, but for more dynamic qualities, the characteristics may change so quickly that the information is out of date by the time the MN has made the decision to move. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 14:26:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29728 for ; Fri, 29 Mar 2002 14:26:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26745; Fri, 29 Mar 2002 14:24:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26715 for ; Fri, 29 Mar 2002 14:24:06 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29599 for ; Fri, 29 Mar 2002 14:24:02 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22165; Fri, 29 Mar 2002 11:23:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2TJNWM30491; Fri, 29 Mar 2002 11:23:32 -0800 X-mProtect:  Fri, 29 Mar 2002 11:23:32 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv7QYhc; Fri, 29 Mar 2002 11:23:30 PST Message-ID: <3CA4BF3C.2B701CBC@iprg.nokia.com> Date: Fri, 29 Mar 2002 11:23:40 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Jim, If one access router has 5 Mb/s available, and another only has 10 Kb/s available, I would like to get my streaming video from the first access router. I might be able to have the choice. IP is exactly the right place for this to be disseminated, assuming that we even have IP QoS in the first place. I do not think that this information would typically change much over the 10-150 milliseconds that it "should" take to accomplish a handover. If this is a problem, though, one could define a "special" kind of CAR discovery protocol that makes the candidate access router reserve the bandwidth for 200 milliseconds, or else not claim that it has the bandwidth available. Regards, Charlie P. James Kempf wrote: > OK, I wasn't going to respond to this in an attempt to reduce my > email volume, but what the hey... > > > > I'd like it if, eventually, availability of QoS would be considered > > > a "Capability", and discoverable by way of this CAR protocol that > > > is under discussion. Such information is not static. > > > > > > Indeed, I'd like it if the actual qualifications for candidacy of an > > > access router were _data_, separated from the actual discovery > > > protocol, as far as possible. > > > > I like what Charlie is saying here and that was my original thoughts > with > > contract NET protocols (CNP) being used to decide on the best handoff > > candidate based on vectors of metrics exchanged between the mobile and > the > > AR/AP (watcha callits). > > > > So the problem I have with this is that, given one (1) specific wireless > link protocol, > I can't see why the QoS or any other characteristic should differ > between one access > point and another. > > There is an issue about link congestion, of course, but I'm not sure if > the IP level is really the > right place to handle issues of link congestion (for end to end > congestion, of course, the > situation is quite different). Some wireless protocols have more > effective ways of handling > link congestion. > > For intertechnology handover, I agree that there are differences, but I > wonder where to > draw the line between dynamic, quickly changing characteristics like QoS > and static > qualities, such as the link media type. For static qualities, I can see > an obvious benefit, > but for more dynamic qualities, the characteristics may change so > quickly that the > information is out of date by the time the MN has made the decision to > move. > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 14:26:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29737 for ; Fri, 29 Mar 2002 14:26:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26906 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 14:26:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26745; Fri, 29 Mar 2002 14:24:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26715 for ; Fri, 29 Mar 2002 14:24:06 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29599 for ; Fri, 29 Mar 2002 14:24:02 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22165; Fri, 29 Mar 2002 11:23:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2TJNWM30491; Fri, 29 Mar 2002 11:23:32 -0800 X-mProtect:  Fri, 29 Mar 2002 11:23:32 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv7QYhc; Fri, 29 Mar 2002 11:23:30 PST Message-ID: <3CA4BF3C.2B701CBC@iprg.nokia.com> Date: Fri, 29 Mar 2002 11:23:40 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Jim, If one access router has 5 Mb/s available, and another only has 10 Kb/s available, I would like to get my streaming video from the first access router. I might be able to have the choice. IP is exactly the right place for this to be disseminated, assuming that we even have IP QoS in the first place. I do not think that this information would typically change much over the 10-150 milliseconds that it "should" take to accomplish a handover. If this is a problem, though, one could define a "special" kind of CAR discovery protocol that makes the candidate access router reserve the bandwidth for 200 milliseconds, or else not claim that it has the bandwidth available. Regards, Charlie P. James Kempf wrote: > OK, I wasn't going to respond to this in an attempt to reduce my > email volume, but what the hey... > > > > I'd like it if, eventually, availability of QoS would be considered > > > a "Capability", and discoverable by way of this CAR protocol that > > > is under discussion. Such information is not static. > > > > > > Indeed, I'd like it if the actual qualifications for candidacy of an > > > access router were _data_, separated from the actual discovery > > > protocol, as far as possible. > > > > I like what Charlie is saying here and that was my original thoughts > with > > contract NET protocols (CNP) being used to decide on the best handoff > > candidate based on vectors of metrics exchanged between the mobile and > the > > AR/AP (watcha callits). > > > > So the problem I have with this is that, given one (1) specific wireless > link protocol, > I can't see why the QoS or any other characteristic should differ > between one access > point and another. > > There is an issue about link congestion, of course, but I'm not sure if > the IP level is really the > right place to handle issues of link congestion (for end to end > congestion, of course, the > situation is quite different). Some wireless protocols have more > effective ways of handling > link congestion. > > For intertechnology handover, I agree that there are differences, but I > wonder where to > draw the line between dynamic, quickly changing characteristics like QoS > and static > qualities, such as the link media type. For static qualities, I can see > an obvious benefit, > but for more dynamic qualities, the characteristics may change so > quickly that the > information is out of date by the time the MN has made the decision to > move. > > jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 18:24:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07417 for ; Fri, 29 Mar 2002 18:24:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08708; Fri, 29 Mar 2002 18:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08673 for ; Fri, 29 Mar 2002 18:11:29 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07102 for ; Fri, 29 Mar 2002 18:11:23 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA16843 for ; Fri, 29 Mar 2002 16:11:22 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA08442 for ; Fri, 29 Mar 2002 16:11:22 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 29 Mar 2002 17:11:21 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FFFA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 17:11:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Well, don't know what a butinsky is (that phil is refering to :) ) , but that QoS capabilities were what I had in mind as the most important capability information to be shared or included in discovery process. And yes, as Charlie mentioned, different access technologies with different bandwidth is an important scenario here. Madjid -----Original Message----- From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] Sent: Friday, March 29, 2002 10:12 AM To: 'Charlie Perkins'; James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Hi, Don't want to be a butinsky, but oh well. > Hello again, > > James Kempf wrote: > > > > Does this mean that the access points themselves cannot use CAR to > > > prepare for a network-controlled handover? Darn ...! > > > > They can, but in a typical cellular system, they won't. The > access points > > > > don't move around much, so this can be preprogrammed into tables. > > I'd like it if, eventually, availability of QoS would be considered > a "Capability", and discoverable by way of this CAR protocol that > is under discussion. Such information is not static. > > Indeed, I'd like it if the actual qualifications for candidacy of an > access router were _data_, separated from the actual discovery > protocol, as far as possible. I like what Charlie is saying here and that was my original thoughts with contract NET protocols (CNP) being used to decide on the best handoff candidate based on vectors of metrics exchanged between the mobile and the AR/AP (watcha callits). Cheers, phil **************************************************************************** This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 18:24:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07433 for ; Fri, 29 Mar 2002 18:24:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09338 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 18:24:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08708; Fri, 29 Mar 2002 18:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08673 for ; Fri, 29 Mar 2002 18:11:29 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07102 for ; Fri, 29 Mar 2002 18:11:23 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA16843 for ; Fri, 29 Mar 2002 16:11:22 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA08442 for ; Fri, 29 Mar 2002 16:11:22 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 29 Mar 2002 17:11:21 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FFFA@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 17:11:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Well, don't know what a butinsky is (that phil is refering to :) ) , but that QoS capabilities were what I had in mind as the most important capability information to be shared or included in discovery process. And yes, as Charlie mentioned, different access technologies with different bandwidth is an important scenario here. Madjid -----Original Message----- From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] Sent: Friday, March 29, 2002 10:12 AM To: 'Charlie Perkins'; James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Hi, Don't want to be a butinsky, but oh well. > Hello again, > > James Kempf wrote: > > > > Does this mean that the access points themselves cannot use CAR to > > > prepare for a network-controlled handover? Darn ...! > > > > They can, but in a typical cellular system, they won't. The > access points > > > > don't move around much, so this can be preprogrammed into tables. > > I'd like it if, eventually, availability of QoS would be considered > a "Capability", and discoverable by way of this CAR protocol that > is under discussion. Such information is not static. > > Indeed, I'd like it if the actual qualifications for candidacy of an > access router were _data_, separated from the actual discovery > protocol, as far as possible. I like what Charlie is saying here and that was my original thoughts with contract NET protocols (CNP) being used to decide on the best handoff candidate based on vectors of metrics exchanged between the mobile and the AR/AP (watcha callits). Cheers, phil **************************************************************************** This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 22:33:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12694 for ; Fri, 29 Mar 2002 22:33:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19866; Fri, 29 Mar 2002 22:12:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19838 for ; Fri, 29 Mar 2002 22:12:25 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11433 for ; Fri, 29 Mar 2002 22:12:21 -0500 (EST) Received: from T23KEMPF (dhcp2.docomolabs-usa.com [172.21.96.2]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2U3BfI07906; Fri, 29 Mar 2002 19:11:41 -0800 (PST) Message-ID: <000d01c1d798$643a7cc0$026015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 19:10:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > If one access router has 5 Mb/s available, and another only has > 10 Kb/s available, I would like to get my streaming video from > the first access router. I might be able to have the choice. > Wouldn't it be better to let the IP QoS signaling protocol handle this? I believe this is exactly what NSIS is working on, but John Loughny could say more. > IP is exactly the right place for this to be disseminated, assuming > that we even have IP QoS in the first place. I was speaking of last hop link capacity. I agree that IP is the right place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS charter also speaks about last hop QoS signaling as well. There is some interest in NSIS to tie Layer 2 QoS and IP QoS together on the last hop, but there has not yet been much work done on it. > I do not think > that this information would typically change much over the > 10-150 milliseconds that it "should" take to accomplish a > handover. If this is a problem, though, one could define a > "special" kind of CAR discovery protocol that makes the > candidate access router reserve the bandwidth for 200 milliseconds, > or else not claim that it has the bandwidth available. > I did not mean just during the handover. If the information provided by the CAR discovery protocol has a lifetime of 200 msec, then if the total L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell during the time between when a mobile node gets its last CAR discovery update and when it decides to move to the cell. At that point, the QoS due to the new load may be below the decision point where the mobile node would want to move into the cell. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 22:33:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12703 for ; Fri, 29 Mar 2002 22:33:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21019 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 22:33:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19866; Fri, 29 Mar 2002 22:12:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19838 for ; Fri, 29 Mar 2002 22:12:25 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11433 for ; Fri, 29 Mar 2002 22:12:21 -0500 (EST) Received: from T23KEMPF (dhcp2.docomolabs-usa.com [172.21.96.2]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2U3BfI07906; Fri, 29 Mar 2002 19:11:41 -0800 (PST) Message-ID: <000d01c1d798$643a7cc0$026015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Fri, 29 Mar 2002 19:10:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit > If one access router has 5 Mb/s available, and another only has > 10 Kb/s available, I would like to get my streaming video from > the first access router. I might be able to have the choice. > Wouldn't it be better to let the IP QoS signaling protocol handle this? I believe this is exactly what NSIS is working on, but John Loughny could say more. > IP is exactly the right place for this to be disseminated, assuming > that we even have IP QoS in the first place. I was speaking of last hop link capacity. I agree that IP is the right place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS charter also speaks about last hop QoS signaling as well. There is some interest in NSIS to tie Layer 2 QoS and IP QoS together on the last hop, but there has not yet been much work done on it. > I do not think > that this information would typically change much over the > 10-150 milliseconds that it "should" take to accomplish a > handover. If this is a problem, though, one could define a > "special" kind of CAR discovery protocol that makes the > candidate access router reserve the bandwidth for 200 milliseconds, > or else not claim that it has the bandwidth available. > I did not mean just during the handover. If the information provided by the CAR discovery protocol has a lifetime of 200 msec, then if the total L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell during the time between when a mobile node gets its last CAR discovery update and when it decides to move to the cell. At that point, the QoS due to the new load may be below the decision point where the mobile node would want to move into the cell. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 23:20:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13250 for ; Fri, 29 Mar 2002 23:20:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22530; Fri, 29 Mar 2002 23:09:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22501 for ; Fri, 29 Mar 2002 23:09:56 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13192 for ; Fri, 29 Mar 2002 23:09:51 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA16749; Fri, 29 Mar 2002 20:09:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2U49Oo04315; Fri, 29 Mar 2002 20:09:24 -0800 X-mProtect: <200203300409> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrWrtQE; Fri, 29 Mar 2002 20:09:22 PST Message-ID: <3CA53A81.33174CF0@iprg.nokia.com> Date: Fri, 29 Mar 2002 20:09:37 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello again, James Kempf wrote: > > If one access router has 5 Mb/s available, and another only has > > 10 Kb/s available, I would like to get my streaming video from > > the first access router. I might be able to have the choice. > > > > Wouldn't it be better to let the IP QoS signaling protocol handle this? > I believe this is exactly what NSIS is working on, > but John Loughny could say more. I didn't know that NSIS was gearing up to supply the needs of handovers -- and, in a way, I hope they don't because I can't follow that many mailing litss. And besides, if smooth handovers is not part of [seamoby] charter, what is?! Lastly, I claim that QoS management in the small is a pretty essential requirement for smooth handovers. Surely, remote signaling is to be avoided. > IP is exactly the right place for this to be disseminated, assuming > that we even have IP QoS in the first place. > I was speaking of last hop link capacity. I agree that IP is the right > place to handle next to last hop QoS (i.e. DiffServ). I am also talking about last hop link capacity. That is what is most important (typically) for the mobile node, and thus is relevant for seamless mobility. Links on the other side of the access routers (away from the mobile node) should be considered irrelevant for this discussion, I hope. Otherwise, we might as well give up. I do not think DiffServ has a role to play in [seamoby] protocols, but I certainly do think that IP has a role to play. > I believe the NSIS > charter also speaks about last hop QoS signaling as well. There is some > interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > hop, but there has not yet been much work done on it. Ouch. Somehow I thought NSIS was end-to-end, not localized to handovers. > I did not mean just during the handover. If the information provided by > the > CAR discovery protocol has a lifetime of 200 msec, then if the total L2 + > L3 > handover time is 40 ms, 5 mobile nodes could move into the cell during > update and when it decides to move to the cell. ... This is true, but that's the breaks. A lot of bad things could happen, and if there is a recognized danger, then we should go with the provisional short-lived reservations. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 23:20:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13261 for ; Fri, 29 Mar 2002 23:20:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA22687 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 23:20:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22530; Fri, 29 Mar 2002 23:09:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22501 for ; Fri, 29 Mar 2002 23:09:56 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13192 for ; Fri, 29 Mar 2002 23:09:51 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA16749; Fri, 29 Mar 2002 20:09:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2U49Oo04315; Fri, 29 Mar 2002 20:09:24 -0800 X-mProtect: <200203300409> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrWrtQE; Fri, 29 Mar 2002 20:09:22 PST Message-ID: <3CA53A81.33174CF0@iprg.nokia.com> Date: Fri, 29 Mar 2002 20:09:37 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello again, James Kempf wrote: > > If one access router has 5 Mb/s available, and another only has > > 10 Kb/s available, I would like to get my streaming video from > > the first access router. I might be able to have the choice. > > > > Wouldn't it be better to let the IP QoS signaling protocol handle this? > I believe this is exactly what NSIS is working on, > but John Loughny could say more. I didn't know that NSIS was gearing up to supply the needs of handovers -- and, in a way, I hope they don't because I can't follow that many mailing litss. And besides, if smooth handovers is not part of [seamoby] charter, what is?! Lastly, I claim that QoS management in the small is a pretty essential requirement for smooth handovers. Surely, remote signaling is to be avoided. > IP is exactly the right place for this to be disseminated, assuming > that we even have IP QoS in the first place. > I was speaking of last hop link capacity. I agree that IP is the right > place to handle next to last hop QoS (i.e. DiffServ). I am also talking about last hop link capacity. That is what is most important (typically) for the mobile node, and thus is relevant for seamless mobility. Links on the other side of the access routers (away from the mobile node) should be considered irrelevant for this discussion, I hope. Otherwise, we might as well give up. I do not think DiffServ has a role to play in [seamoby] protocols, but I certainly do think that IP has a role to play. > I believe the NSIS > charter also speaks about last hop QoS signaling as well. There is some > interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > hop, but there has not yet been much work done on it. Ouch. Somehow I thought NSIS was end-to-end, not localized to handovers. > I did not mean just during the handover. If the information provided by > the > CAR discovery protocol has a lifetime of 200 msec, then if the total L2 + > L3 > handover time is 40 ms, 5 mobile nodes could move into the cell during > update and when it decides to move to the cell. ... This is true, but that's the breaks. A lot of bad things could happen, and if there is a recognized danger, then we should go with the provisional short-lived reservations. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Mar 29 23:30:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13395 for ; Fri, 29 Mar 2002 23:30:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22730; Fri, 29 Mar 2002 23:21:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22702 for ; Fri, 29 Mar 2002 23:21:49 -0500 (EST) Received: from hotmail.com (oe27.law4.hotmail.com [216.33.148.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13280 for ; Fri, 29 Mar 2002 23:21:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Mar 2002 20:21:13 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "James Kempf" , "Charlie Perkins" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Sat, 30 Mar 2002 13:26:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 30 Mar 2002 04:21:13.0238 (UTC) FILETIME=[53B8D360:01C1D7A2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Kempf" To: "Charlie Perkins" Cc: Sent: Friday, March 29, 2002 7:10 PM Subject: Re: [Seamoby] Examples of CAR discovery > > If one access router has 5 Mb/s available, and another only has > > 10 Kb/s available, I would like to get my streaming video from > > the first access router. I might be able to have the choice. > > > > Wouldn't it be better to let the IP QoS signaling protocol handle this? > I believe this is exactly what NSIS is working on, > but John Loughny could say more. > > > IP is exactly the right place for this to be disseminated, assuming > > that we even have IP QoS in the first place. > > I was speaking of last hop link capacity. I agree that IP is the right > place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS > charter also speaks about last hop QoS signaling as well. There is some > interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > hop, but there has not yet been much work done on it. > > > I do not think > > that this information would typically change much over the > > 10-150 milliseconds that it "should" take to accomplish a > > handover. If this is a problem, though, one could define a > > "special" kind of CAR discovery protocol that makes the > > candidate access router reserve the bandwidth for 200 milliseconds, > > or else not claim that it has the bandwidth available. > > > > I did not mean just during the handover. If the information provided by > the CAR discovery protocol has a lifetime of 200 msec, then if the total > L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell > during the time between when a mobile node gets its last CAR discovery > update and when it decides to move to the cell. At that point, the QoS > due to the new load may be below the decision point where the mobile > node would want to move into the cell. > I think that's where the network can do some more intelligent work, that is, the network could make selective recommendations to the mobile nodes. Thanks. Eunsoo > jak > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Mar 29 23:30:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13407 for ; Fri, 29 Mar 2002 23:30:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA23029 for seamoby-archive@odin.ietf.org; Fri, 29 Mar 2002 23:30:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22730; Fri, 29 Mar 2002 23:21:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22702 for ; Fri, 29 Mar 2002 23:21:49 -0500 (EST) Received: from hotmail.com (oe27.law4.hotmail.com [216.33.148.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13280 for ; Fri, 29 Mar 2002 23:21:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Mar 2002 20:21:13 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "James Kempf" , "Charlie Perkins" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Sat, 30 Mar 2002 13:26:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 30 Mar 2002 04:21:13.0238 (UTC) FILETIME=[53B8D360:01C1D7A2] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Kempf" To: "Charlie Perkins" Cc: Sent: Friday, March 29, 2002 7:10 PM Subject: Re: [Seamoby] Examples of CAR discovery > > If one access router has 5 Mb/s available, and another only has > > 10 Kb/s available, I would like to get my streaming video from > > the first access router. I might be able to have the choice. > > > > Wouldn't it be better to let the IP QoS signaling protocol handle this? > I believe this is exactly what NSIS is working on, > but John Loughny could say more. > > > IP is exactly the right place for this to be disseminated, assuming > > that we even have IP QoS in the first place. > > I was speaking of last hop link capacity. I agree that IP is the right > place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS > charter also speaks about last hop QoS signaling as well. There is some > interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > hop, but there has not yet been much work done on it. > > > I do not think > > that this information would typically change much over the > > 10-150 milliseconds that it "should" take to accomplish a > > handover. If this is a problem, though, one could define a > > "special" kind of CAR discovery protocol that makes the > > candidate access router reserve the bandwidth for 200 milliseconds, > > or else not claim that it has the bandwidth available. > > > > I did not mean just during the handover. If the information provided by > the CAR discovery protocol has a lifetime of 200 msec, then if the total > L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell > during the time between when a mobile node gets its last CAR discovery > update and when it decides to move to the cell. At that point, the QoS > due to the new load may be below the decision point where the mobile > node would want to move into the cell. > I think that's where the network can do some more intelligent work, that is, the network could make selective recommendations to the mobile nodes. Thanks. Eunsoo > jak > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Mar 30 22:33:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10453 for ; Sat, 30 Mar 2002 22:33:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23140; Sat, 30 Mar 2002 22:12:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23109 for ; Sat, 30 Mar 2002 22:12:51 -0500 (EST) Received: from hotmail.com (f88.law7.hotmail.com [216.33.237.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09404 for ; Sat, 30 Mar 2002 22:12:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Mar 2002 19:12:20 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 31 Mar 2002 03:12:20 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 03:12:20 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Mar 2002 03:12:20.0796 (UTC) FILETIME=[DF01F7C0:01C1D861] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: As far as delegating QoS aspects of smooth handoff to NSIS is considered, the following statement that was discussed in the WG catches my attention when reading NSIS (rough) meeting minutes from IETF53. [Quote:] "Regarding to the mobile IP, the hand of decision and trigger sources should be out of the scope of the NSIS. Thus the WG should rather focus only on "establishing" QoS after hand off." The following statement from Mobile IP QoS requirements draft (WG document that has passed the last call) is interesting too: [Quote:] "In this document, we assume that the target access router for MN's handover is already pinned down by other protocols. For example, Seamoby working group has started work on the candidate access router discovery protocols [3]. Thus, any QoS-capability specific negotiations that may affect the handover decision are outside the scope of QoS solution as such, rather need to be performed by candidate and target access router selection protocols." BR, Hemant >From: "James Kempf" >To: "Charlie Perkins" >CC: >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > If one access router has 5 Mb/s available, and another only has > > 10 Kb/s available, I would like to get my streaming video from > > the first access router. I might be able to have the choice. > > > >Wouldn't it be better to let the IP QoS signaling protocol handle this? >I believe this is exactly what NSIS is working on, >but John Loughny could say more. > > > IP is exactly the right place for this to be disseminated, assuming > > that we even have IP QoS in the first place. > >I was speaking of last hop link capacity. I agree that IP is the right >place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS >charter also speaks about last hop QoS signaling as well. There is some >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last >hop, but there has not yet been much work done on it. > > > I do not think > > that this information would typically change much over the > > 10-150 milliseconds that it "should" take to accomplish a > > handover. If this is a problem, though, one could define a > > "special" kind of CAR discovery protocol that makes the > > candidate access router reserve the bandwidth for 200 milliseconds, > > or else not claim that it has the bandwidth available. > > > >I did not mean just during the handover. If the information provided by >the CAR discovery protocol has a lifetime of 200 msec, then if the total >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell >during the time between when a mobile node gets its last CAR discovery >update and when it decides to move to the cell. At that point, the QoS >due to the new load may be below the decision point where the mobile >node would want to move into the cell. > > jak > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Mar 30 22:33:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10461 for ; Sat, 30 Mar 2002 22:33:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA24076 for seamoby-archive@odin.ietf.org; Sat, 30 Mar 2002 22:33:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23140; Sat, 30 Mar 2002 22:12:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23109 for ; Sat, 30 Mar 2002 22:12:51 -0500 (EST) Received: from hotmail.com (f88.law7.hotmail.com [216.33.237.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09404 for ; Sat, 30 Mar 2002 22:12:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Mar 2002 19:12:20 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 31 Mar 2002 03:12:20 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 03:12:20 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Mar 2002 03:12:20.0796 (UTC) FILETIME=[DF01F7C0:01C1D861] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: As far as delegating QoS aspects of smooth handoff to NSIS is considered, the following statement that was discussed in the WG catches my attention when reading NSIS (rough) meeting minutes from IETF53. [Quote:] "Regarding to the mobile IP, the hand of decision and trigger sources should be out of the scope of the NSIS. Thus the WG should rather focus only on "establishing" QoS after hand off." The following statement from Mobile IP QoS requirements draft (WG document that has passed the last call) is interesting too: [Quote:] "In this document, we assume that the target access router for MN's handover is already pinned down by other protocols. For example, Seamoby working group has started work on the candidate access router discovery protocols [3]. Thus, any QoS-capability specific negotiations that may affect the handover decision are outside the scope of QoS solution as such, rather need to be performed by candidate and target access router selection protocols." BR, Hemant >From: "James Kempf" >To: "Charlie Perkins" >CC: >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > If one access router has 5 Mb/s available, and another only has > > 10 Kb/s available, I would like to get my streaming video from > > the first access router. I might be able to have the choice. > > > >Wouldn't it be better to let the IP QoS signaling protocol handle this? >I believe this is exactly what NSIS is working on, >but John Loughny could say more. > > > IP is exactly the right place for this to be disseminated, assuming > > that we even have IP QoS in the first place. > >I was speaking of last hop link capacity. I agree that IP is the right >place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS >charter also speaks about last hop QoS signaling as well. There is some >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last >hop, but there has not yet been much work done on it. > > > I do not think > > that this information would typically change much over the > > 10-150 milliseconds that it "should" take to accomplish a > > handover. If this is a problem, though, one could define a > > "special" kind of CAR discovery protocol that makes the > > candidate access router reserve the bandwidth for 200 milliseconds, > > or else not claim that it has the bandwidth available. > > > >I did not mean just during the handover. If the information provided by >the CAR discovery protocol has a lifetime of 200 msec, then if the total >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell >during the time between when a mobile node gets its last CAR discovery >update and when it decides to move to the cell. At that point, the QoS >due to the new load may be below the decision point where the mobile >node would want to move into the cell. > > jak > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 06:29:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22352 for ; Sun, 31 Mar 2002 06:29:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19418; Sun, 31 Mar 2002 06:11:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19387 for ; Sun, 31 Mar 2002 06:11:07 -0500 (EST) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22254 for ; Sun, 31 Mar 2002 06:10:59 -0500 (EST) Received: (cpmta 18530 invoked from network); 31 Mar 2002 03:10:31 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.206) with SMTP; 31 Mar 2002 03:10:31 -0800 X-Sent: 31 Mar 2002 11:10:31 GMT Message-ID: <001601c1d8a4$ad594730$0902a8c0@Study> From: "Phil Neumiller" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 06:10:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Interesting... ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Sunday, March 31, 2002 3:12 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hi: > > As far as delegating QoS aspects of smooth handoff to NSIS is considered, > the following statement that was discussed in the WG catches my attention > when reading NSIS (rough) meeting minutes from IETF53. > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > sources should be out of the scope of the NSIS. Thus the WG should rather > focus only on "establishing" QoS after hand off." Don't know who this quote is from, but clearly this show a mis-understanding. There should be no "after" handoff. A seamless handoff will not have a before and after. A big part of QoS to mobiles is making the handoff seamless. -pdn _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 06:29:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22361 for ; Sun, 31 Mar 2002 06:29:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA19718 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 06:29:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19418; Sun, 31 Mar 2002 06:11:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19387 for ; Sun, 31 Mar 2002 06:11:07 -0500 (EST) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22254 for ; Sun, 31 Mar 2002 06:10:59 -0500 (EST) Received: (cpmta 18530 invoked from network); 31 Mar 2002 03:10:31 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.206) with SMTP; 31 Mar 2002 03:10:31 -0800 X-Sent: 31 Mar 2002 11:10:31 GMT Message-ID: <001601c1d8a4$ad594730$0902a8c0@Study> From: "Phil Neumiller" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 06:10:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Interesting... ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Sunday, March 31, 2002 3:12 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hi: > > As far as delegating QoS aspects of smooth handoff to NSIS is considered, > the following statement that was discussed in the WG catches my attention > when reading NSIS (rough) meeting minutes from IETF53. > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > sources should be out of the scope of the NSIS. Thus the WG should rather > focus only on "establishing" QoS after hand off." Don't know who this quote is from, but clearly this show a mis-understanding. There should be no "after" handoff. A seamless handoff will not have a before and after. A big part of QoS to mobiles is making the handoff seamless. -pdn _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 11:51:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25730 for ; Sun, 31 Mar 2002 11:51:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29321; Sun, 31 Mar 2002 11:29:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29292 for ; Sun, 31 Mar 2002 11:29:38 -0500 (EST) Received: from hotmail.com (f89.law7.hotmail.com [216.33.237.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25139 for ; Sun, 31 Mar 2002 11:29:35 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Mar 2002 08:29:04 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 31 Mar 2002 16:29:04 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 16:29:04 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Mar 2002 16:29:04.0835 (UTC) FILETIME=[2C6F7130:01C1D8D1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: You are right, there is not one point in time that can probably be identified as handoff event in seamless handoffs. But, I think, in spirit, this means that NSIS protocol may no go looking for which access router is the best one for MN's handoff. Rather it will take the target access router as input and *establish* QoS from there. Hemant >From: "Phil Neumiller" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Sun, 31 Mar 2002 06:10:33 -0500 > >Interesting... >----- Original Message ----- >From: "Hemant Chaskar" >To: >Sent: Sunday, March 31, 2002 3:12 AM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi: > > > > As far as delegating QoS aspects of smooth handoff to NSIS is >considered, > > the following statement that was discussed in the WG catches my >attention > > when reading NSIS (rough) meeting minutes from IETF53. > > > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > > sources should be out of the scope of the NSIS. Thus the WG should >rather > > focus only on "establishing" QoS after hand off." > >Don't know who this quote is from, but clearly this show a >mis-understanding. >There should be no "after" handoff. A seamless handoff will not have a >before >and after. A big part of QoS to mobiles is making the handoff seamless. > >-pdn > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 11:51:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25740 for ; Sun, 31 Mar 2002 11:51:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00422 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 11:51:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29321; Sun, 31 Mar 2002 11:29:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29292 for ; Sun, 31 Mar 2002 11:29:38 -0500 (EST) Received: from hotmail.com (f89.law7.hotmail.com [216.33.237.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25139 for ; Sun, 31 Mar 2002 11:29:35 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Mar 2002 08:29:04 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Sun, 31 Mar 2002 16:29:04 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 16:29:04 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Mar 2002 16:29:04.0835 (UTC) FILETIME=[2C6F7130:01C1D8D1] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Hi: You are right, there is not one point in time that can probably be identified as handoff event in seamless handoffs. But, I think, in spirit, this means that NSIS protocol may no go looking for which access router is the best one for MN's handoff. Rather it will take the target access router as input and *establish* QoS from there. Hemant >From: "Phil Neumiller" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Sun, 31 Mar 2002 06:10:33 -0500 > >Interesting... >----- Original Message ----- >From: "Hemant Chaskar" >To: >Sent: Sunday, March 31, 2002 3:12 AM >Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hi: > > > > As far as delegating QoS aspects of smooth handoff to NSIS is >considered, > > the following statement that was discussed in the WG catches my >attention > > when reading NSIS (rough) meeting minutes from IETF53. > > > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > > sources should be out of the scope of the NSIS. Thus the WG should >rather > > focus only on "establishing" QoS after hand off." > >Don't know who this quote is from, but clearly this show a >mis-understanding. >There should be no "after" handoff. A seamless handoff will not have a >before >and after. A big part of QoS to mobiles is making the handoff seamless. > >-pdn > > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 13:54:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27505 for ; Sun, 31 Mar 2002 13:54:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04714; Sun, 31 Mar 2002 13:37:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04685 for ; Sun, 31 Mar 2002 13:37:53 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27407 for ; Sun, 31 Mar 2002 13:37:51 -0500 (EST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2VIb4I12150; Sun, 31 Mar 2002 10:37:04 -0800 (PST) Message-ID: <001e01c1d8e2$d4f3f1d0$746015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> <3CA53A81.33174CF0@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 10:35:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Charlie, > I didn't know that NSIS was gearing up to supply the needs > of handovers -- and, in a way, I hope they don't because I > can't follow that many mailing litss. And besides, if smooth > handovers is not part of [seamoby] charter, what is?! > Lastly, I claim that QoS management in the small is a > pretty essential requirement for smooth handovers. > Surely, remote signaling is to be avoided. > Well, we need to confirm this with Allison, but my reading of the Seamoby charter does not include anything on doing QoS for handover. I believe NSIS was established for purposes of consolidating all the QoS for wireless work. Of course, if that isn't covered and the WG wants to expand the charter we could discuss it when we finish our current work items. > This is true, but that's the breaks. A lot of bad things could happen, > and if there is a recognized danger, then we should go with the provisional > short-lived reservations. > Right, well, some of the bad things that can happen are large scale hysterisis in which MNs rythmically switch between cells. There are explicit measures taken in cellular protocols to avoid this kind of behavior (e.g. add and delete power levels for adding or removing BTSs from the active set), because it makes load management difficult. Such nonlinear effects are typical when the time constants between two different but linked processes are an order of magnitude or more different. Of course, simulations are in order here to see if this intuition applies to this particular case, mitigation may be possible and even easy as in the CDMA power level case. BTW, I was not speaking here about, for example, advertising that a particular wireless link was configured with so-and-so much bandwidth capacity. I think that could be useful, for example, in order for an MN to determine whether it wanted to make use of some hotspot support. A specific example, suppose I have two choices for hotspot support, 802.11b at 5 Mbps and Bluetooth at 600 kbps. and suppose that the type of media didnt' allow me to differentiate, ie. I could have 802.11 at a lower or higher rate. The MN could use this information to determine what kind of hotspot media it wanted. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 13:54:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27514 for ; Sun, 31 Mar 2002 13:54:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05053 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 13:54:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04714; Sun, 31 Mar 2002 13:37:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04685 for ; Sun, 31 Mar 2002 13:37:53 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27407 for ; Sun, 31 Mar 2002 13:37:51 -0500 (EST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2VIb4I12150; Sun, 31 Mar 2002 10:37:04 -0800 (PST) Message-ID: <001e01c1d8e2$d4f3f1d0$746015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> <3CA53A81.33174CF0@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 10:35:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hi Charlie, > I didn't know that NSIS was gearing up to supply the needs > of handovers -- and, in a way, I hope they don't because I > can't follow that many mailing litss. And besides, if smooth > handovers is not part of [seamoby] charter, what is?! > Lastly, I claim that QoS management in the small is a > pretty essential requirement for smooth handovers. > Surely, remote signaling is to be avoided. > Well, we need to confirm this with Allison, but my reading of the Seamoby charter does not include anything on doing QoS for handover. I believe NSIS was established for purposes of consolidating all the QoS for wireless work. Of course, if that isn't covered and the WG wants to expand the charter we could discuss it when we finish our current work items. > This is true, but that's the breaks. A lot of bad things could happen, > and if there is a recognized danger, then we should go with the provisional > short-lived reservations. > Right, well, some of the bad things that can happen are large scale hysterisis in which MNs rythmically switch between cells. There are explicit measures taken in cellular protocols to avoid this kind of behavior (e.g. add and delete power levels for adding or removing BTSs from the active set), because it makes load management difficult. Such nonlinear effects are typical when the time constants between two different but linked processes are an order of magnitude or more different. Of course, simulations are in order here to see if this intuition applies to this particular case, mitigation may be possible and even easy as in the CDMA power level case. BTW, I was not speaking here about, for example, advertising that a particular wireless link was configured with so-and-so much bandwidth capacity. I think that could be useful, for example, in order for an MN to determine whether it wanted to make use of some hotspot support. A specific example, suppose I have two choices for hotspot support, 802.11b at 5 Mbps and Bluetooth at 600 kbps. and suppose that the type of media didnt' allow me to differentiate, ie. I could have 802.11 at a lower or higher rate. The MN could use this information to determine what kind of hotspot media it wanted. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 14:20:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28003 for ; Sun, 31 Mar 2002 14:20:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06438; Sun, 31 Mar 2002 14:11:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06411 for ; Sun, 31 Mar 2002 14:11:48 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27849 for ; Sun, 31 Mar 2002 14:11:46 -0500 (EST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2VJBBI12636; Sun, 31 Mar 2002 11:11:12 -0800 (PST) Message-ID: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 11:09:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit So it sounds to me like dynamic QoS negotiation for handover has fallen between the cracks of the WGs. Pat and I will take this point up with Allison. At this time, I would rather not try to add it to our charter because we have a lot to do. Having just jettisoned paging, I think we now have the right number of tasks matched to people who have expressed interest in working on them. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Sunday, March 31, 2002 3:12 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hi: > > As far as delegating QoS aspects of smooth handoff to NSIS is considered, > the following statement that was discussed in the WG catches my attention > when reading NSIS (rough) meeting minutes from IETF53. > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > sources should be out of the scope of the NSIS. Thus the WG should rather > focus only on "establishing" QoS after hand off." > > The following statement from Mobile IP QoS requirements draft (WG document > that has passed the last call) is interesting too: > > [Quote:] "In this document, we assume that the target access router for > MN's handover is already pinned down by other protocols. For > example, Seamoby working group has started work on the candidate > access router discovery protocols [3]. Thus, any QoS-capability > specific negotiations that may affect the handover decision are > outside the scope of QoS solution as such, rather need to be > performed by candidate and target access router selection > protocols." > > BR, > Hemant > > > > >From: "James Kempf" > >To: "Charlie Perkins" > >CC: > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > If one access router has 5 Mb/s available, and another only has > > > 10 Kb/s available, I would like to get my streaming video from > > > the first access router. I might be able to have the choice. > > > > > > >Wouldn't it be better to let the IP QoS signaling protocol handle this? > >I believe this is exactly what NSIS is working on, > >but John Loughny could say more. > > > > > IP is exactly the right place for this to be disseminated, assuming > > > that we even have IP QoS in the first place. > > > >I was speaking of last hop link capacity. I agree that IP is the right > >place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS > >charter also speaks about last hop QoS signaling as well. There is some > >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > >hop, but there has not yet been much work done on it. > > > > > I do not think > > > that this information would typically change much over the > > > 10-150 milliseconds that it "should" take to accomplish a > > > handover. If this is a problem, though, one could define a > > > "special" kind of CAR discovery protocol that makes the > > > candidate access router reserve the bandwidth for 200 milliseconds, > > > or else not claim that it has the bandwidth available. > > > > > > >I did not mean just during the handover. If the information provided by > >the CAR discovery protocol has a lifetime of 200 msec, then if the total > >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell > >during the time between when a mobile node gets its last CAR discovery > >update and when it decides to move to the cell. At that point, the QoS > >due to the new load may be below the decision point where the mobile > >node would want to move into the cell. > > > > jak > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 14:20:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28011 for ; Sun, 31 Mar 2002 14:20:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06697 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 14:20:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06438; Sun, 31 Mar 2002 14:11:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06411 for ; Sun, 31 Mar 2002 14:11:48 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27849 for ; Sun, 31 Mar 2002 14:11:46 -0500 (EST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2VJBBI12636; Sun, 31 Mar 2002 11:11:12 -0800 (PST) Message-ID: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 11:09:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit So it sounds to me like dynamic QoS negotiation for handover has fallen between the cracks of the WGs. Pat and I will take this point up with Allison. At this time, I would rather not try to add it to our charter because we have a lot to do. Having just jettisoned paging, I think we now have the right number of tasks matched to people who have expressed interest in working on them. jak ----- Original Message ----- From: "Hemant Chaskar" To: Sent: Sunday, March 31, 2002 3:12 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hi: > > As far as delegating QoS aspects of smooth handoff to NSIS is considered, > the following statement that was discussed in the WG catches my attention > when reading NSIS (rough) meeting minutes from IETF53. > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > sources should be out of the scope of the NSIS. Thus the WG should rather > focus only on "establishing" QoS after hand off." > > The following statement from Mobile IP QoS requirements draft (WG document > that has passed the last call) is interesting too: > > [Quote:] "In this document, we assume that the target access router for > MN's handover is already pinned down by other protocols. For > example, Seamoby working group has started work on the candidate > access router discovery protocols [3]. Thus, any QoS-capability > specific negotiations that may affect the handover decision are > outside the scope of QoS solution as such, rather need to be > performed by candidate and target access router selection > protocols." > > BR, > Hemant > > > > >From: "James Kempf" > >To: "Charlie Perkins" > >CC: > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > If one access router has 5 Mb/s available, and another only has > > > 10 Kb/s available, I would like to get my streaming video from > > > the first access router. I might be able to have the choice. > > > > > > >Wouldn't it be better to let the IP QoS signaling protocol handle this? > >I believe this is exactly what NSIS is working on, > >but John Loughny could say more. > > > > > IP is exactly the right place for this to be disseminated, assuming > > > that we even have IP QoS in the first place. > > > >I was speaking of last hop link capacity. I agree that IP is the right > >place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS > >charter also speaks about last hop QoS signaling as well. There is some > >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > >hop, but there has not yet been much work done on it. > > > > > I do not think > > > that this information would typically change much over the > > > 10-150 milliseconds that it "should" take to accomplish a > > > handover. If this is a problem, though, one could define a > > > "special" kind of CAR discovery protocol that makes the > > > candidate access router reserve the bandwidth for 200 milliseconds, > > > or else not claim that it has the bandwidth available. > > > > > > >I did not mean just during the handover. If the information provided by > >the CAR discovery protocol has a lifetime of 200 msec, then if the total > >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell > >during the time between when a mobile node gets its last CAR discovery > >update and when it decides to move to the cell. At that point, the QoS > >due to the new load may be below the decision point where the mobile > >node would want to move into the cell. > > > > jak > > > > > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 16:24:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29236 for ; Sun, 31 Mar 2002 16:24:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10952; Sun, 31 Mar 2002 16:10:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10922 for ; Sun, 31 Mar 2002 16:10:05 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29152 for ; Sun, 31 Mar 2002 16:10:02 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA13221; Sun, 31 Mar 2002 13:09:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2VL9VK10268; Sun, 31 Mar 2002 13:09:31 -0800 X-mProtect: <200203312109> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCLViLe; Sun, 31 Mar 2002 13:09:28 PST Message-ID: <3CA77B0E.50FB4E20@iprg.nokia.com> Date: Sun, 31 Mar 2002 13:09:34 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Hemant Chaskar , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Jim, I'd like to suggest that QoS handover is not the same as QoS negotiation. For handover, we can assume that the service is authorized and that there is a routing path available at least as far as the current access router. In the general case (e.g., NSIS(?)), these assumptions are not valid. Furthermore, having handovers that do not preserve some agreed-upon bandwidth or delay parameters might be about as interesting as transport in only the passenger side of the CAR. Lastly, we have already some evidence that handing QoS from one access router to another access router is about the same as handing any other context between routers -- again, under the assumption that the basic authorization has already been negotiated at some time in the past. There is no need to have two protocols where one is better, regardless of political divisions within the IETF. Regards, Charlie P. James Kempf wrote: > So it sounds to me like dynamic QoS negotiation for handover has fallen > between the cracks of the WGs. > > Pat and I will take this point up with Allison. At this time, I would > rather not try to add it to our charter because we have a lot to do. > Having just jettisoned paging, I think we now have the right number of > tasks matched to people who have expressed interest in working on them. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: > Sent: Sunday, March 31, 2002 3:12 AM > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hi: > > > > As far as delegating QoS aspects of smooth handoff to NSIS is > considered, > > the following statement that was discussed in the WG catches my > attention > > when reading NSIS (rough) meeting minutes from IETF53. > > > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > > sources should be out of the scope of the NSIS. Thus the WG should > rather > > focus only on "establishing" QoS after hand off." > > > > The following statement from Mobile IP QoS requirements draft (WG > document > > that has passed the last call) is interesting too: > > > > [Quote:] "In this document, we assume that the target access router > for > > MN's handover is already pinned down by other protocols. For > > example, Seamoby working group has started work on the candidate > > access router discovery protocols [3]. Thus, any QoS-capability > > specific negotiations that may affect the handover decision are > > outside the scope of QoS solution as such, rather need to be > > performed by candidate and target access router selection > > protocols." > > > > BR, > > Hemant > > > > > > > > >From: "James Kempf" > > >To: "Charlie Perkins" > > >CC: > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > > > If one access router has 5 Mb/s available, and another only has > > > > 10 Kb/s available, I would like to get my streaming video from > > > > the first access router. I might be able to have the choice. > > > > > > > > > >Wouldn't it be better to let the IP QoS signaling protocol handle > this? > > >I believe this is exactly what NSIS is working on, > > >but John Loughny could say more. > > > > > > > IP is exactly the right place for this to be disseminated, > assuming > > > > that we even have IP QoS in the first place. > > > > > >I was speaking of last hop link capacity. I agree that IP is the > right > > >place to handle next to last hop QoS (i.e. DiffServ). I believe the > NSIS > > >charter also speaks about last hop QoS signaling as well. There is > some > > >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > > >hop, but there has not yet been much work done on it. > > > > > > > I do not think > > > > that this information would typically change much over the > > > > 10-150 milliseconds that it "should" take to accomplish a > > > > handover. If this is a problem, though, one could define a > > > > "special" kind of CAR discovery protocol that makes the > > > > candidate access router reserve the bandwidth for 200 > milliseconds, > > > > or else not claim that it has the bandwidth available. > > > > > > > > > >I did not mean just during the handover. If the information provided > by > > >the CAR discovery protocol has a lifetime of 200 msec, then if the > total > > >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the > cell > > >during the time between when a mobile node gets its last CAR > discovery > > >update and when it decides to move to the cell. At that point, the > QoS > > >due to the new load may be below the decision point where the mobile > > >node would want to move into the cell. > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 16:24:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29246 for ; Sun, 31 Mar 2002 16:24:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11175 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 16:24:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10952; Sun, 31 Mar 2002 16:10:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10922 for ; Sun, 31 Mar 2002 16:10:05 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29152 for ; Sun, 31 Mar 2002 16:10:02 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA13221; Sun, 31 Mar 2002 13:09:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2VL9VK10268; Sun, 31 Mar 2002 13:09:31 -0800 X-mProtect: <200203312109> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCLViLe; Sun, 31 Mar 2002 13:09:28 PST Message-ID: <3CA77B0E.50FB4E20@iprg.nokia.com> Date: Sun, 31 Mar 2002 13:09:34 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Hemant Chaskar , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Jim, I'd like to suggest that QoS handover is not the same as QoS negotiation. For handover, we can assume that the service is authorized and that there is a routing path available at least as far as the current access router. In the general case (e.g., NSIS(?)), these assumptions are not valid. Furthermore, having handovers that do not preserve some agreed-upon bandwidth or delay parameters might be about as interesting as transport in only the passenger side of the CAR. Lastly, we have already some evidence that handing QoS from one access router to another access router is about the same as handing any other context between routers -- again, under the assumption that the basic authorization has already been negotiated at some time in the past. There is no need to have two protocols where one is better, regardless of political divisions within the IETF. Regards, Charlie P. James Kempf wrote: > So it sounds to me like dynamic QoS negotiation for handover has fallen > between the cracks of the WGs. > > Pat and I will take this point up with Allison. At this time, I would > rather not try to add it to our charter because we have a lot to do. > Having just jettisoned paging, I think we now have the right number of > tasks matched to people who have expressed interest in working on them. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: > Sent: Sunday, March 31, 2002 3:12 AM > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hi: > > > > As far as delegating QoS aspects of smooth handoff to NSIS is > considered, > > the following statement that was discussed in the WG catches my > attention > > when reading NSIS (rough) meeting minutes from IETF53. > > > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > > sources should be out of the scope of the NSIS. Thus the WG should > rather > > focus only on "establishing" QoS after hand off." > > > > The following statement from Mobile IP QoS requirements draft (WG > document > > that has passed the last call) is interesting too: > > > > [Quote:] "In this document, we assume that the target access router > for > > MN's handover is already pinned down by other protocols. For > > example, Seamoby working group has started work on the candidate > > access router discovery protocols [3]. Thus, any QoS-capability > > specific negotiations that may affect the handover decision are > > outside the scope of QoS solution as such, rather need to be > > performed by candidate and target access router selection > > protocols." > > > > BR, > > Hemant > > > > > > > > >From: "James Kempf" > > >To: "Charlie Perkins" > > >CC: > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > > > If one access router has 5 Mb/s available, and another only has > > > > 10 Kb/s available, I would like to get my streaming video from > > > > the first access router. I might be able to have the choice. > > > > > > > > > >Wouldn't it be better to let the IP QoS signaling protocol handle > this? > > >I believe this is exactly what NSIS is working on, > > >but John Loughny could say more. > > > > > > > IP is exactly the right place for this to be disseminated, > assuming > > > > that we even have IP QoS in the first place. > > > > > >I was speaking of last hop link capacity. I agree that IP is the > right > > >place to handle next to last hop QoS (i.e. DiffServ). I believe the > NSIS > > >charter also speaks about last hop QoS signaling as well. There is > some > > >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > > >hop, but there has not yet been much work done on it. > > > > > > > I do not think > > > > that this information would typically change much over the > > > > 10-150 milliseconds that it "should" take to accomplish a > > > > handover. If this is a problem, though, one could define a > > > > "special" kind of CAR discovery protocol that makes the > > > > candidate access router reserve the bandwidth for 200 > milliseconds, > > > > or else not claim that it has the bandwidth available. > > > > > > > > > >I did not mean just during the handover. If the information provided > by > > >the CAR discovery protocol has a lifetime of 200 msec, then if the > total > > >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the > cell > > >during the time between when a mobile node gets its last CAR > discovery > > >update and when it decides to move to the cell. At that point, the > QoS > > >due to the new load may be below the decision point where the mobile > > >node would want to move into the cell. > > > > > > jak > > > > > > > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 20:51:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01525 for ; Sun, 31 Mar 2002 20:51:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21179; Sun, 31 Mar 2002 20:42:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21148 for ; Sun, 31 Mar 2002 20:42:13 -0500 (EST) Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01431 for ; Sun, 31 Mar 2002 20:42:11 -0500 (EST) Received: (cpmta 3077 invoked from network); 31 Mar 2002 17:41:41 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.222) with SMTP; 31 Mar 2002 17:41:41 -0800 X-Sent: 1 Apr 2002 01:41:41 GMT Message-ID: <000f01c1d91e$60d395d0$0902a8c0@Study> From: "Phil Neumiller" To: "Charlie Perkins" , "James Kempf" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 20:41:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit This seems pretty strange to me too Jim. I hate to say it, but the IETF is showing some wireless ignorance here. The MOST important thing SeaMoby could ever do in the IETF is to facility seamless/smooth/soft/fluffy handoff. This is an ESSENTIAL part of QoS. I have not followed the NSIS mailing list, but it sounds pretty misguided to me. What is SeaMoby chopped liver??? Thanks, Phil ----- Original Message ----- From: "Charlie Perkins" To: "James Kempf" Cc: "Hemant Chaskar" ; Sent: Sunday, March 31, 2002 4:09 PM Subject: Re: [Seamoby] Examples of CAR discovery > > Hello Jim, > > I'd like to suggest that QoS handover is not the same as QoS negotiation. > For handover, we can assume that the service is authorized and that > there is a routing path available at least as far as the current access > router. In the general case (e.g., NSIS(?)), these assumptions are not > valid. > > Furthermore, having handovers that do not preserve some agreed-upon > bandwidth or delay parameters might be about as interesting as transport > in only the passenger side of the CAR. > > Lastly, we have already some evidence that handing QoS from one > access router to another access router is about the same as handing > any other context between routers -- again, under the assumption that > the basic authorization has already been negotiated at some time in > the past. There is no need to have two protocols where one is better, > regardless of political divisions within the IETF. > > Regards, > Charlie P. > > > > James Kempf wrote: > > > So it sounds to me like dynamic QoS negotiation for handover has fallen > > between the cracks of the WGs. > > > > Pat and I will take this point up with Allison. At this time, I would > > rather not try to add it to our charter because we have a lot to do. > > Having just jettisoned paging, I think we now have the right number of > > tasks matched to people who have expressed interest in working on them. > > > > jak > > > > ----- Original Message ----- > > From: "Hemant Chaskar" > > To: > > Sent: Sunday, March 31, 2002 3:12 AM > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > Hi: > > > > > > As far as delegating QoS aspects of smooth handoff to NSIS is > > considered, > > > the following statement that was discussed in the WG catches my > > attention > > > when reading NSIS (rough) meeting minutes from IETF53. > > > > > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > > > sources should be out of the scope of the NSIS. Thus the WG should > > rather > > > focus only on "establishing" QoS after hand off." > > > > > > The following statement from Mobile IP QoS requirements draft (WG > > document > > > that has passed the last call) is interesting too: > > > > > > [Quote:] "In this document, we assume that the target access router > > for > > > MN's handover is already pinned down by other protocols. For > > > example, Seamoby working group has started work on the candidate > > > access router discovery protocols [3]. Thus, any QoS-capability > > > specific negotiations that may affect the handover decision are > > > outside the scope of QoS solution as such, rather need to be > > > performed by candidate and target access router selection > > > protocols." > > > > > > BR, > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > >To: "Charlie Perkins" > > > >CC: > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > > > > > If one access router has 5 Mb/s available, and another only has > > > > > 10 Kb/s available, I would like to get my streaming video from > > > > > the first access router. I might be able to have the choice. > > > > > > > > > > > > >Wouldn't it be better to let the IP QoS signaling protocol handle > > this? > > > >I believe this is exactly what NSIS is working on, > > > >but John Loughny could say more. > > > > > > > > > IP is exactly the right place for this to be disseminated, > > assuming > > > > > that we even have IP QoS in the first place. > > > > > > > >I was speaking of last hop link capacity. I agree that IP is the > > right > > > >place to handle next to last hop QoS (i.e. DiffServ). I believe the > > NSIS > > > >charter also speaks about last hop QoS signaling as well. There is > > some > > > >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > > > >hop, but there has not yet been much work done on it. > > > > > > > > > I do not think > > > > > that this information would typically change much over the > > > > > 10-150 milliseconds that it "should" take to accomplish a > > > > > handover. If this is a problem, though, one could define a > > > > > "special" kind of CAR discovery protocol that makes the > > > > > candidate access router reserve the bandwidth for 200 > > milliseconds, > > > > > or else not claim that it has the bandwidth available. > > > > > > > > > > > > >I did not mean just during the handover. If the information provided > > by > > > >the CAR discovery protocol has a lifetime of 200 msec, then if the > > total > > > >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the > > cell > > > >during the time between when a mobile node gets its last CAR > > discovery > > > >update and when it decides to move to the cell. At that point, the > > QoS > > > >due to the new load may be below the decision point where the mobile > > > >node would want to move into the cell. > > > > > > > > jak > > > > > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 20:51:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01535 for ; Sun, 31 Mar 2002 20:51:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA21456 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 20:51:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21179; Sun, 31 Mar 2002 20:42:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21148 for ; Sun, 31 Mar 2002 20:42:13 -0500 (EST) Received: from c007.snv.cp.net (c007-h015.c007.snv.cp.net [209.228.33.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01431 for ; Sun, 31 Mar 2002 20:42:11 -0500 (EST) Received: (cpmta 3077 invoked from network); 31 Mar 2002 17:41:41 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.222) with SMTP; 31 Mar 2002 17:41:41 -0800 X-Sent: 1 Apr 2002 01:41:41 GMT Message-ID: <000f01c1d91e$60d395d0$0902a8c0@Study> From: "Phil Neumiller" To: "Charlie Perkins" , "James Kempf" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 20:41:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit This seems pretty strange to me too Jim. I hate to say it, but the IETF is showing some wireless ignorance here. The MOST important thing SeaMoby could ever do in the IETF is to facility seamless/smooth/soft/fluffy handoff. This is an ESSENTIAL part of QoS. I have not followed the NSIS mailing list, but it sounds pretty misguided to me. What is SeaMoby chopped liver??? Thanks, Phil ----- Original Message ----- From: "Charlie Perkins" To: "James Kempf" Cc: "Hemant Chaskar" ; Sent: Sunday, March 31, 2002 4:09 PM Subject: Re: [Seamoby] Examples of CAR discovery > > Hello Jim, > > I'd like to suggest that QoS handover is not the same as QoS negotiation. > For handover, we can assume that the service is authorized and that > there is a routing path available at least as far as the current access > router. In the general case (e.g., NSIS(?)), these assumptions are not > valid. > > Furthermore, having handovers that do not preserve some agreed-upon > bandwidth or delay parameters might be about as interesting as transport > in only the passenger side of the CAR. > > Lastly, we have already some evidence that handing QoS from one > access router to another access router is about the same as handing > any other context between routers -- again, under the assumption that > the basic authorization has already been negotiated at some time in > the past. There is no need to have two protocols where one is better, > regardless of political divisions within the IETF. > > Regards, > Charlie P. > > > > James Kempf wrote: > > > So it sounds to me like dynamic QoS negotiation for handover has fallen > > between the cracks of the WGs. > > > > Pat and I will take this point up with Allison. At this time, I would > > rather not try to add it to our charter because we have a lot to do. > > Having just jettisoned paging, I think we now have the right number of > > tasks matched to people who have expressed interest in working on them. > > > > jak > > > > ----- Original Message ----- > > From: "Hemant Chaskar" > > To: > > Sent: Sunday, March 31, 2002 3:12 AM > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > Hi: > > > > > > As far as delegating QoS aspects of smooth handoff to NSIS is > > considered, > > > the following statement that was discussed in the WG catches my > > attention > > > when reading NSIS (rough) meeting minutes from IETF53. > > > > > > [Quote:] "Regarding to the mobile IP, the hand of decision and trigger > > > sources should be out of the scope of the NSIS. Thus the WG should > > rather > > > focus only on "establishing" QoS after hand off." > > > > > > The following statement from Mobile IP QoS requirements draft (WG > > document > > > that has passed the last call) is interesting too: > > > > > > [Quote:] "In this document, we assume that the target access router > > for > > > MN's handover is already pinned down by other protocols. For > > > example, Seamoby working group has started work on the candidate > > > access router discovery protocols [3]. Thus, any QoS-capability > > > specific negotiations that may affect the handover decision are > > > outside the scope of QoS solution as such, rather need to be > > > performed by candidate and target access router selection > > > protocols." > > > > > > BR, > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > >To: "Charlie Perkins" > > > >CC: > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > > > > > If one access router has 5 Mb/s available, and another only has > > > > > 10 Kb/s available, I would like to get my streaming video from > > > > > the first access router. I might be able to have the choice. > > > > > > > > > > > > >Wouldn't it be better to let the IP QoS signaling protocol handle > > this? > > > >I believe this is exactly what NSIS is working on, > > > >but John Loughny could say more. > > > > > > > > > IP is exactly the right place for this to be disseminated, > > assuming > > > > > that we even have IP QoS in the first place. > > > > > > > >I was speaking of last hop link capacity. I agree that IP is the > > right > > > >place to handle next to last hop QoS (i.e. DiffServ). I believe the > > NSIS > > > >charter also speaks about last hop QoS signaling as well. There is > > some > > > >interest in NSIS to tie Layer 2 QoS and IP QoS together on the last > > > >hop, but there has not yet been much work done on it. > > > > > > > > > I do not think > > > > > that this information would typically change much over the > > > > > 10-150 milliseconds that it "should" take to accomplish a > > > > > handover. If this is a problem, though, one could define a > > > > > "special" kind of CAR discovery protocol that makes the > > > > > candidate access router reserve the bandwidth for 200 > > milliseconds, > > > > > or else not claim that it has the bandwidth available. > > > > > > > > > > > > >I did not mean just during the handover. If the information provided > > by > > > >the CAR discovery protocol has a lifetime of 200 msec, then if the > > total > > > >L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the > > cell > > > >during the time between when a mobile node gets its last CAR > > discovery > > > >update and when it decides to move to the cell. At that point, the > > QoS > > > >due to the new load may be below the decision point where the mobile > > > >node would want to move into the cell. > > > > > > > > jak > > > > > > > > > > > > > > > >_______________________________________________ > > > >Seamoby mailing list > > > >Seamoby@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 20:56:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01614 for ; Sun, 31 Mar 2002 20:56:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21318; Sun, 31 Mar 2002 20:47:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21287 for ; Sun, 31 Mar 2002 20:47:10 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01484 for ; Sun, 31 Mar 2002 20:47:08 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-351.cisco.com [10.82.225.95]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA15096; Sun, 31 Mar 2002 17:46:38 -0800 (PST) Message-Id: <4.3.2.7.2.20020331204356.018f8198@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 31 Mar 2002 20:46:06 -0500 To: "Phil Neumiller" From: John Schnizlein Subject: Re: [Seamoby] Examples of CAR discovery Cc: In-Reply-To: <000f01c1d91e$60d395d0$0902a8c0@Study> References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org At 08:41 PM 3/31/2002, Phil Neumiller wrote: >... What is SeaMoby chopped liver??? Please keep up .. "What [is SeaMoby] a potted plant?" What do you expect on Easter evening? John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 20:56:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01623 for ; Sun, 31 Mar 2002 20:56:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA21632 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 20:56:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21318; Sun, 31 Mar 2002 20:47:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21287 for ; Sun, 31 Mar 2002 20:47:10 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01484 for ; Sun, 31 Mar 2002 20:47:08 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-351.cisco.com [10.82.225.95]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA15096; Sun, 31 Mar 2002 17:46:38 -0800 (PST) Message-Id: <4.3.2.7.2.20020331204356.018f8198@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 31 Mar 2002 20:46:06 -0500 To: "Phil Neumiller" From: John Schnizlein Subject: Re: [Seamoby] Examples of CAR discovery Cc: In-Reply-To: <000f01c1d91e$60d395d0$0902a8c0@Study> References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org At 08:41 PM 3/31/2002, Phil Neumiller wrote: >... What is SeaMoby chopped liver??? Please keep up .. "What [is SeaMoby] a potted plant?" What do you expect on Easter evening? John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 21:22:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01985 for ; Sun, 31 Mar 2002 21:22:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22364; Sun, 31 Mar 2002 21:05:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22335 for ; Sun, 31 Mar 2002 21:05:38 -0500 (EST) Received: from ponyexpress.ee.columbia.edu (IDENT:root@ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01727 for ; Sun, 31 Mar 2002 21:05:32 -0500 (EST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id g3125Ss24494; Sun, 31 Mar 2002 21:05:28 -0500 From: "Andrew T. Campbell" To: "'Phil Neumiller'" , "'Charlie Perkins'" , "'James Kempf'" Cc: "'Hemant Chaskar'" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 21:02:35 -0500 Message-ID: <003501c1d921$4b9bbb90$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000f01c1d91e$60d395d0$0902a8c0@Study> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit NSIS has a very strong mobility dimension to it, which I find very interesting, but odd. And, I agree, completing handoff quickly with optional low loss support is the first order mobile QOS. Second order, is much harder. It requires a good model of resources in the network and how to allocate/re-allocate or engineer them in support of tighter QOS contol (delay, bandwidth). But as we see, with all QOS initiatives in IETF there is a lot of activity and out put but incentives for carriers to deploy it. Its just a very hard problem. Question is why do you need QOS signaling when the network has no QOS? You certainly need some signaling for handoff. --- Andrew http://comet.columbia.edu/~campbell > -----Original Message----- > From: seamoby-admin@ietf.org > [mailto:seamoby-admin@ietf.org]On Behalf Of > Phil Neumiller > Sent: Sunday, March 31, 2002 8:42 PM > To: Charlie Perkins; James Kempf > Cc: Hemant Chaskar; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > This seems pretty strange to me too Jim. I hate to say it, > but the IETF is > showing some > wireless ignorance here. The MOST important thing SeaMoby > could ever do in > the IETF is to facility seamless/smooth/soft/fluffy handoff. > This is an > ESSENTIAL > part of QoS. I have not followed the NSIS mailing list, but it sounds > pretty misguided > to me. What is SeaMoby chopped liver??? > > Thanks, > > Phil > ----- Original Message ----- > From: "Charlie Perkins" > To: "James Kempf" > Cc: "Hemant Chaskar" ; > Sent: Sunday, March 31, 2002 4:09 PM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hello Jim, > > > > I'd like to suggest that QoS handover is not the same as > QoS negotiation. > > For handover, we can assume that the service is authorized and that > > there is a routing path available at least as far as the > current access > > router. In the general case (e.g., NSIS(?)), these > assumptions are not > > valid. > > > > Furthermore, having handovers that do not preserve some agreed-upon > > bandwidth or delay parameters might be about as interesting > as transport > > in only the passenger side of the CAR. > > > > Lastly, we have already some evidence that handing QoS from one > > access router to another access router is about the same as handing > > any other context between routers -- again, under the > assumption that > > the basic authorization has already been negotiated at some time in > > the past. There is no need to have two protocols where one > is better, > > regardless of political divisions within the IETF. > > > > Regards, > > Charlie P. > > > > > > > > James Kempf wrote: > > > > > So it sounds to me like dynamic QoS negotiation for > handover has fallen > > > between the cracks of the WGs. > > > > > > Pat and I will take this point up with Allison. At this > time, I would > > > rather not try to add it to our charter because we have a > lot to do. > > > Having just jettisoned paging, I think we now have the > right number of > > > tasks matched to people who have expressed interest in > working on them. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Hemant Chaskar" > > > To: > > > Sent: Sunday, March 31, 2002 3:12 AM > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi: > > > > > > > > As far as delegating QoS aspects of smooth handoff to NSIS is > > > considered, > > > > the following statement that was discussed in the WG catches my > > > attention > > > > when reading NSIS (rough) meeting minutes from IETF53. > > > > > > > > [Quote:] "Regarding to the mobile IP, the hand of > decision and trigger > > > > sources should be out of the scope of the NSIS. Thus > the WG should > > > rather > > > > focus only on "establishing" QoS after hand off." > > > > > > > > The following statement from Mobile IP QoS requirements > draft (WG > > > document > > > > that has passed the last call) is interesting too: > > > > > > > > [Quote:] "In this document, we assume that the target > access router > > > for > > > > MN's handover is already pinned down by other protocols. For > > > > example, Seamoby working group has started work on > the candidate > > > > access router discovery protocols [3]. Thus, any > QoS-capability > > > > specific negotiations that may affect the handover > decision are > > > > outside the scope of QoS solution as such, rather need to be > > > > performed by candidate and target access router selection > > > > protocols." > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Charlie Perkins" > > > > >CC: > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > > > > > > > If one access router has 5 Mb/s available, and > another only has > > > > > > 10 Kb/s available, I would like to get my streaming > video from > > > > > > the first access router. I might be able to have > the choice. > > > > > > > > > > > > > > > >Wouldn't it be better to let the IP QoS signaling > protocol handle > > > this? > > > > >I believe this is exactly what NSIS is working on, > > > > >but John Loughny could say more. > > > > > > > > > > > IP is exactly the right place for this to be disseminated, > > > assuming > > > > > > that we even have IP QoS in the first place. > > > > > > > > > >I was speaking of last hop link capacity. I agree that > IP is the > > > right > > > > >place to handle next to last hop QoS (i.e. DiffServ). > I believe the > > > NSIS > > > > >charter also speaks about last hop QoS signaling as > well. There is > > > some > > > > >interest in NSIS to tie Layer 2 QoS and IP QoS > together on the last > > > > >hop, but there has not yet been much work done on it. > > > > > > > > > > > I do not think > > > > > > that this information would typically change much over the > > > > > > 10-150 milliseconds that it "should" take to accomplish a > > > > > > handover. If this is a problem, though, one could define a > > > > > > "special" kind of CAR discovery protocol that makes the > > > > > > candidate access router reserve the bandwidth for 200 > > > milliseconds, > > > > > > or else not claim that it has the bandwidth available. > > > > > > > > > > > > > > > >I did not mean just during the handover. If the > information provided > > > by > > > > >the CAR discovery protocol has a lifetime of 200 msec, > then if the > > > total > > > > >L2 + L3 handover time is 40 ms, 5 mobile nodes could > move into the > > > cell > > > > >during the time between when a mobile node gets its last CAR > > > discovery > > > > >update and when it decides to move to the cell. At > that point, the > > > QoS > > > > >due to the new load may be below the decision point > where the mobile > > > > >node would want to move into the cell. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 21:22:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01995 for ; Sun, 31 Mar 2002 21:22:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA22919 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 21:22:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22364; Sun, 31 Mar 2002 21:05:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22335 for ; Sun, 31 Mar 2002 21:05:38 -0500 (EST) Received: from ponyexpress.ee.columbia.edu (IDENT:root@ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01727 for ; Sun, 31 Mar 2002 21:05:32 -0500 (EST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id g3125Ss24494; Sun, 31 Mar 2002 21:05:28 -0500 From: "Andrew T. Campbell" To: "'Phil Neumiller'" , "'Charlie Perkins'" , "'James Kempf'" Cc: "'Hemant Chaskar'" , Subject: RE: [Seamoby] Examples of CAR discovery Date: Sun, 31 Mar 2002 21:02:35 -0500 Message-ID: <003501c1d921$4b9bbb90$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000f01c1d91e$60d395d0$0902a8c0@Study> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit NSIS has a very strong mobility dimension to it, which I find very interesting, but odd. And, I agree, completing handoff quickly with optional low loss support is the first order mobile QOS. Second order, is much harder. It requires a good model of resources in the network and how to allocate/re-allocate or engineer them in support of tighter QOS contol (delay, bandwidth). But as we see, with all QOS initiatives in IETF there is a lot of activity and out put but incentives for carriers to deploy it. Its just a very hard problem. Question is why do you need QOS signaling when the network has no QOS? You certainly need some signaling for handoff. --- Andrew http://comet.columbia.edu/~campbell > -----Original Message----- > From: seamoby-admin@ietf.org > [mailto:seamoby-admin@ietf.org]On Behalf Of > Phil Neumiller > Sent: Sunday, March 31, 2002 8:42 PM > To: Charlie Perkins; James Kempf > Cc: Hemant Chaskar; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > This seems pretty strange to me too Jim. I hate to say it, > but the IETF is > showing some > wireless ignorance here. The MOST important thing SeaMoby > could ever do in > the IETF is to facility seamless/smooth/soft/fluffy handoff. > This is an > ESSENTIAL > part of QoS. I have not followed the NSIS mailing list, but it sounds > pretty misguided > to me. What is SeaMoby chopped liver??? > > Thanks, > > Phil > ----- Original Message ----- > From: "Charlie Perkins" > To: "James Kempf" > Cc: "Hemant Chaskar" ; > Sent: Sunday, March 31, 2002 4:09 PM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hello Jim, > > > > I'd like to suggest that QoS handover is not the same as > QoS negotiation. > > For handover, we can assume that the service is authorized and that > > there is a routing path available at least as far as the > current access > > router. In the general case (e.g., NSIS(?)), these > assumptions are not > > valid. > > > > Furthermore, having handovers that do not preserve some agreed-upon > > bandwidth or delay parameters might be about as interesting > as transport > > in only the passenger side of the CAR. > > > > Lastly, we have already some evidence that handing QoS from one > > access router to another access router is about the same as handing > > any other context between routers -- again, under the > assumption that > > the basic authorization has already been negotiated at some time in > > the past. There is no need to have two protocols where one > is better, > > regardless of political divisions within the IETF. > > > > Regards, > > Charlie P. > > > > > > > > James Kempf wrote: > > > > > So it sounds to me like dynamic QoS negotiation for > handover has fallen > > > between the cracks of the WGs. > > > > > > Pat and I will take this point up with Allison. At this > time, I would > > > rather not try to add it to our charter because we have a > lot to do. > > > Having just jettisoned paging, I think we now have the > right number of > > > tasks matched to people who have expressed interest in > working on them. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Hemant Chaskar" > > > To: > > > Sent: Sunday, March 31, 2002 3:12 AM > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > Hi: > > > > > > > > As far as delegating QoS aspects of smooth handoff to NSIS is > > > considered, > > > > the following statement that was discussed in the WG catches my > > > attention > > > > when reading NSIS (rough) meeting minutes from IETF53. > > > > > > > > [Quote:] "Regarding to the mobile IP, the hand of > decision and trigger > > > > sources should be out of the scope of the NSIS. Thus > the WG should > > > rather > > > > focus only on "establishing" QoS after hand off." > > > > > > > > The following statement from Mobile IP QoS requirements > draft (WG > > > document > > > > that has passed the last call) is interesting too: > > > > > > > > [Quote:] "In this document, we assume that the target > access router > > > for > > > > MN's handover is already pinned down by other protocols. For > > > > example, Seamoby working group has started work on > the candidate > > > > access router discovery protocols [3]. Thus, any > QoS-capability > > > > specific negotiations that may affect the handover > decision are > > > > outside the scope of QoS solution as such, rather need to be > > > > performed by candidate and target access router selection > > > > protocols." > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Charlie Perkins" > > > > >CC: > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Fri, 29 Mar 2002 19:10:03 -0800 > > > > > > > > > > > If one access router has 5 Mb/s available, and > another only has > > > > > > 10 Kb/s available, I would like to get my streaming > video from > > > > > > the first access router. I might be able to have > the choice. > > > > > > > > > > > > > > > >Wouldn't it be better to let the IP QoS signaling > protocol handle > > > this? > > > > >I believe this is exactly what NSIS is working on, > > > > >but John Loughny could say more. > > > > > > > > > > > IP is exactly the right place for this to be disseminated, > > > assuming > > > > > > that we even have IP QoS in the first place. > > > > > > > > > >I was speaking of last hop link capacity. I agree that > IP is the > > > right > > > > >place to handle next to last hop QoS (i.e. DiffServ). > I believe the > > > NSIS > > > > >charter also speaks about last hop QoS signaling as > well. There is > > > some > > > > >interest in NSIS to tie Layer 2 QoS and IP QoS > together on the last > > > > >hop, but there has not yet been much work done on it. > > > > > > > > > > > I do not think > > > > > > that this information would typically change much over the > > > > > > 10-150 milliseconds that it "should" take to accomplish a > > > > > > handover. If this is a problem, though, one could define a > > > > > > "special" kind of CAR discovery protocol that makes the > > > > > > candidate access router reserve the bandwidth for 200 > > > milliseconds, > > > > > > or else not claim that it has the bandwidth available. > > > > > > > > > > > > > > > >I did not mean just during the handover. If the > information provided > > > by > > > > >the CAR discovery protocol has a lifetime of 200 msec, > then if the > > > total > > > > >L2 + L3 handover time is 40 ms, 5 mobile nodes could > move into the > > > cell > > > > >during the time between when a mobile node gets its last CAR > > > discovery > > > > >update and when it decides to move to the cell. At > that point, the > > > QoS > > > > >due to the new load may be below the decision point > where the mobile > > > > >node would want to move into the cell. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >Seamoby mailing list > > > > >Seamoby@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Mar 31 21:53:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03331 for ; Sun, 31 Mar 2002 21:53:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24024; Sun, 31 Mar 2002 21:44:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23959 for ; Sun, 31 Mar 2002 21:44:07 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03241 for ; Sun, 31 Mar 2002 21:44:05 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA20701; Sun, 31 Mar 2002 18:43:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g312hUa09516; Sun, 31 Mar 2002 18:43:30 -0800 X-mProtect: <200204010243> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdj8ujxP; Sun, 31 Mar 2002 18:43:27 PST Message-ID: <3CA7C955.20F194F5@iprg.nokia.com> Date: Sun, 31 Mar 2002 18:43:33 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew T. Campbell" CC: "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <003501c1d921$4b9bbb90$ca413b80@SWEETPEA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Andrew, "Andrew T. Campbell" wrote: > And, I agree, completing handoff quickly with > optional low loss support is the first order > mobile QOS. What does "loss" mean? > Second order, is much harder. It requires a good > model of resources in the network and how to > allocate/re-allocate or engineer them in > support of tighter QOS contol (delay, bandwidth). Maybe not! If we have a good "discovery" protocol, and we have suboptions to say what it is that we want to discover from possibly neighboring access points, then we can leave it for later to define the data formats for the suboptions. Furthermore, any other strategy which commingles data and control flow is, in my opinion, headed towards failure. > But as we see, with all QOS initiatives in IETF > there is a lot of activity and out put > but incentives for carriers to deploy it. I could not parse this! Is there a "no" before "incentives"? > Its just a very hard problem. Question is why > do you need QOS signaling when the network > has no QOS? If "the network" has no QoS, then it cannot satisfy any request which mandates it. That's clear. If a request is preferential for appropriate QoS but does not mandate it, then the rules have to make it clear when the CAR discovery can still succeed if there is no QoS to satisfy the preferential request. Maybe the participants in this discussion would agree that we cannot boil the QoS ocean, but I wish we could still make a localized protocol that does a small *but essential* job -- and it's a job for [seamoby], in my opinion. > You certainly need some signaling for handoff. Agreed! Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Mar 31 21:53:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03340 for ; Sun, 31 Mar 2002 21:53:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA24246 for seamoby-archive@odin.ietf.org; Sun, 31 Mar 2002 21:53:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24024; Sun, 31 Mar 2002 21:44:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23959 for ; Sun, 31 Mar 2002 21:44:07 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03241 for ; Sun, 31 Mar 2002 21:44:05 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA20701; Sun, 31 Mar 2002 18:43:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g312hUa09516; Sun, 31 Mar 2002 18:43:30 -0800 X-mProtect: <200204010243> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdj8ujxP; Sun, 31 Mar 2002 18:43:27 PST Message-ID: <3CA7C955.20F194F5@iprg.nokia.com> Date: Sun, 31 Mar 2002 18:43:33 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew T. Campbell" CC: "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <003501c1d921$4b9bbb90$ca413b80@SWEETPEA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Hello Andrew, "Andrew T. Campbell" wrote: > And, I agree, completing handoff quickly with > optional low loss support is the first order > mobile QOS. What does "loss" mean? > Second order, is much harder. It requires a good > model of resources in the network and how to > allocate/re-allocate or engineer them in > support of tighter QOS contol (delay, bandwidth). Maybe not! If we have a good "discovery" protocol, and we have suboptions to say what it is that we want to discover from possibly neighboring access points, then we can leave it for later to define the data formats for the suboptions. Furthermore, any other strategy which commingles data and control flow is, in my opinion, headed towards failure. > But as we see, with all QOS initiatives in IETF > there is a lot of activity and out put > but incentives for carriers to deploy it. I could not parse this! Is there a "no" before "incentives"? > Its just a very hard problem. Question is why > do you need QOS signaling when the network > has no QOS? If "the network" has no QoS, then it cannot satisfy any request which mandates it. That's clear. If a request is preferential for appropriate QoS but does not mandate it, then the rules have to make it clear when the CAR discovery can still succeed if there is no QoS to satisfy the preferential request. Maybe the participants in this discussion would agree that we cannot boil the QoS ocean, but I wish we could still make a localized protocol that does a small *but essential* job -- and it's a job for [seamoby], in my opinion. > You certainly need some signaling for handoff. Agreed! Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby