From seamoby-admin@ietf.org Mon Apr 1 03:59: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 DAA04783 for ; Mon, 1 Apr 2002 03:59: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 DAA19307; Mon, 1 Apr 2002 03:32: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 DAA19278 for ; Mon, 1 Apr 2002 03:32:50 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02381 for ; Mon, 1 Apr 2002 03:32:49 -0500 (EST) Received: from pyegani-w2k2.cisco.com (sjc-vpn1-513.cisco.com [10.21.98.1]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id AAA10820; Mon, 1 Apr 2002 00:32:01 -0800 (PST) Message-Id: <4.3.2.7.2.20020331235625.03fd43e8@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Apr 2002 00:32:00 -0800 To: "James Kempf" , "Charlie Perkins" From: Parviz Yegani Subject: Re: [Seamoby] Examples of CAR discovery Cc: In-Reply-To: <001e01c1d8e2$d4f3f1d0$746015ac@T23KEMPF> References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> <3CA53A81.33174CF0@iprg.nokia.com> 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 Hi Jim, Comments inline... At 10:35 AM 3/31/2002 -0800, James Kempf wrote: >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. What do you mean by "QoS for handover"? Are there any requirements defined for this in IETF? I hope this will be done in Seamoby. As Charlie said there are too many mailing lists and it's very hard for one to follow all the email discussions on these lists. >I >believe NSIS was established for purposes of consolidating all the QoS >for wireless work. Could you please briefly tell us what NSIS is supposed to accomplish as far as QoS for wireless is concerned? As you may both 3GPP and 3GPP2 folks are working on an end-to-end QoS solution for mobile wireless systems and applications (beyond 3G). In this work we are heavily relying on the IETF existing protocols. It would be interesting to know if IETF is going to standardize yet another protocol specifically tailored/designed for wireless applications. Thanks, Parviz >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 _________________ Parviz Yegani, Ph.D. Mobile Wireless Group Cisco Systems 3625 Cisco Way San Jose, CA 95134 (408) 853-9018 (voice) (408) 832-5729 (mobile) (408) 853-3543 (fax) Email: pyegani@cisco.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 1 03:59: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 DAA04797 for ; Mon, 1 Apr 2002 03:59:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19941 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 03:59: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 DAA19307; Mon, 1 Apr 2002 03:32: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 DAA19278 for ; Mon, 1 Apr 2002 03:32:50 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02381 for ; Mon, 1 Apr 2002 03:32:49 -0500 (EST) Received: from pyegani-w2k2.cisco.com (sjc-vpn1-513.cisco.com [10.21.98.1]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id AAA10820; Mon, 1 Apr 2002 00:32:01 -0800 (PST) Message-Id: <4.3.2.7.2.20020331235625.03fd43e8@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Apr 2002 00:32:00 -0800 To: "James Kempf" , "Charlie Perkins" From: Parviz Yegani Subject: Re: [Seamoby] Examples of CAR discovery Cc: In-Reply-To: <001e01c1d8e2$d4f3f1d0$746015ac@T23KEMPF> References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> <3CA53A81.33174CF0@iprg.nokia.com> 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 Hi Jim, Comments inline... At 10:35 AM 3/31/2002 -0800, James Kempf wrote: >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. What do you mean by "QoS for handover"? Are there any requirements defined for this in IETF? I hope this will be done in Seamoby. As Charlie said there are too many mailing lists and it's very hard for one to follow all the email discussions on these lists. >I >believe NSIS was established for purposes of consolidating all the QoS >for wireless work. Could you please briefly tell us what NSIS is supposed to accomplish as far as QoS for wireless is concerned? As you may both 3GPP and 3GPP2 folks are working on an end-to-end QoS solution for mobile wireless systems and applications (beyond 3G). In this work we are heavily relying on the IETF existing protocols. It would be interesting to know if IETF is going to standardize yet another protocol specifically tailored/designed for wireless applications. Thanks, Parviz >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 _________________ Parviz Yegani, Ph.D. Mobile Wireless Group Cisco Systems 3625 Cisco Way San Jose, CA 95134 (408) 853-9018 (voice) (408) 832-5729 (mobile) (408) 853-3543 (fax) Email: pyegani@cisco.com _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailman-owner@ietf.org Mon Apr 1 06:06: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 GAA17174 for ; Mon, 1 Apr 2002 06:06: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 GAA24853 for ; Mon, 1 Apr 2002 06:06:45 -0500 (EST) Date: Mon, 1 Apr 2002 06:06:45 -0500 (EST) Message-Id: <200204011106.GAA24853@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 seamoby-admin@ietf.org Mon Apr 1 10: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 KAA02121 for ; Mon, 1 Apr 2002 10: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 KAA15605; Mon, 1 Apr 2002 10:29: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 KAA15577 for ; Mon, 1 Apr 2002 10:29:46 -0500 (EST) Received: from hotmail.com (f268.law9.hotmail.com [64.4.8.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01591 for ; Mon, 1 Apr 2002 10:29:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 07:29:17 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 15:29:16 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 10:29:16 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 15:29:17.0056 (UTC) FILETIME=[FC5D9000:01C1D991] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, I think that figuring out whether the AR that the MN is going to get IP connectivity from has the necessary QoS support for the MN is in the scope of CAR discovery as this is an IP capability. The second scenario illustrated in the Issues draft as a justification for the need of CAR discovery, is very similar to the example that Charlie pointed out. It talks about the case when a MN moves into a different AR's domain and that AR cannot support the MN's QoS needs. This example from the Issues draft, talks about the MN not connecting to the new AR if the AR cannot support the MN. I therefore think this clearly is a case where CAR discovery is useful. I think that QoS support in the AR is an IP capability of the AR and therefore CAR discovery can help. My two cents, Best 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 Mon Apr 1 10: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 KAA02130 for ; Mon, 1 Apr 2002 10:43:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16690 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 10:43: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 KAA15605; Mon, 1 Apr 2002 10:29: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 KAA15577 for ; Mon, 1 Apr 2002 10:29:46 -0500 (EST) Received: from hotmail.com (f268.law9.hotmail.com [64.4.8.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01591 for ; Mon, 1 Apr 2002 10:29:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 07:29:17 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 15:29:16 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 10:29:16 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 15:29:17.0056 (UTC) FILETIME=[FC5D9000:01C1D991] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, I think that figuring out whether the AR that the MN is going to get IP connectivity from has the necessary QoS support for the MN is in the scope of CAR discovery as this is an IP capability. The second scenario illustrated in the Issues draft as a justification for the need of CAR discovery, is very similar to the example that Charlie pointed out. It talks about the case when a MN moves into a different AR's domain and that AR cannot support the MN's QoS needs. This example from the Issues draft, talks about the MN not connecting to the new AR if the AR cannot support the MN. I therefore think this clearly is a case where CAR discovery is useful. I think that QoS support in the AR is an IP capability of the AR and therefore CAR discovery can help. My two cents, Best 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 Apr 1 11:04: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 LAA02752 for ; Mon, 1 Apr 2002 11:04: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 KAA16937; Mon, 1 Apr 2002 10:49: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 KAA16907 for ; Mon, 1 Apr 2002 10:49:02 -0500 (EST) Received: from hotmail.com (f96.law9.hotmail.com [64.4.9.96]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02271 for ; Mon, 1 Apr 2002 10:49:00 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 07:48:32 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 15:48:32 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 10:48:32 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 15:48:32.0788 (UTC) FILETIME=[AD3C4540:01C1D994] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, >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. > [Govind] CAR discovery informs the capabilities of the AR (here QoS) to the TAR selection protocol. I think this is very different from the act of doing explicit QoS signalling. Also, if QoS support is recognized as a capability of the AR, we don't need to expand the charter of the WG, IMHO. Again from the CAR discovery issues draft, Section 5.2: "For example, the MN may need some hardware or software support from the AR or need some application servers topologically close to the AR, to run certain IP-based applications. Support for QoS, security, multicast, header compression etc. are some other aspects that need to be considered when choosing the CAR for MN's handoff. " Best 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 Mon Apr 1 11:04: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 LAA02762 for ; Mon, 1 Apr 2002 11:04:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18035 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 11:04: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 KAA16937; Mon, 1 Apr 2002 10:49: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 KAA16907 for ; Mon, 1 Apr 2002 10:49:02 -0500 (EST) Received: from hotmail.com (f96.law9.hotmail.com [64.4.9.96]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02271 for ; Mon, 1 Apr 2002 10:49:00 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 07:48:32 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 15:48:32 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 10:48:32 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 15:48:32.0788 (UTC) FILETIME=[AD3C4540:01C1D994] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, >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. > [Govind] CAR discovery informs the capabilities of the AR (here QoS) to the TAR selection protocol. I think this is very different from the act of doing explicit QoS signalling. Also, if QoS support is recognized as a capability of the AR, we don't need to expand the charter of the WG, IMHO. Again from the CAR discovery issues draft, Section 5.2: "For example, the MN may need some hardware or software support from the AR or need some application servers topologically close to the AR, to run certain IP-based applications. Support for QoS, security, multicast, header compression etc. are some other aspects that need to be considered when choosing the CAR for MN's handoff. " Best 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 Apr 1 11:36: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 LAA04115 for ; Mon, 1 Apr 2002 11:36: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 LAA19163; Mon, 1 Apr 2002 11:18: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 LAA19132 for ; Mon, 1 Apr 2002 11:18: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 LAA03484 for ; Mon, 1 Apr 2002 11:18:19 -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 g31GHcI02485; Mon, 1 Apr 2002 08:17:38 -0800 (PST) Message-ID: <002a01c1d998$84b734a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 08:16: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 Hi Charlie, > 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. > This sounds like context transfer, not CAR discovery. QoS was one of the intended applications of context transfer, so I believe it is in scope. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 1 11:36: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 LAA04127 for ; Mon, 1 Apr 2002 11:36:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20560 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 11:36: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 LAA19163; Mon, 1 Apr 2002 11:18: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 LAA19132 for ; Mon, 1 Apr 2002 11:18: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 LAA03484 for ; Mon, 1 Apr 2002 11:18:19 -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 g31GHcI02485; Mon, 1 Apr 2002 08:17:38 -0800 (PST) Message-ID: <002a01c1d998$84b734a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 08:16: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 Hi Charlie, > 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. > This sounds like context transfer, not CAR discovery. QoS was one of the intended applications of context transfer, so I believe it is in scope. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 11:39: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 LAA04248 for ; Mon, 1 Apr 2002 11:39: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 LAA19575; Mon, 1 Apr 2002 11:28: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 LAA19547 for ; Mon, 1 Apr 2002 11:28: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 LAA03869 for ; Mon, 1 Apr 2002 11:28: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 g31GRgI02692; Mon, 1 Apr 2002 08:27:42 -0800 (PST) Message-ID: <003b01c1d999$ec925040$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Charlie Perkins" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 08:26: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 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??? > Um, it is only chopped liver to the extent that the WG members don't contribute to technical discussion but rather snipe at each other when having technical discussions and at the WG chair when trying to figure out the right thing to do. :-) If you have some ideas about how to get around the nonlinear effects caused by coupling two processes with time constants an order of magnitude apart, to say nothing of how to incorporate additional decision criteria besides power levels at the 10's of ms time constant level, then by all means (broad and not so subtle hint) write a draft about it and contribute on the mailing list to discussing it. I think Allison could be convinced (and certainly I could) to have Seamoby working on these topics if we see people willing to engage in self-sustaining technical discussion that entertains all viewpoints and is oriented toward coming up with a concensus solution. That does not mean that people come on the list when the topic first comes up and agitate that it be considered, then vanish when there is work to do on writing and reading drafts, and refining the design. It means that people are engaged in the process from start to finish. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 11:52: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 LAA04623 for ; Mon, 1 Apr 2002 11:52: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 LAA20420; Mon, 1 Apr 2002 11:34: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 LAA20390 for ; Mon, 1 Apr 2002 11:34:01 -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 LAA04002 for ; Mon, 1 Apr 2002 11:33:58 -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 IAA12903; Mon, 1 Apr 2002 08:33:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31GXUD19888; Mon, 1 Apr 2002 08:33:30 -0800 X-mProtect: <200204011633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTYrynh; Mon, 01 Apr 2002 08:33:27 PST Message-ID: <3CA88BD8.AAC945E2@iprg.nokia.com> Date: Mon, 01 Apr 2002 08:33:28 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <002a01c1d998$84b734a0$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, James Kempf wrote: > This sounds like context transfer, not CAR discovery. QoS was one of the > intended applications of context transfer, so I believe it is in scope. Agreed. However, I think that whatever data format is used to _supply_ the context for a QoS handover, would be similar to the data format to _request_ whether it is available. Differences might be needed for mandated vs. preferential, and for accounting purposes, but those are details that should not obscure the basic similarity. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 1 11:52: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 LAA04632 for ; Mon, 1 Apr 2002 11:52:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21374 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 11:52: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 LAA20420; Mon, 1 Apr 2002 11:34: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 LAA20390 for ; Mon, 1 Apr 2002 11:34:01 -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 LAA04002 for ; Mon, 1 Apr 2002 11:33:58 -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 IAA12903; Mon, 1 Apr 2002 08:33:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31GXUD19888; Mon, 1 Apr 2002 08:33:30 -0800 X-mProtect: <200204011633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTYrynh; Mon, 01 Apr 2002 08:33:27 PST Message-ID: <3CA88BD8.AAC945E2@iprg.nokia.com> Date: Mon, 01 Apr 2002 08:33:28 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <002a01c1d998$84b734a0$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, James Kempf wrote: > This sounds like context transfer, not CAR discovery. QoS was one of the > intended applications of context transfer, so I believe it is in scope. Agreed. However, I think that whatever data format is used to _supply_ the context for a QoS handover, would be similar to the data format to _request_ whether it is available. Differences might be needed for mandated vs. preferential, and for accounting purposes, but those are details that should not obscure the basic similarity. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 11:59: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 LAA05162 for ; Mon, 1 Apr 2002 11:59: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 LAA21064; Mon, 1 Apr 2002 11:45: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 LAA21037 for ; Mon, 1 Apr 2002 11:45:26 -0500 (EST) Received: from hotmail.com (f230.law7.hotmail.com [216.33.237.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04443 for ; Mon, 1 Apr 2002 11:45:23 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 08:44:55 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 16:44:55 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 16:44:55 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 16:44:55.0898 (UTC) FILETIME=[8DB9E3A0:01C1D99C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: Pardon my ignorance here, but isn't CT about *transferring* context rather than negotiating capabilities. In other words, doesn't CT protocol take source and dest. of CT as input? Now, source is obvious, we still need to work on finding dest. which is target AR of handoff. BR, Hemant >From: "James Kempf" >To: "Charlie Perkins" >CC: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 1 Apr 2002 08:16:02 -0800 > >Hi Charlie, > > > > 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. > > > >This sounds like context transfer, not CAR discovery. QoS was one of the >intended applications of context transfer, so I believe it is in scope. > > 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 Mon Apr 1 11:59: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 LAA05171 for ; Mon, 1 Apr 2002 11:59:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21937 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 11:59: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 LAA21064; Mon, 1 Apr 2002 11:45: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 LAA21037 for ; Mon, 1 Apr 2002 11:45:26 -0500 (EST) Received: from hotmail.com (f230.law7.hotmail.com [216.33.237.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04443 for ; Mon, 1 Apr 2002 11:45:23 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 08:44:55 -0800 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 16:44:55 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 16:44:55 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 16:44:55.0898 (UTC) FILETIME=[8DB9E3A0:01C1D99C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: Pardon my ignorance here, but isn't CT about *transferring* context rather than negotiating capabilities. In other words, doesn't CT protocol take source and dest. of CT as input? Now, source is obvious, we still need to work on finding dest. which is target AR of handoff. BR, Hemant >From: "James Kempf" >To: "Charlie Perkins" >CC: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 1 Apr 2002 08:16:02 -0800 > >Hi Charlie, > > > > 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. > > > >This sounds like context transfer, not CAR discovery. QoS was one of the >intended applications of context transfer, so I believe it is in scope. > > 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 Mon Apr 1 12: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 MAA05834 for ; Mon, 1 Apr 2002 12: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 LAA21743; Mon, 1 Apr 2002 11:57: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 LAA21718 for ; Mon, 1 Apr 2002 11:57:02 -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 LAA04967 for ; Mon, 1 Apr 2002 11:56:59 -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 IAA13449; Mon, 1 Apr 2002 08:56:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31GuQs01504; Mon, 1 Apr 2002 08:56:26 -0800 X-mProtect: <200204011656> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpkgIUa; Mon, 01 Apr 2002 08:56:24 PST Message-ID: <3CA89139.2D189E27@iprg.nokia.com> Date: Mon, 01 Apr 2002 08:56:25 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Phil Neumiller , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$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: > If you have some ideas about how to get around the nonlinear effects > caused by coupling two processes with time constants an order of > magnitude apart, to say nothing of how to incorporate additional > decision criteria besides power levels at the 10's of ms time constant > level, then by all means (broad and not so subtle hint) write a draft > about it and contribute on the mailing list to discussing it. I'm fascinated by this request, and I would really like it if you could give some further clues about what you are looking for. For instance, can you identify the processes that you think might be coupled? Can you say something more about the decision criteria? I would think that CARD would "naturally" be constrained to consider dynamic behavior with time constants not less than, say, 30 ms. At least, until 2005 or so. The (independent!) processes that are of interest would include: 1. Something that triggers CAR discovery 2. Something else that subsequently triggers handover 3. Something that carries out remote signaling to optimize whatever needs fixing up after the localized handover has occurred. Regarding (3), note that a local optimization for time and smoothness is "typically" not good for wide-area optimization of network paths. Chained tunnels provide a good illustration about why this is the case. It would be even worse for extended patch-ups to QoS. Another way of saying this, is that although CARD is separable from smooth handover, it has to be considered in light of what is likely to happen once the discovery takes place. And, I would also say that we should be allowed to discover whatever information by way of (1) that would be use during process (2). Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 1 12: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 MAA05844 for ; Mon, 1 Apr 2002 12:08:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23551 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 12: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 LAA21743; Mon, 1 Apr 2002 11:57: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 LAA21718 for ; Mon, 1 Apr 2002 11:57:02 -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 LAA04967 for ; Mon, 1 Apr 2002 11:56:59 -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 IAA13449; Mon, 1 Apr 2002 08:56:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31GuQs01504; Mon, 1 Apr 2002 08:56:26 -0800 X-mProtect: <200204011656> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpkgIUa; Mon, 01 Apr 2002 08:56:24 PST Message-ID: <3CA89139.2D189E27@iprg.nokia.com> Date: Mon, 01 Apr 2002 08:56:25 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Phil Neumiller , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$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: > If you have some ideas about how to get around the nonlinear effects > caused by coupling two processes with time constants an order of > magnitude apart, to say nothing of how to incorporate additional > decision criteria besides power levels at the 10's of ms time constant > level, then by all means (broad and not so subtle hint) write a draft > about it and contribute on the mailing list to discussing it. I'm fascinated by this request, and I would really like it if you could give some further clues about what you are looking for. For instance, can you identify the processes that you think might be coupled? Can you say something more about the decision criteria? I would think that CARD would "naturally" be constrained to consider dynamic behavior with time constants not less than, say, 30 ms. At least, until 2005 or so. The (independent!) processes that are of interest would include: 1. Something that triggers CAR discovery 2. Something else that subsequently triggers handover 3. Something that carries out remote signaling to optimize whatever needs fixing up after the localized handover has occurred. Regarding (3), note that a local optimization for time and smoothness is "typically" not good for wide-area optimization of network paths. Chained tunnels provide a good illustration about why this is the case. It would be even worse for extended patch-ups to QoS. Another way of saying this, is that although CARD is separable from smooth handover, it has to be considered in light of what is likely to happen once the discovery takes place. And, I would also say that we should be allowed to discover whatever information by way of (1) that would be use during process (2). Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 12:26: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 MAA06557 for ; Mon, 1 Apr 2002 12:26: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 MAA23705; Mon, 1 Apr 2002 12:10: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 MAA23680 for ; Mon, 1 Apr 2002 12:10: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 MAA06058 for ; Mon, 1 Apr 2002 12:10: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 g31H9tI03801; Mon, 1 Apr 2002 09:09:55 -0800 (PST) Message-ID: <00db01c1d99f$d24047a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:08: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 Govind, As I mentioned to Charlie, I don't see a problem with advertising configured QoS and having the mobile use that as a possible criteria on an intertechnology handover, for example. Where I have a problem is in using QoS as a first order deterimant of handover, on the order of power. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Monday, April 01, 2002 7:29 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hello all, > I think that figuring out whether the AR that the MN is going to get IP > connectivity from has the necessary QoS support for the MN is in the scope > of CAR discovery as this is an IP capability. > > The second scenario illustrated in the Issues draft > as a justification for the need of CAR discovery, > is very similar to the example that Charlie pointed out. > It talks about the case when a MN moves into a different AR's domain and > that AR cannot support the MN's QoS needs. This example from the Issues > draft, talks about the MN not connecting to the new AR if the AR cannot > support the MN. > > I therefore think this clearly is a case where CAR discovery is useful. > I think that QoS support in the AR is an IP capability of the AR and > therefore CAR discovery can help. > > My two cents, > Best 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 Mon Apr 1 12:26: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 MAA06566 for ; Mon, 1 Apr 2002 12:26:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24567 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 12:26: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 MAA23705; Mon, 1 Apr 2002 12:10: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 MAA23680 for ; Mon, 1 Apr 2002 12:10: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 MAA06058 for ; Mon, 1 Apr 2002 12:10: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 g31H9tI03801; Mon, 1 Apr 2002 09:09:55 -0800 (PST) Message-ID: <00db01c1d99f$d24047a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:08: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 Govind, As I mentioned to Charlie, I don't see a problem with advertising configured QoS and having the mobile use that as a possible criteria on an intertechnology handover, for example. Where I have a problem is in using QoS as a first order deterimant of handover, on the order of power. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: Sent: Monday, April 01, 2002 7:29 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hello all, > I think that figuring out whether the AR that the MN is going to get IP > connectivity from has the necessary QoS support for the MN is in the scope > of CAR discovery as this is an IP capability. > > The second scenario illustrated in the Issues draft > as a justification for the need of CAR discovery, > is very similar to the example that Charlie pointed out. > It talks about the case when a MN moves into a different AR's domain and > that AR cannot support the MN's QoS needs. This example from the Issues > draft, talks about the MN not connecting to the new AR if the AR cannot > support the MN. > > I therefore think this clearly is a case where CAR discovery is useful. > I think that QoS support in the AR is an IP capability of the AR and > therefore CAR discovery can help. > > My two cents, > Best 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 Mon Apr 1 12: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 MAA06663 for ; Mon, 1 Apr 2002 12: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 MAA23630; Mon, 1 Apr 2002 12:09: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 MAA23600 for ; Mon, 1 Apr 2002 12:09: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 MAA05928 for ; Mon, 1 Apr 2002 12:09:19 -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 g31H8dI03768; Mon, 1 Apr 2002 09:08:40 -0800 (PST) Message-ID: <00d501c1d99f$a584dd20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , Cc: References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:07: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, The issues draft has not yet been approved by the IESG. Until it is, I don't think we can rely on specific examples to guide the discussion of requirements. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: ; Cc: Sent: Monday, April 01, 2002 7:48 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hello James, > > >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. > > > > > [Govind] CAR discovery informs the capabilities of the AR (here QoS) to the > TAR selection protocol. I think this is very different from the act of doing > explicit QoS signalling. > > Also, if QoS support is recognized as a capability of the AR, we don't need > to expand the charter of the WG, IMHO. > > Again from the CAR discovery issues draft, Section 5.2: > > "For example, the MN may > need some hardware or software support from the AR or need some > application servers topologically close to the AR, to run certain > IP-based applications. Support for QoS, security, multicast, header > compression etc. are some other aspects that need to be considered > when choosing the CAR for MN's handoff. " > > > Best 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 Mon Apr 1 12:28: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 MAA06671 for ; Mon, 1 Apr 2002 12:28:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24636 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 12:28: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 MAA23630; Mon, 1 Apr 2002 12:09: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 MAA23600 for ; Mon, 1 Apr 2002 12:09: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 MAA05928 for ; Mon, 1 Apr 2002 12:09:19 -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 g31H8dI03768; Mon, 1 Apr 2002 09:08:40 -0800 (PST) Message-ID: <00d501c1d99f$a584dd20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Govind Krishnamurthi" , Cc: References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:07: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, The issues draft has not yet been approved by the IESG. Until it is, I don't think we can rely on specific examples to guide the discussion of requirements. jak ----- Original Message ----- From: "Govind Krishnamurthi" To: ; Cc: Sent: Monday, April 01, 2002 7:48 AM Subject: Re: [Seamoby] Examples of CAR discovery > Hello James, > > >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. > > > > > [Govind] CAR discovery informs the capabilities of the AR (here QoS) to the > TAR selection protocol. I think this is very different from the act of doing > explicit QoS signalling. > > Also, if QoS support is recognized as a capability of the AR, we don't need > to expand the charter of the WG, IMHO. > > Again from the CAR discovery issues draft, Section 5.2: > > "For example, the MN may > need some hardware or software support from the AR or need some > application servers topologically close to the AR, to run certain > IP-based applications. Support for QoS, security, multicast, header > compression etc. are some other aspects that need to be considered > when choosing the CAR for MN's handoff. " > > > Best 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 Mon Apr 1 12:39: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 LAA04261 for ; Mon, 1 Apr 2002 11:39:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20736 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 11:39: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 LAA19575; Mon, 1 Apr 2002 11:28: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 LAA19547 for ; Mon, 1 Apr 2002 11:28: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 LAA03869 for ; Mon, 1 Apr 2002 11:28: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 g31GRgI02692; Mon, 1 Apr 2002 08:27:42 -0800 (PST) Message-ID: <003b01c1d999$ec925040$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Charlie Perkins" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 08:26: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 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??? > Um, it is only chopped liver to the extent that the WG members don't contribute to technical discussion but rather snipe at each other when having technical discussions and at the WG chair when trying to figure out the right thing to do. :-) If you have some ideas about how to get around the nonlinear effects caused by coupling two processes with time constants an order of magnitude apart, to say nothing of how to incorporate additional decision criteria besides power levels at the 10's of ms time constant level, then by all means (broad and not so subtle hint) write a draft about it and contribute on the mailing list to discussing it. I think Allison could be convinced (and certainly I could) to have Seamoby working on these topics if we see people willing to engage in self-sustaining technical discussion that entertains all viewpoints and is oriented toward coming up with a concensus solution. That does not mean that people come on the list when the topic first comes up and agitate that it be considered, then vanish when there is work to do on writing and reading drafts, and refining the design. It means that people are engaged in the process from start to finish. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 12:44: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 MAA07413 for ; Mon, 1 Apr 2002 12:44: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 MAA24679; Mon, 1 Apr 2002 12:28: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 MAA24650 for ; Mon, 1 Apr 2002 12:28: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 MAA06692 for ; Mon, 1 Apr 2002 12:28: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 g31HRlI04366; Mon, 1 Apr 2002 09:27:47 -0800 (PST) Message-ID: <00e701c1d9a2$51661b20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" , "Parviz Yegani" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> <3CA53A81.33174CF0@iprg.nokia.com> <4.3.2.7.2.20020331235625.03fd43e8@franklin.cisco.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:26: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 Parviz, > What do you mean by "QoS for handover"? As I see it, there are two issues: 1) Providing the mobile with a CAR capability that gives the configured QoS of an access router. The configured capability would change very slowly, if at all. 2) Providing the mobile with dynamic IP level QoS measurements at the time of handover, on a time scale similar to power measurements, so the mobile could use that in addition to power levels to determine handover. >Are there any requirements defined > for this in IETF? We are in the process of defining CAR discovery requirements, so that would cover 1) above. 2) is currently under debate as to whether Seamoby is the right place to investigate it. > I hope this will be done in Seamoby. As Charlie said there are too many > mailing > lists and it's very hard for one to follow all the email discussions on > these lists. > I appreciate the problem, but IETF WGs typically have fixed charters. To succeed, a WG must focus on its charter, otherwise, it can easily become distracted and not get anything done. If dynamic QoS determination at handover is decided not to be in Seamoby's charter, then the discussion must be moved elsewhere. It is possible to change the charter with approval of the AD, but I feel that Seamoby's charter is now a good match between the amount of work and the number of people who have actually exhibited an inclination to work on the charter items (as opposed to those who insist on including charter items and then vanish when there is work to do on them). > Could you please briefly tell us what NSIS is supposed to accomplish as far > as QoS > for wireless is concerned? As you may both 3GPP and 3GPP2 folks are working on > an end-to-end QoS solution for mobile wireless systems and applications > (beyond 3G). > In this work we are heavily relying on the IETF existing protocols. It > would be interesting > to know if IETF is going to standardize yet another protocol specifically > tailored/designed > for wireless applications. > Please read the NSIS WG page, available through the IETF web site. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 12:52: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 MAA07751 for ; Mon, 1 Apr 2002 12:52: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 MAA25972; Mon, 1 Apr 2002 12: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 MAA25941 for ; Mon, 1 Apr 2002 12:41:30 -0500 (EST) Received: from hotmail.com (f95.law9.hotmail.com [64.4.9.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07254 for ; Mon, 1 Apr 2002 12:41:27 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 09:41:00 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 17:40:59 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 12:40:59 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 17:41:00.0020 (UTC) FILETIME=[62E62B40:01C1D9A4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, but atleast it has cleared WG last call. If that document shouldn't be the basis of our discussions henceforth on the scope of CAR discovery could you point out what other document I should use? Just for clarification. Regards, Govind. > >Govind, > >The issues draft has not yet been approved by the IESG. Until it is, I >don't think we can rely on specific examples to guide the discussion of >requirements. > > 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@ns.ietf.org Mon Apr 1 12:52: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 MAA07764 for ; Mon, 1 Apr 2002 12:52:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26696 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 12:52: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 MAA25972; Mon, 1 Apr 2002 12: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 MAA25941 for ; Mon, 1 Apr 2002 12:41:30 -0500 (EST) Received: from hotmail.com (f95.law9.hotmail.com [64.4.9.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07254 for ; Mon, 1 Apr 2002 12:41:27 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 09:41:00 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 17:40:59 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 01 Apr 2002 12:40:59 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 17:41:00.0020 (UTC) FILETIME=[62E62B40:01C1D9A4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, but atleast it has cleared WG last call. If that document shouldn't be the basis of our discussions henceforth on the scope of CAR discovery could you point out what other document I should use? Just for clarification. Regards, Govind. > >Govind, > >The issues draft has not yet been approved by the IESG. Until it is, I >don't think we can rely on specific examples to guide the discussion of >requirements. > > 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 Mon Apr 1 12:57: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 MAA07948 for ; Mon, 1 Apr 2002 12:57: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 MAA25901; Mon, 1 Apr 2002 12: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 MAA25872 for ; Mon, 1 Apr 2002 12: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 MAA07215 for ; Mon, 1 Apr 2002 12:40: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 g31HeEI04789; Mon, 1 Apr 2002 09:40:14 -0800 (PST) Message-ID: <012001c1d9a4$0e6be320$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <002a01c1d998$84b734a0$7e6015ac@T23KEMPF> <3CA88BD8.AAC945E2@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:38: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 > Agreed. However, I think that whatever data format is used to _supply_ > the context for a QoS handover, would be similar to the data format > to _request_ whether it is available. Differences might be needed for > mandated vs. preferential, and for accounting purposes, but those are > details that should not obscure the basic similarity. > Off the top of my head, I can't see the connection, but this sounds like a subtle enough point that it is probably worth doing a draft on it if you think you have some insight to share. BTW, I don't believe that Seamoby will be standardizing on the data format for particular context features. At least, it is not in the charter. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 1 12: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 MAA07963 for ; Mon, 1 Apr 2002 12:57:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27028 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 12: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 MAA25901; Mon, 1 Apr 2002 12: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 MAA25872 for ; Mon, 1 Apr 2002 12: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 MAA07215 for ; Mon, 1 Apr 2002 12:40: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 g31HeEI04789; Mon, 1 Apr 2002 09:40:14 -0800 (PST) Message-ID: <012001c1d9a4$0e6be320$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <002a01c1d998$84b734a0$7e6015ac@T23KEMPF> <3CA88BD8.AAC945E2@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:38: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 > Agreed. However, I think that whatever data format is used to _supply_ > the context for a QoS handover, would be similar to the data format > to _request_ whether it is available. Differences might be needed for > mandated vs. preferential, and for accounting purposes, but those are > details that should not obscure the basic similarity. > Off the top of my head, I can't see the connection, but this sounds like a subtle enough point that it is probably worth doing a draft on it if you think you have some insight to share. BTW, I don't believe that Seamoby will be standardizing on the data format for particular context features. At least, it is not in the charter. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 13:22: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 NAA09286 for ; Mon, 1 Apr 2002 13:22: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 NAA27694; Mon, 1 Apr 2002 13: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 NAA27655 for ; Mon, 1 Apr 2002 13:00: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 NAA08180 for ; Mon, 1 Apr 2002 13:00: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 g31I0DI05483; Mon, 1 Apr 2002 10:00:13 -0800 (PST) Message-ID: <014701c1d9a6$d936f2a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: "Phil Neumiller" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:58:37 -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'm fascinated by this request, and I would really like it if you > could give some further clues about what you are looking for. Well, I'm not looking for anything, except to reduce my email volume. :-) So far, I seem to have failed miserably. :-( > For instance, can you identify the processes that you think might > be coupled? Can you say something more about the decision criteria? > Obtaining measurements of IP level QoS is one process. Per our previous discussion, the estimate was a time constant on the order of 100's of msec. The other process is making the handover decision. That is 10's of msec estimated. There is another issue here. Suppose we consider a dynamic QoS measurement on the order of 200 ms and a total (L2 + L3) handover time of 40 ms as in previous email. Now, just for the sake of argument, suppose we consider that the QoS measurement delivers 20 bytes of data, minus IPv6 headers which are removed by header compression. This should be enough for the IPv6 address of the access router and a 4 byte QoS level. By my calculation, that is approximately 8kbps just to deliver QoS measurement data to the mobile node. That's a lot of bandwidth. In fact, it is more bandwidth than is used to deliver cellular voice in current 3G systems. > I would think that CARD would "naturally" be constrained to consider > dynamic behavior with time constants not less than, say, 30 ms. I see the time constant as rather higher, more like seconds. > At least, until 2005 or so. The (independent!) processes that > are of interest would include: > > 1. Something that triggers CAR discovery > 2. Something else that subsequently triggers handover > 3. Something that carries out remote signaling to optimize > whatever needs fixing up after the localized handover > has occurred. > I think one needs to distinguish between InterTHO and IntraTHO. I believe the time constants can be considerably different, and the need for involvement of the mobile, it's user, or potentially software agents acting on behalf of the user, are considerably different. For InterTHO, the time constant can be up to seconds, for IntraTHO it is 10's of ms. > Regarding (3), note that a local optimization for time and > smoothness is "typically" not good for wide-area optimization > of network paths. Chained tunnels provide a good illustration > about why this is the case. It would be even worse for extended > patch-ups to QoS. > I'm not sure I understand your point. I agree about chained tunnels, but I don't see how this applies to QoS. > Another way of saying this, is that although CARD is separable > from smooth handover, it has to be considered in light of what > is likely to happen once the discovery takes place. And, I > would also say that we should be allowed to discover whatever > information by way of (1) that would be use during process (2). > Again, I think the distinction between InterTHO and IntraTHO is important. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 1 13:22: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 NAA09295 for ; Mon, 1 Apr 2002 13:22:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00135 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 13:22: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 NAA27694; Mon, 1 Apr 2002 13: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 NAA27655 for ; Mon, 1 Apr 2002 13:00: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 NAA08180 for ; Mon, 1 Apr 2002 13:00: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 g31I0DI05483; Mon, 1 Apr 2002 10:00:13 -0800 (PST) Message-ID: <014701c1d9a6$d936f2a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: "Phil Neumiller" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:58:37 -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'm fascinated by this request, and I would really like it if you > could give some further clues about what you are looking for. Well, I'm not looking for anything, except to reduce my email volume. :-) So far, I seem to have failed miserably. :-( > For instance, can you identify the processes that you think might > be coupled? Can you say something more about the decision criteria? > Obtaining measurements of IP level QoS is one process. Per our previous discussion, the estimate was a time constant on the order of 100's of msec. The other process is making the handover decision. That is 10's of msec estimated. There is another issue here. Suppose we consider a dynamic QoS measurement on the order of 200 ms and a total (L2 + L3) handover time of 40 ms as in previous email. Now, just for the sake of argument, suppose we consider that the QoS measurement delivers 20 bytes of data, minus IPv6 headers which are removed by header compression. This should be enough for the IPv6 address of the access router and a 4 byte QoS level. By my calculation, that is approximately 8kbps just to deliver QoS measurement data to the mobile node. That's a lot of bandwidth. In fact, it is more bandwidth than is used to deliver cellular voice in current 3G systems. > I would think that CARD would "naturally" be constrained to consider > dynamic behavior with time constants not less than, say, 30 ms. I see the time constant as rather higher, more like seconds. > At least, until 2005 or so. The (independent!) processes that > are of interest would include: > > 1. Something that triggers CAR discovery > 2. Something else that subsequently triggers handover > 3. Something that carries out remote signaling to optimize > whatever needs fixing up after the localized handover > has occurred. > I think one needs to distinguish between InterTHO and IntraTHO. I believe the time constants can be considerably different, and the need for involvement of the mobile, it's user, or potentially software agents acting on behalf of the user, are considerably different. For InterTHO, the time constant can be up to seconds, for IntraTHO it is 10's of ms. > Regarding (3), note that a local optimization for time and > smoothness is "typically" not good for wide-area optimization > of network paths. Chained tunnels provide a good illustration > about why this is the case. It would be even worse for extended > patch-ups to QoS. > I'm not sure I understand your point. I agree about chained tunnels, but I don't see how this applies to QoS. > Another way of saying this, is that although CARD is separable > from smooth handover, it has to be considered in light of what > is likely to happen once the discovery takes place. And, I > would also say that we should be allowed to discover whatever > information by way of (1) that would be use during process (2). > Again, I think the distinction between InterTHO and IntraTHO is important. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 13: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 NAA10067 for ; Mon, 1 Apr 2002 13:39: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 NAA29955; Mon, 1 Apr 2002 13:20: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 NAA29920 for ; Mon, 1 Apr 2002 13:20:47 -0500 (EST) Received: from hotmail.com (f91.law9.hotmail.com [64.4.9.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09227 for ; Mon, 1 Apr 2002 13:20:43 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 10:19:45 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 18:19:45 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: Mon, 01 Apr 2002 13:19:45 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 18:19:45.0531 (UTC) FILETIME=[CD02FCB0:01C1D9A9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, Two points: 1. I believe that the AR's QoS capability info through CAR discovery is a necessary (not sufficient) condition, in deciding the TAR by the TAR selection algorithm. Also, as I had mentioned in an earlier mail, link scenarios like SIR from the AP etc are a given. Clearly, SIR will be an important part of the TAR decision making process. What CAR discovery aims to do is beyond this and dealing with the capabilities of the AR attached to the AP. Regarding where the QoS capability of the AR falls w.r.t other parameters while making the TAR decision is under purview of the TAR selection implementation. 2. I don't think the example mentioned is restricted to inter-technology handovers. I think it is quite valid for the WLAN -> WLAN case. Please correct me if I misunderstood your comments. Regards, Govind. > >Govind, > >As I mentioned to Charlie, I don't see a problem with advertising >configured QoS and having the mobile use that as a possible criteria on >an intertechnology handover, for example. Where I have a problem is in >using QoS as a first order deterimant of handover, on the order of >power. _________________________________________________________________ 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 Mon Apr 1 13:39: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 NAA10077 for ; Mon, 1 Apr 2002 13:39:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02597 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 13:39: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 NAA29955; Mon, 1 Apr 2002 13:20: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 NAA29920 for ; Mon, 1 Apr 2002 13:20:47 -0500 (EST) Received: from hotmail.com (f91.law9.hotmail.com [64.4.9.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09227 for ; Mon, 1 Apr 2002 13:20:43 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 10:19:45 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 18:19:45 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: Mon, 01 Apr 2002 13:19:45 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 18:19:45.0531 (UTC) FILETIME=[CD02FCB0:01C1D9A9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, Two points: 1. I believe that the AR's QoS capability info through CAR discovery is a necessary (not sufficient) condition, in deciding the TAR by the TAR selection algorithm. Also, as I had mentioned in an earlier mail, link scenarios like SIR from the AP etc are a given. Clearly, SIR will be an important part of the TAR decision making process. What CAR discovery aims to do is beyond this and dealing with the capabilities of the AR attached to the AP. Regarding where the QoS capability of the AR falls w.r.t other parameters while making the TAR decision is under purview of the TAR selection implementation. 2. I don't think the example mentioned is restricted to inter-technology handovers. I think it is quite valid for the WLAN -> WLAN case. Please correct me if I misunderstood your comments. Regards, Govind. > >Govind, > >As I mentioned to Charlie, I don't see a problem with advertising >configured QoS and having the mobile use that as a possible criteria on >an intertechnology handover, for example. Where I have a problem is in >using QoS as a first order deterimant of handover, on the order of >power. _________________________________________________________________ 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 Mon Apr 1 13:39: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 MAA07422 for ; Mon, 1 Apr 2002 12:44:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26148 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 12:44: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 MAA24679; Mon, 1 Apr 2002 12:28: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 MAA24650 for ; Mon, 1 Apr 2002 12:28: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 MAA06692 for ; Mon, 1 Apr 2002 12:28: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 g31HRlI04366; Mon, 1 Apr 2002 09:27:47 -0800 (PST) Message-ID: <00e701c1d9a2$51661b20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" , "Parviz Yegani" Cc: References: <0DF9FBC42474A24CA50F7A27FB08E0486166D5@meshpdc.meshnetworks.com> <00d801c1d744$b7a3fc50$7e6015ac@T23KEMPF> <3CA4BF3C.2B701CBC@iprg.nokia.com> <000d01c1d798$643a7cc0$026015ac@T23KEMPF> <3CA53A81.33174CF0@iprg.nokia.com> <4.3.2.7.2.20020331235625.03fd43e8@franklin.cisco.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 09:26: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 Parviz, > What do you mean by "QoS for handover"? As I see it, there are two issues: 1) Providing the mobile with a CAR capability that gives the configured QoS of an access router. The configured capability would change very slowly, if at all. 2) Providing the mobile with dynamic IP level QoS measurements at the time of handover, on a time scale similar to power measurements, so the mobile could use that in addition to power levels to determine handover. >Are there any requirements defined > for this in IETF? We are in the process of defining CAR discovery requirements, so that would cover 1) above. 2) is currently under debate as to whether Seamoby is the right place to investigate it. > I hope this will be done in Seamoby. As Charlie said there are too many > mailing > lists and it's very hard for one to follow all the email discussions on > these lists. > I appreciate the problem, but IETF WGs typically have fixed charters. To succeed, a WG must focus on its charter, otherwise, it can easily become distracted and not get anything done. If dynamic QoS determination at handover is decided not to be in Seamoby's charter, then the discussion must be moved elsewhere. It is possible to change the charter with approval of the AD, but I feel that Seamoby's charter is now a good match between the amount of work and the number of people who have actually exhibited an inclination to work on the charter items (as opposed to those who insist on including charter items and then vanish when there is work to do on them). > Could you please briefly tell us what NSIS is supposed to accomplish as far > as QoS > for wireless is concerned? As you may both 3GPP and 3GPP2 folks are working on > an end-to-end QoS solution for mobile wireless systems and applications > (beyond 3G). > In this work we are heavily relying on the IETF existing protocols. It > would be interesting > to know if IETF is going to standardize yet another protocol specifically > tailored/designed > for wireless applications. > Please read the NSIS WG page, available through the IETF web site. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 14:49: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 OAA11891 for ; Mon, 1 Apr 2002 14:49: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 OAA05812; Mon, 1 Apr 2002 14:30: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 OAA05774 for ; Mon, 1 Apr 2002 14:30:33 -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 OAA11424 for ; Mon, 1 Apr 2002 14:30:29 -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 LAA23330; Mon, 1 Apr 2002 11:29:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31JTvr28727; Mon, 1 Apr 2002 11:29:57 -0800 X-mProtect: <200204011929> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVGgO9s; Mon, 01 Apr 2002 11:29:55 PST Message-ID: <3CA8B533.EA0F51BA@iprg.nokia.com> Date: Mon, 01 Apr 2002 11:29:55 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c 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 James Kempf wrote: >> For instance, can you identify the processes that you think might >> be coupled? Can you say something more about the decision criteria? > > Obtaining measurements of IP level QoS is one process. Per our previous > discussion, the estimate was a time constant on the order of 100's of > msec. The other process is making the handover decision. That is 10's of > msec estimated. I'd like to suggest that we allow handovers based on availability of resources for less than 100ms. The handover can be accomplished in a lot shorter than that amount of time, and the CAR discovery is exactly for the purposes of doing a handover. Why disallow the more dynamic behavior? > There is another issue here. Suppose we consider a dynamic QoS > measurement on the order of 200 ms and a total (L2 + L3) handover time > of 40 ms as in previous email. Now, just for the sake of argument, > suppose we consider that the QoS measurement delivers 20 bytes of data, > minus IPv6 headers which are removed by header compression. This should > be enough for the IPv6 address of the access router and a 4 byte QoS > level. By my calculation, that is approximately 8kbps just to deliver > QoS measurement data to the mobile node. That's a lot of bandwidth. In > fact, it is more bandwidth than is used to deliver cellular voice in > current 3G systems. Are you worried about delivering _any_ data to the mobile node? What was special about QoS data here? If we had 20 bytes of data to be delivered to the mobile node, that wouldn't take very long compared to the handover time. Do you suggest that this be delivered periodically? I would not like that! Otherwise, I don't see how the 8kbps figure was arrived at... >> I would think that CARD would "naturally" be constrained to consider >> dynamic behavior with time constants not less than, say, 30 ms. > > I see the time constant as rather higher, more like seconds. Are you saying that a quantity being measured has to be stable for seconds, before a mobile node can act on the measurement? This is not right, I'm pretty sure. Consider the following: - CAR agrees to provide video QoS to a mobile node. CAR even reserves the capacity for 100ms, waiting for the node to arrive. - Another customer shows up 120ms later (we have lots of customers :-) and uses up that video bandwidth By your definition, the mobile node should not even consider CAR, because CAR is unwilling to tie up its resources for more than 100ms just on the _prospect_ of a handover. By my understanding, it would be better (for smoother handovers) for the CAR to reserve the bandwidth, but it would be uneconomical to do so for "seconds". > I think one needs to distinguish between InterTHO and IntraTHO. I > believe the time constants can be considerably different, and the need > for involvement of the mobile, it's user, or potentially software agents > acting on behalf of the user, are considerably different. For InterTHO, > the time constant can be up to seconds, for IntraTHO it is 10's of ms. The time constant _could_ be large, but even for InterTHO it does not have to be -- the two interfaces could (and often would) be on the same router. I would hope that we don't have to deal with mobile agents here. Besides that, IP-layer stuff should not depend on the specifics of the technology (i.e., the 'T'). It should work over whatever reasonable technology is going to support handovers. Maybe not carrier pigeons. >> Regarding (3), note that a local optimization for time and >> smoothness is "typically" not good for wide-area optimization >> of network paths. Chained tunnels provide a good illustration >> about why this is the case. It would be even worse for extended >> patch-ups to QoS. > > I'm not sure I understand your point. I agree about chained tunnels, but > I don't see how this applies to QoS. Nothing deep here... If I get QoS at the router, by appending a QoS-reserved path between access routers to a QoS-reserved path ending at the previous access router, I get QoS, but it takes more network resources than would otherwise be necessary. >> Another way of saying this, is that although CARD is separable >> from smooth handover, it has to be considered in light of what >> is likely to happen once the discovery takes place. And, I >> would also say that we should be allowed to discover whatever >> information by way of (1) that would be use during process (2). > > Again, I think the distinction between InterTHO and IntraTHO is > important. I don't think we should design CAR discovery around such a distinction. Of course, it's important for any reasonable system design, but that does not have to affect the discovery protocol by which CARs are identified. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 1 14:49: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 OAA11901 for ; Mon, 1 Apr 2002 14:49:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06992 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 14:49: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 OAA05812; Mon, 1 Apr 2002 14:30: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 OAA05774 for ; Mon, 1 Apr 2002 14:30:33 -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 OAA11424 for ; Mon, 1 Apr 2002 14:30:29 -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 LAA23330; Mon, 1 Apr 2002 11:29:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31JTvr28727; Mon, 1 Apr 2002 11:29:57 -0800 X-mProtect: <200204011929> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVGgO9s; Mon, 01 Apr 2002 11:29:55 PST Message-ID: <3CA8B533.EA0F51BA@iprg.nokia.com> Date: Mon, 01 Apr 2002 11:29:55 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c 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 James Kempf wrote: >> For instance, can you identify the processes that you think might >> be coupled? Can you say something more about the decision criteria? > > Obtaining measurements of IP level QoS is one process. Per our previous > discussion, the estimate was a time constant on the order of 100's of > msec. The other process is making the handover decision. That is 10's of > msec estimated. I'd like to suggest that we allow handovers based on availability of resources for less than 100ms. The handover can be accomplished in a lot shorter than that amount of time, and the CAR discovery is exactly for the purposes of doing a handover. Why disallow the more dynamic behavior? > There is another issue here. Suppose we consider a dynamic QoS > measurement on the order of 200 ms and a total (L2 + L3) handover time > of 40 ms as in previous email. Now, just for the sake of argument, > suppose we consider that the QoS measurement delivers 20 bytes of data, > minus IPv6 headers which are removed by header compression. This should > be enough for the IPv6 address of the access router and a 4 byte QoS > level. By my calculation, that is approximately 8kbps just to deliver > QoS measurement data to the mobile node. That's a lot of bandwidth. In > fact, it is more bandwidth than is used to deliver cellular voice in > current 3G systems. Are you worried about delivering _any_ data to the mobile node? What was special about QoS data here? If we had 20 bytes of data to be delivered to the mobile node, that wouldn't take very long compared to the handover time. Do you suggest that this be delivered periodically? I would not like that! Otherwise, I don't see how the 8kbps figure was arrived at... >> I would think that CARD would "naturally" be constrained to consider >> dynamic behavior with time constants not less than, say, 30 ms. > > I see the time constant as rather higher, more like seconds. Are you saying that a quantity being measured has to be stable for seconds, before a mobile node can act on the measurement? This is not right, I'm pretty sure. Consider the following: - CAR agrees to provide video QoS to a mobile node. CAR even reserves the capacity for 100ms, waiting for the node to arrive. - Another customer shows up 120ms later (we have lots of customers :-) and uses up that video bandwidth By your definition, the mobile node should not even consider CAR, because CAR is unwilling to tie up its resources for more than 100ms just on the _prospect_ of a handover. By my understanding, it would be better (for smoother handovers) for the CAR to reserve the bandwidth, but it would be uneconomical to do so for "seconds". > I think one needs to distinguish between InterTHO and IntraTHO. I > believe the time constants can be considerably different, and the need > for involvement of the mobile, it's user, or potentially software agents > acting on behalf of the user, are considerably different. For InterTHO, > the time constant can be up to seconds, for IntraTHO it is 10's of ms. The time constant _could_ be large, but even for InterTHO it does not have to be -- the two interfaces could (and often would) be on the same router. I would hope that we don't have to deal with mobile agents here. Besides that, IP-layer stuff should not depend on the specifics of the technology (i.e., the 'T'). It should work over whatever reasonable technology is going to support handovers. Maybe not carrier pigeons. >> Regarding (3), note that a local optimization for time and >> smoothness is "typically" not good for wide-area optimization >> of network paths. Chained tunnels provide a good illustration >> about why this is the case. It would be even worse for extended >> patch-ups to QoS. > > I'm not sure I understand your point. I agree about chained tunnels, but > I don't see how this applies to QoS. Nothing deep here... If I get QoS at the router, by appending a QoS-reserved path between access routers to a QoS-reserved path ending at the previous access router, I get QoS, but it takes more network resources than would otherwise be necessary. >> Another way of saying this, is that although CARD is separable >> from smooth handover, it has to be considered in light of what >> is likely to happen once the discovery takes place. And, I >> would also say that we should be allowed to discover whatever >> information by way of (1) that would be use during process (2). > > Again, I think the distinction between InterTHO and IntraTHO is > important. I don't think we should design CAR discovery around such a distinction. Of course, it's important for any reasonable system design, but that does not have to affect the discovery protocol by which CARs are identified. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 15: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 PAA12711 for ; Mon, 1 Apr 2002 15:19: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 PAA08010; Mon, 1 Apr 2002 15:05: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 PAA07979 for ; Mon, 1 Apr 2002 15:05: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 PAA12394 for ; Mon, 1 Apr 2002 15:05:29 -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 g31K4qI09347; Mon, 1 Apr 2002 12:04:52 -0800 (PST) Message-ID: <018701c1d9b8$4293b1f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , "Charles E. Perkins" Cc: "Phil Neumiller" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c1d9a6$d936f2a0$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 12:03:15 -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 > There is another issue here. Suppose we consider a dynamic QoS > measurement on the order of 200 ms and a total (L2 + L3) handover time > of 40 ms as in previous email. Now, just for the sake of argument, > suppose we consider that the QoS measurement delivers 20 bytes of data, > minus IPv6 headers which are removed by header compression. This should > be enough for the IPv6 address of the access router and a 4 byte QoS > level. By my calculation, that is approximately 8kbps just to deliver > QoS measurement data to the mobile node. That's a lot of bandwidth. In > fact, it is more bandwidth than is used to deliver cellular voice in > current 3G systems. > Sorry, actually for 200 ms, the data rate should be 800bps. For 20 ms, it is 8kbps. 800bps is probably not unreasonable. So the problem in data rate only occurs if the sampling time is the same order of magnitude as the decision time. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 1 15: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 PAA12720 for ; Mon, 1 Apr 2002 15:19:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08613 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 15:19: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 PAA08010; Mon, 1 Apr 2002 15:05: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 PAA07979 for ; Mon, 1 Apr 2002 15:05: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 PAA12394 for ; Mon, 1 Apr 2002 15:05:29 -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 g31K4qI09347; Mon, 1 Apr 2002 12:04:52 -0800 (PST) Message-ID: <018701c1d9b8$4293b1f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "James Kempf" , "Charles E. Perkins" Cc: "Phil Neumiller" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c1d9a6$d936f2a0$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 12:03:15 -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 > There is another issue here. Suppose we consider a dynamic QoS > measurement on the order of 200 ms and a total (L2 + L3) handover time > of 40 ms as in previous email. Now, just for the sake of argument, > suppose we consider that the QoS measurement delivers 20 bytes of data, > minus IPv6 headers which are removed by header compression. This should > be enough for the IPv6 address of the access router and a 4 byte QoS > level. By my calculation, that is approximately 8kbps just to deliver > QoS measurement data to the mobile node. That's a lot of bandwidth. In > fact, it is more bandwidth than is used to deliver cellular voice in > current 3G systems. > Sorry, actually for 200 ms, the data rate should be 800bps. For 20 ms, it is 8kbps. 800bps is probably not unreasonable. So the problem in data rate only occurs if the sampling time is the same order of magnitude as the decision time. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 15:29: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 PAA13548 for ; Mon, 1 Apr 2002 15:29: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 PAA08581; Mon, 1 Apr 2002 15:18: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 PAA08552 for ; Mon, 1 Apr 2002 15:18: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 PAA12699 for ; Mon, 1 Apr 2002 15:18: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 g31KHuI09904; Mon, 1 Apr 2002 12:17:57 -0800 (PST) Message-ID: <01c801c1d9ba$16b48bc0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c <3CA8B533.EA0F51BA@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 12:16: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 Charlie, Let's take this off the list. I'm still conferring with Allison about whether dynamic QoS sampling and decision making at handover is covered in the Seamoby charter. jak ----- Original Message ----- From: "Charles E. Perkins" To: "James Kempf" Cc: Sent: Monday, April 01, 2002 11:29 AM Subject: Re: [Seamoby] Examples of CAR discovery > James Kempf wrote: > > >> For instance, can you identify the processes that you think might > >> be coupled? Can you say something more about the decision criteria? > > > > Obtaining measurements of IP level QoS is one process. Per our previous > > discussion, the estimate was a time constant on the order of 100's of > > msec. The other process is making the handover decision. That is 10's of > > msec estimated. > > I'd like to suggest that we allow handovers based on availability > of resources for less than 100ms. The handover can be accomplished > in a lot shorter than that amount of time, and the CAR discovery is > exactly for the purposes of doing a handover. Why disallow the more > dynamic behavior? > > > There is another issue here. Suppose we consider a dynamic QoS > > measurement on the order of 200 ms and a total (L2 + L3) handover time > > of 40 ms as in previous email. Now, just for the sake of argument, > > suppose we consider that the QoS measurement delivers 20 bytes of data, > > minus IPv6 headers which are removed by header compression. This should > > be enough for the IPv6 address of the access router and a 4 byte QoS > > level. By my calculation, that is approximately 8kbps just to deliver > > QoS measurement data to the mobile node. That's a lot of bandwidth. In > > fact, it is more bandwidth than is used to deliver cellular voice in > > current 3G systems. > > Are you worried about delivering _any_ data to the mobile node? > What was special about QoS data here? If we had 20 bytes of data > to be delivered to the mobile node, that wouldn't take very long > compared to the handover time. Do you suggest that this be delivered > periodically? I would not like that! Otherwise, I don't see how > the 8kbps figure was arrived at... > > >> I would think that CARD would "naturally" be constrained to consider > >> dynamic behavior with time constants not less than, say, 30 ms. > > > > I see the time constant as rather higher, more like seconds. > > Are you saying that a quantity being measured has to be stable for > seconds, before a mobile node can act on the measurement? > > This is not right, I'm pretty sure. Consider the following: > > - CAR agrees to provide video QoS to a mobile node. CAR even > reserves the capacity for 100ms, waiting for the node to arrive. > > - Another customer shows up 120ms later (we have lots of customers :-) > and uses up that video bandwidth > > By your definition, the mobile node should not even consider CAR, > because CAR is unwilling to tie up its resources for more than 100ms > just on the _prospect_ of a handover. By my understanding, it would > be better (for smoother handovers) for the CAR to reserve the bandwidth, > but it would be uneconomical to do so for "seconds". > > > I think one needs to distinguish between InterTHO and IntraTHO. I > > believe the time constants can be considerably different, and the need > > for involvement of the mobile, it's user, or potentially software agents > > acting on behalf of the user, are considerably different. For InterTHO, > > the time constant can be up to seconds, for IntraTHO it is 10's of ms. > > The time constant _could_ be large, but even for InterTHO it does > not have to be -- the two interfaces could (and often would) be on > the same router. I would hope that we don't have to deal with mobile > agents here. > > Besides that, IP-layer stuff should not depend on the specifics > of the technology (i.e., the 'T'). It should work over whatever > reasonable technology is going to support handovers. Maybe not > carrier pigeons. > > >> Regarding (3), note that a local optimization for time and > >> smoothness is "typically" not good for wide-area optimization > >> of network paths. Chained tunnels provide a good illustration > >> about why this is the case. It would be even worse for extended > >> patch-ups to QoS. > > > > I'm not sure I understand your point. I agree about chained tunnels, but > > I don't see how this applies to QoS. > > Nothing deep here... If I get QoS at the router, by appending a > QoS-reserved path between access routers to a QoS-reserved path > ending at the previous access router, I get QoS, but it takes more > network resources than would otherwise be necessary. > > >> Another way of saying this, is that although CARD is separable > >> from smooth handover, it has to be considered in light of what > >> is likely to happen once the discovery takes place. And, I > >> would also say that we should be allowed to discover whatever > >> information by way of (1) that would be use during process (2). > > > > Again, I think the distinction between InterTHO and IntraTHO is > > important. > > I don't think we should design CAR discovery around such a > distinction. Of course, it's important for any reasonable > system design, but that does not have to affect the discovery > protocol by which CARs are identified. > > Regards, > Charlie P. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 1 15:29: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 PAA13569 for ; Mon, 1 Apr 2002 15:29:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09053 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 15:29: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 PAA08581; Mon, 1 Apr 2002 15:18: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 PAA08552 for ; Mon, 1 Apr 2002 15:18: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 PAA12699 for ; Mon, 1 Apr 2002 15:18: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 g31KHuI09904; Mon, 1 Apr 2002 12:17:57 -0800 (PST) Message-ID: <01c801c1d9ba$16b48bc0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" Cc: References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c <3CA8B533.EA0F51BA@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 12:16: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 Charlie, Let's take this off the list. I'm still conferring with Allison about whether dynamic QoS sampling and decision making at handover is covered in the Seamoby charter. jak ----- Original Message ----- From: "Charles E. Perkins" To: "James Kempf" Cc: Sent: Monday, April 01, 2002 11:29 AM Subject: Re: [Seamoby] Examples of CAR discovery > James Kempf wrote: > > >> For instance, can you identify the processes that you think might > >> be coupled? Can you say something more about the decision criteria? > > > > Obtaining measurements of IP level QoS is one process. Per our previous > > discussion, the estimate was a time constant on the order of 100's of > > msec. The other process is making the handover decision. That is 10's of > > msec estimated. > > I'd like to suggest that we allow handovers based on availability > of resources for less than 100ms. The handover can be accomplished > in a lot shorter than that amount of time, and the CAR discovery is > exactly for the purposes of doing a handover. Why disallow the more > dynamic behavior? > > > There is another issue here. Suppose we consider a dynamic QoS > > measurement on the order of 200 ms and a total (L2 + L3) handover time > > of 40 ms as in previous email. Now, just for the sake of argument, > > suppose we consider that the QoS measurement delivers 20 bytes of data, > > minus IPv6 headers which are removed by header compression. This should > > be enough for the IPv6 address of the access router and a 4 byte QoS > > level. By my calculation, that is approximately 8kbps just to deliver > > QoS measurement data to the mobile node. That's a lot of bandwidth. In > > fact, it is more bandwidth than is used to deliver cellular voice in > > current 3G systems. > > Are you worried about delivering _any_ data to the mobile node? > What was special about QoS data here? If we had 20 bytes of data > to be delivered to the mobile node, that wouldn't take very long > compared to the handover time. Do you suggest that this be delivered > periodically? I would not like that! Otherwise, I don't see how > the 8kbps figure was arrived at... > > >> I would think that CARD would "naturally" be constrained to consider > >> dynamic behavior with time constants not less than, say, 30 ms. > > > > I see the time constant as rather higher, more like seconds. > > Are you saying that a quantity being measured has to be stable for > seconds, before a mobile node can act on the measurement? > > This is not right, I'm pretty sure. Consider the following: > > - CAR agrees to provide video QoS to a mobile node. CAR even > reserves the capacity for 100ms, waiting for the node to arrive. > > - Another customer shows up 120ms later (we have lots of customers :-) > and uses up that video bandwidth > > By your definition, the mobile node should not even consider CAR, > because CAR is unwilling to tie up its resources for more than 100ms > just on the _prospect_ of a handover. By my understanding, it would > be better (for smoother handovers) for the CAR to reserve the bandwidth, > but it would be uneconomical to do so for "seconds". > > > I think one needs to distinguish between InterTHO and IntraTHO. I > > believe the time constants can be considerably different, and the need > > for involvement of the mobile, it's user, or potentially software agents > > acting on behalf of the user, are considerably different. For InterTHO, > > the time constant can be up to seconds, for IntraTHO it is 10's of ms. > > The time constant _could_ be large, but even for InterTHO it does > not have to be -- the two interfaces could (and often would) be on > the same router. I would hope that we don't have to deal with mobile > agents here. > > Besides that, IP-layer stuff should not depend on the specifics > of the technology (i.e., the 'T'). It should work over whatever > reasonable technology is going to support handovers. Maybe not > carrier pigeons. > > >> Regarding (3), note that a local optimization for time and > >> smoothness is "typically" not good for wide-area optimization > >> of network paths. Chained tunnels provide a good illustration > >> about why this is the case. It would be even worse for extended > >> patch-ups to QoS. > > > > I'm not sure I understand your point. I agree about chained tunnels, but > > I don't see how this applies to QoS. > > Nothing deep here... If I get QoS at the router, by appending a > QoS-reserved path between access routers to a QoS-reserved path > ending at the previous access router, I get QoS, but it takes more > network resources than would otherwise be necessary. > > >> Another way of saying this, is that although CARD is separable > >> from smooth handover, it has to be considered in light of what > >> is likely to happen once the discovery takes place. And, I > >> would also say that we should be allowed to discover whatever > >> information by way of (1) that would be use during process (2). > > > > Again, I think the distinction between InterTHO and IntraTHO is > > important. > > I don't think we should design CAR discovery around such a > distinction. Of course, it's important for any reasonable > system design, but that does not have to affect the discovery > protocol by which CARs are identified. > > Regards, > Charlie P. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 17:11: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 RAA16752 for ; Mon, 1 Apr 2002 17:11: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 QAA14175; Mon, 1 Apr 2002 16:50: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 QAA14133 for ; Mon, 1 Apr 2002 16:50:01 -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 QAA16388 for ; Mon, 1 Apr 2002 16:49:58 -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 NAA02811; Mon, 1 Apr 2002 13:49:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31LnLj06669; Mon, 1 Apr 2002 13:49:21 -0800 X-mProtect: <200204012149> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5SBH5i; Mon, 01 Apr 2002 13:49:19 PST Message-ID: <3CA8D5E0.CC683919@iprg.nokia.com> Date: Mon, 01 Apr 2002 13:49:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org, Allison Mankin Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c 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, James Kempf wrote: > Let's take this off the list. I'm still conferring with Allison about > whether dynamic QoS sampling and decision making at handover is covered > in the Seamoby charter. O.K. I wouldn't mind it, though, if Allison wished to make her participation public. There might be some additional working group comments to help formulate the appropriate charter language, if any changes need to be made. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 1 17:11: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 RAA16762 for ; Mon, 1 Apr 2002 17:11:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16100 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 17:11: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 QAA14175; Mon, 1 Apr 2002 16:50: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 QAA14133 for ; Mon, 1 Apr 2002 16:50:01 -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 QAA16388 for ; Mon, 1 Apr 2002 16:49:58 -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 NAA02811; Mon, 1 Apr 2002 13:49:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g31LnLj06669; Mon, 1 Apr 2002 13:49:21 -0800 X-mProtect: <200204012149> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5SBH5i; Mon, 01 Apr 2002 13:49:19 PST Message-ID: <3CA8D5E0.CC683919@iprg.nokia.com> Date: Mon, 01 Apr 2002 13:49:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org, Allison Mankin Subject: Re: [Seamoby] Examples of CAR discovery References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> <3CA89139.2D189E27@iprg.nokia.com> <014701c 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, James Kempf wrote: > Let's take this off the list. I'm still conferring with Allison about > whether dynamic QoS sampling and decision making at handover is covered > in the Seamoby charter. O.K. I wouldn't mind it, though, if Allison wished to make her participation public. There might be some additional working group comments to help formulate the appropriate charter language, if any changes need to be made. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 19:34: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 TAA20277 for ; Mon, 1 Apr 2002 19: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 TAA21974; Mon, 1 Apr 2002 19:17: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 TAA21946 for ; Mon, 1 Apr 2002 19:17:12 -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 TAA20025 for ; Mon, 1 Apr 2002 19:17:09 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA14420 for ; Mon, 1 Apr 2002 17:16:26 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA05540 for ; Mon, 1 Apr 2002 17:04:13 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Mon, 1 Apr 2002 18:16:24 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465000A@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 18:16:24 -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 Bingo, Hemant, you hit it right in the bulls eye. CAR discovery is about finding the destination, CT will happen after you found the destination. QoS CT will only help maintaining QoS after (or during) the handoff, but it cannot be used to determine where to handoff to. Madjid -----Original Message----- From: Hemant Chaskar [mailto:hchaskar@hotmail.com] Sent: Monday, April 01, 2002 10:45 AM To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hi James: Pardon my ignorance here, but isn't CT about *transferring* context rather than negotiating capabilities. In other words, doesn't CT protocol take source and dest. of CT as input? Now, source is obvious, we still need to work on finding dest. which is target AR of handoff. BR, Hemant >From: "James Kempf" >To: "Charlie Perkins" >CC: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 1 Apr 2002 08:16:02 -0800 > >Hi Charlie, > > > > 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. > > > >This sounds like context transfer, not CAR discovery. QoS was one of the >intended applications of context transfer, so I believe it is in scope. > > 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 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 1 19:34: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 TAA20275 for ; Mon, 1 Apr 2002 19:34: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 TAA21763; Mon, 1 Apr 2002 19:11: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 TAA21698 for ; Mon, 1 Apr 2002 19:11: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 TAA19863 for ; Mon, 1 Apr 2002 19:11:18 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA26455 for ; Mon, 1 Apr 2002 17:11:21 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA16060 for ; Mon, 1 Apr 2002 17:11:20 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 1 Apr 2002 18:11:20 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650009@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 18:11:04 -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 Please note that transferring the QoS context as part of context transfer is something you do when you already have made a decision on where you are moving to (unless you are blasting context to a bunch of candidates). While making a decision on where to move (which I think is one usage for CAR as Govind mentioned) based on QoS capabilities of the sorounding ARs is different issues and cannot be handled by context transfer (unless you are blasting context to all your neighbors, as I said). I have been following NSIS (to the extent possible :) ) I know John L. is on this list, but to me it Seems like they are dealing with e2e signaling for QoS, with RSVP like protocols. How can you do that if you don't know your first hop router?? Maybe I am missing something. I was hoping that QoS capability would be an input to the CAR discovery protocol. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 01, 2002 10:16 AM To: Charlie Perkins Cc: Hemant Chaskar; seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hi Charlie, > 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. > This sounds like context transfer, not CAR discovery. QoS was one of the intended applications of context transfer, so I believe it is in scope. 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 Mon Apr 1 19:34: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 TAA20302 for ; Mon, 1 Apr 2002 19:34:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22910 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 19:34: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 TAA21763; Mon, 1 Apr 2002 19:11: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 TAA21698 for ; Mon, 1 Apr 2002 19:11: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 TAA19863 for ; Mon, 1 Apr 2002 19:11:18 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA26455 for ; Mon, 1 Apr 2002 17:11:21 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA16060 for ; Mon, 1 Apr 2002 17:11:20 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 1 Apr 2002 18:11:20 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650009@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 18:11:04 -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 Please note that transferring the QoS context as part of context transfer is something you do when you already have made a decision on where you are moving to (unless you are blasting context to a bunch of candidates). While making a decision on where to move (which I think is one usage for CAR as Govind mentioned) based on QoS capabilities of the sorounding ARs is different issues and cannot be handled by context transfer (unless you are blasting context to all your neighbors, as I said). I have been following NSIS (to the extent possible :) ) I know John L. is on this list, but to me it Seems like they are dealing with e2e signaling for QoS, with RSVP like protocols. How can you do that if you don't know your first hop router?? Maybe I am missing something. I was hoping that QoS capability would be an input to the CAR discovery protocol. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 01, 2002 10:16 AM To: Charlie Perkins Cc: Hemant Chaskar; seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hi Charlie, > 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. > This sounds like context transfer, not CAR discovery. QoS was one of the intended applications of context transfer, so I believe it is in scope. 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 Mon Apr 1 20:24: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 TAA20287 for ; Mon, 1 Apr 2002 19:34:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA22896 for seamoby-archive@odin.ietf.org; Mon, 1 Apr 2002 19:34: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 TAA21974; Mon, 1 Apr 2002 19:17: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 TAA21946 for ; Mon, 1 Apr 2002 19:17:12 -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 TAA20025 for ; Mon, 1 Apr 2002 19:17:09 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA14420 for ; Mon, 1 Apr 2002 17:16:26 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA05540 for ; Mon, 1 Apr 2002 17:04:13 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Mon, 1 Apr 2002 18:16:24 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465000A@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Mon, 1 Apr 2002 18:16:24 -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 Bingo, Hemant, you hit it right in the bulls eye. CAR discovery is about finding the destination, CT will happen after you found the destination. QoS CT will only help maintaining QoS after (or during) the handoff, but it cannot be used to determine where to handoff to. Madjid -----Original Message----- From: Hemant Chaskar [mailto:hchaskar@hotmail.com] Sent: Monday, April 01, 2002 10:45 AM To: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Hi James: Pardon my ignorance here, but isn't CT about *transferring* context rather than negotiating capabilities. In other words, doesn't CT protocol take source and dest. of CT as input? Now, source is obvious, we still need to work on finding dest. which is target AR of handoff. BR, Hemant >From: "James Kempf" >To: "Charlie Perkins" >CC: "Hemant Chaskar" , >Subject: Re: [Seamoby] Examples of CAR discovery >Date: Mon, 1 Apr 2002 08:16:02 -0800 > >Hi Charlie, > > > > 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. > > > >This sounds like context transfer, not CAR discovery. QoS was one of the >intended applications of context transfer, so I believe it is in scope. > > 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 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 01: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 BAA29275 for ; Tue, 2 Apr 2002 01: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 AAA07429; Tue, 2 Apr 2002 00:58: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 AAA07402 for ; Tue, 2 Apr 2002 00:58:44 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28808 for ; Tue, 2 Apr 2002 00:58:43 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g325weq19161; Tue, 2 Apr 2002 00:58:40 -0500 Message-Id: <200204020558.g325weq19161@minotaur.nge.isi.edu> To: kempf@docomolabsusa-com, hemant.chaskar@nokia.com, dirk.trossen@nokia.com, govind.krishnamurthi@nokia.com Cc: seamoby@ietf.org Reply-To: mankin@isi.edu Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Apr 2002 00:58:40 -0500 From: Allison Mankin Subject: [Seamoby] Revision of car discovery issues draft requested Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Jim, Pat, You asked for publication of draft-ietf-seamoby-cardiscovery-issues-02.txt. An initial review raised a couple of concerns that I think should be addressed before full IESG review: 1. There is only a tiny mention of inter-technology handoff (in 5.2), but enabling this is a seamoby charter goal. As Steve Deering advised during the MN meeting, this could even be CAR discovery when going from wired to wireless...There could be a fifth scenario of a technology change - going from a crowded 802.11b to an uncongested 802.11a is another thought here. 2. The references need to be split into normative and informative. If the draft must (as it now reads) be normatively dependent on the fast handoff drafts from mobileip, it will have to await their publication. 3. The points in section 7 should be prefaced with a comment on their sketchiness - they are a too brief treatment. It is not clear that any treatment of solutions belongs in this draft. Editorial: Grammar is shaky in "The following sections describe the specific issues in the CAR discovery, may it be done in anticipated, dynamic or hybrid way." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 01: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 BAA29283 for ; Tue, 2 Apr 2002 01: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 AAA07253; Tue, 2 Apr 2002 00:53: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 AAA07184 for ; Tue, 2 Apr 2002 00:53:43 -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 AAA28707 for ; Tue, 2 Apr 2002 00:53:37 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g325rTP08457; Tue, 2 Apr 2002 11:23:29 +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 g325rRL22682; Tue, 2 Apr 2002 11:23:27 +0530 (IST) Message-ID: <006701c1da0a$dc9a6a80$9224010a@SATISHJ> From: "Satish Jamadagni" To: "James Kempf" , "Phil Neumiller" , "Charlie Perkins" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 11:24:32 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0064_01C1DA38.F647F820" 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 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_0064_01C1DA38.F647F820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please find a draft that proposes combining CT and CAR. This is just a beginning - QOS classes (or context classes can be identified and the proposal enhanced). Also this draws heavely from previous drafts on CT and CAR. Your comments please. Regards, Satish Jamadagni. Sasken Communication Technologies Ltd, Bangalore, India. ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller" ; "Charlie Perkins" Cc: "Hemant Chaskar" ; Sent: Monday, April 01, 2002 9:56 PM 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??? > > > > Um, it is only chopped liver to the extent that the WG members don't > contribute to technical discussion but rather snipe at each other when > having technical discussions and at the WG chair when trying to figure > out the right thing to do. :-) > > If you have some ideas about how to get around the nonlinear effects > caused by coupling two processes with time constants an order of > magnitude apart, to say nothing of how to incorporate additional > decision criteria besides power levels at the 10's of ms time constant > level, then by all means (broad and not so subtle hint) write a draft > about it and contribute on the mailing list to discussing it. > > I think Allison could be convinced (and certainly I could) to have > Seamoby working on these topics if we see people willing to engage in > self-sustaining technical discussion that entertains all viewpoints and > is oriented toward coming up with a concensus solution. That does not > mean that people come on the list when the topic first comes up and > agitate that it be considered, then vanish when there is work to do on > writing and reading drafts, and refining the design. It means that > people are engaged in the process from start to finish. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby ------=_NextPart_000_0064_01C1DA38.F647F820 Content-Type: text/plain; name="draft-satish-car-ct-00.txt" Content-Disposition: attachment; filename="draft-satish-car-ct-00.txt" Content-Transfer-Encoding: 7bit INTERNET DRAFT Satish Jamadagni March 2002 Satish D Shiva Raman Pandey Sasken Communication Technologies Ltd A combined Context Transfer and Candidate Access Router Discovery protocol draft-satish-car-ct-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an individual submission to the Seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to seamoby@diameter.org mailing list. Distribution of this memo is unlimited. Abstract Protocols being designed for seamless IP-level handovers, such as fast handover, context transfer (CT) and Candidate Access Router (CAR) discovery protocols will have to go hand in hand for any meaningful seamless handover implementation. The CAR discovery and subsequent Target Access Router (TAR) discovery is achieved through L3 QoS parameters, user preferences and application level QoS parameter match between the geographically adjacent access routers (GAAR). It is asserted in this draft that the primary consideration for fast handover and CAR discovery will still be layer 3 QoS parameters as supported by the ARs. The TAR selection demands that the capability set of the CARs is available and should necessarily meet the MN's requirements. While the TAR selection process can happen at the time of handover, the GAARs which have the capabilities to meet the MN's requirements can be identified in advance. Whether the CAR and subsequently the TAR identification is done in advance of at the time of handover there will have to be a constant exchange of capabilities between the current AR Satish et Al [Page 1] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 and the GAARs. This motivates us to propose a CAR discovery protocol using CT messages thus resulting in signaling advantages. Our protocol qualifies to be what is called the CAR discovery protocol. Table of Contents 1. Introduction 2 1.1. Conventions Used In This Document 4 1.2. Terminology 4 2. The CAR Discovery Protocol 5 2.1. Capability exchange between GAARs - From GAARs to CARs 6 2.1.1. Capability list in the PPCT 6 2.2. Target Access Router (TAR) Selection 7 3. Modified Messages used by the CAR Discovery Protocol 8 3.1. Modified PCT for GAAR identification 8 3.2. CT Messages to aid in TAR identification 10 4. Mobile Node (MN) Operation 10 5. Access Router (AR) Operation 10 6. Security Considerations 11 7. References 11 8. Author's Addresses 12 1. INTRODUCTION There are existing solutions [1, 2] that enable mobile nodes (MNs) to execute IP-level handovers between the points of attachment (called access routers or ARs) to IP network. Additionally, work is underway [3, 4, 5, 6, 7], to define protocols that would allow seamless, i.e., low latency and low packet loss, handovers of MNs between ARs. These seamless handover solutions assume that the identity of the target AR TAR) for the MN's handover is known to the current AR. It is required to develop a protocol that would allow an AR to identify the TAR for MN's handover. We identify two important components in the problem of TAR selection. They are as follows: 1) Identifying the neighboring or geographically adjacent ARs sufficiently in advance of the handover, which have the capability set required to meet the MN's requirements. This process leads to a set of CARs, which not only are geographically adjacent but also meet any initial context based filtering criteria that can be used. Such initial filtering to identify CARs based on a critical, common feature set as required by all or a subset of the MNs attached to an AR is briefly discussed in a later section. 2) Choosing the TAR either at the time of handover from the set of CARs, or much earlier if possible with the help of additional Satish et Al [Page 2] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 information such as any additional context information, local policy, MN's preferences etc. Three approaches, namely, anticipated, dynamic and hybrid, have been outlined in [8] for CAR discovery. In the "anticipated" approach, the current AR identifies the CARs for handover prior to the handover process. At the time of handover, the TAR is identified by the current AR from the set of CARs. If CAR selection is "dynamic", the MN is actively involved in the CAR discovery process. The MN identifies the neighboring ARs as well as their capabilities and selects the TAR. This information is then forwarded to the current AR. A "hybrid" approach lies in between these two. In this draft, we argue that any AR that embarks on the CAR discovery process to aid in seamless handover can achieve identification of geographically adjacent access routers at a high level and as a further step can identify those ARs that cover in some sense an aggregate of the QoS supported by the discovery initiating AR. We also argue that the process of specifically identifying the target access router should involve the MN or the MN specific QoS and policy considerations. We specify a protocol where the discovery initiating AR initially identifies the GAARs and then uses CT messages as described in [10] with the "aggregate QoS" to identify a broad set of CARs. Then the actual identification of the TAR from the CARs can involve the use of CT messages by the specific MN or the initiating AR. The identification of the TAR given a set of CARs can be initiated by the MN or can be proactively achieved by the AR on behalf of the MN. Here the initiating AR can use triggers as specified in the fast handover draft [3] to initiate a MN specific TAR identification based on the MNs context state in that AR. In our protocol we assume that the MN may not be in a position to listen to a neighboring beacon i.e. the MN may not have or might not prefer to have (due to power, interference considerations) two L2 connections UP simultaneously. The protocol should cater to this situation well. In case a MN has the capability to listen to advertisements over two L2s simultaneously A MN can listen to beacons from neighboring access points and forward the information in the beacon to the AR it is currently attached to. The TAR selection protocol can then take this as an initiation to identify the TAR. Our protocol can cater to both the cases though we believe that the former should be given more consideration because of power and other interference constraints that might arise with two L2s being UP simultaneously. TAR selection will have to consider other parameters like user preferences and policies along with CARs to uniquely identify the TAR. The algorithms (like distance measures between the QoS descriptors etc) used in TAR selection, however is out of scope for this document. Satish et Al [Page 3] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 1.2. Terminology Access Point (AP) : A layer 2 device to which the MN connects to through a wireless link. An AP may connect to one or more ARs. An AR may be connected to connected to APs belonging to different technologies. Access Router (AR) : An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MN. When dealing with IPv4 based networks running Mobile IPv4, Foreign Agents (FAs) take the place of ARs. Geographically Adjacent AR (GAAR) : An AR whose coverage area is such that an MN may move from the coverage area of the AR currently serving the MN into the coverage area of this AR. Physical Neighborhood List (PNL) : The set of GAARs along with their capabilities maintained at an AR. Candidate AR (CAR) : This is an AR that is a candidate for MN's handover. Candidate AR is "physically adjacent" to the AR currently serving the MN, and has the capability set required to serve the MN. Target AR (TAR) : This is an AR with which the procedures for MN's handover are initiated. Border Router (BR) : Globally IP addressable router through which a privately addressable network connects to the Internet. IP-level Identity of an AR : This is the IP address of an AR if the address is globally routable. However, if an AR resides in a private IP address space, this is a tuple (border router's globally routable IP address, AR identifier recognized by the BR). Satish et Al [Page 4] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 2. THE CAR DISCOVERY PROTOCOL A basic requirement for a new AR to be considered as a CAR for a MN is that the coverage area of the new AR be "geographically adjacent" to that of the AR currently serving the MN. Note that, the geographical adjacency of two ARs is not necessarily implied by their "logical" adjacency [9]. Manually configuring this physical neighborhood at each AR as described in [8] has disadvantages and in many cases, may not be feasible. We describe a dynamic mechanism to identify GAARs for each AR. It is described with reference to Figure 1. MN +-----------+ +-+ | Current | < | | ---------- | AR | ------ > ----\ +-+ | | < \ +-----------+ \ | +--------+ Handover | Capability ^ IP | Corr. | | Exchange | Network |Node(CN)| V (PPCT message) | +--------+ v / MN +-----------+ / +-+ --------> | New | < / | | ---------- | AR | ------ > ----/ +-+ | | < +-----------+ Figure 1: Reference Scenario for Handovers In Figure 1, the current AR broadcasts the "physical coverage area" to all its logically adjacent ARs and the new AR adds this identity to its Physical Neighborhood List (PNL) if this entry does not already exist and associates a lifetime to it. The lifetime field is refreshed if the entry already exists. This "Router Identity" message can be sent to the new AR as an ICMP option. The "Partial Proactive CT (PPCT)" is derived from the PCT message defined in [10] and this can be broadcast by an edge device or a border gateway or by the AR itself to the new AR. The PPCT broadcast SHOULD essentially be an edge device function. If the MN can detect the identity of the new AR by listening to its beacon while still connected to the old AR, then the MN MUST forward this identity to the old AR. It again uses the Router Identity message for this purpose. Satish et Al [Page 5] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 If the MN receives the L2 identity of the AP in the AP's beacon it forwards this information to the current AR also through the Router Identity message. A Physical Neighborhood List (PNL) [9] is maintained at an AR and there is one entry in the PNL for each GAAR of an AR that has been identified so far. The capability set maintained is not elaborate in the sense that a minimum but essential set is identified. The objective is just to be able to identify CARs from the GAARs. 2.1. Capability exchange between GAARs - From GAARs to CARs In future IP networks, the GAARs will be heterogeneous in administrative control, function, capability, link layer technology and resources available for packet sessions. Further the MN will have specific requirements as regards these parameters. The knowledge of GAARs' capabilities allows the current AR to choose CARs from GAARs. Hence, the current AR needs to identify the capability set of each of its GAARs to arrive at the CAR set. The PPCT message is sent to a new GAAR over the wired Internet enlisting the AR's capabilities. On receiving this message, the recipient GAAR responds with another PPCT message detailing its own capabilities. The capability information obtained via this message is used to populate the "Capability Set" field in the PNL. GAARs MAY also exchange the status of capabilities periodically or on-demand. 2.1.1. Capability list in the PPCT Capabilities can broadly be divided into dynamic and static. Static capabilities do not change over time, while dynamic capabilities do. Some of the capabilities are specific to a particular MN, and MAY be exchanged on demand. There may be other capabilities which are more generic and which may specify information relevant to all MNs. The capability exchange is achieved through the use of CT [10] messages. The CAR discovery protocol SHOULD make a distinction between that set of capabilities that can be used by the AR in choosing CARs from GAARs independent of the MN considerations and those that are used in the actual TAR identification. Some of the context parameter considerations that the RIM should support in order to help in CAR identification by any AR are listed below. - Administrative parameters: ISP name, organizational ownership, device authentication and authorization data, policy information; - Cost of access: Dollar cost per QoS class; Satish et Al [Page 6] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 - Available radio interfaces that are geographically adjacent to given AR: 802.11, WCDMA, GSM; - Availability of application logic: Multicast support, playout buffer hosting for streaming applications, TCP performance enhancing proxies (PEPs), media transcoding functionality, header compression functionality; - Internet connectivity parameters: NAT traversal for connectivity; - Resource parameters: Existing load, available bandwidth are some of the resource parameters that can be used. - Identities of APs (layer 2 identities) that are served by the AR. Once GAARs are identified through the PPCT messages, the current AR identifies the CARs for a particular MN as GAARs whose capabilities meets either a broad set of MNs grouped together based on the applications or services that they are running or the MN's capability requirements. 2.2. Target Access Router (TAR) Selection Assuming that the current AR has done a good job of identifying a minimal set of CARs from which the MN has to choose a TAR, the actual TAR selection can be based on explicit MN triggers (MN initiated) or the AR initiated. The TAR selection algorithm can reside in the MN or at the AR. The following figures (2 and 3) depicts the scenarios mentioned above. +----------+ +----------+ | | 3. SHREQ | | | |-----------------| | 2. Trigger | Prtr | 4. SHREP | Nrtr | ------> | | | | | | <-------------> | | | | 1. PPCT (CARs) | | +----------+ +----------+ | ^ ^ | | | | | 5. Proxy router | | | ~~ solicitation v | | V V +-+ +-+ | | 6. movement | | +-+ ---------------> +-+ Figure 2: CAR discovery protocol (AR initiated handover) Satish et Al [Page 7] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 In anticipated CAR discovery the AR can help find the exact TAR for the mobile node and then notify the MN about the new AR for handover. This can be the case under certain load conditions when the AR wants to force some MNs to new ARs. +----------+ +----------+ | | 3. SHREQ | | | Prtr |-----------------| Nrtr | | | 4. SHREP | | | | | | | | <-----------> | | +----------+ 1. PPCT (CARs) +----------+ ^ ^ | | | | 2. Trigger | | ~~ | | V V +-+ +-+ | | 5. movement | | +-+ ---------------> +-+ Figure 3: CAR discovery Protocol (MN initiated handover) In the case of the dynamic CAR discovery the MN initiates the TAR discovery. The process of identifying the TAR for the MN's handover forms the final step of the TAR selection process. This step is performed at the time of handover. The TAR selection algorithm selects a unique TAR from the set of CARs. For this it also uses the AR reachability information for the MN at the time of handover. In addition, other aspects such as local policy and MN's preferences are also applied during the decision- making. The details of TAR selection algorithm are not within the scope of CAR discovery protocol. The TAR selection is aided through the CT messages like SHREQ and SHREP [10] where the exact list of context parameters are exchanged on a per MN basis and the TAR selection algorithm run over these parameters. The MNs can be an active or a passive participant in the TAR selection process. 3. MODIFIED MESSAGES USED BY THE CAR DISCOVERY PROTOCOL 3.1. Modified PCT for GAAR identification We are using a modified PCT message [10] as mentioned below to achieve the GAAR list and further the CAR list from a given set of GAARs. We call this message the PPCT (Partial proactive context transfer). Satish et Al [Page 8] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=PPCT | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Multicast or broadcast IP Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit AR IP Address (Paddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Geographic coverage information +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Transfer Options Data... (Initial capability set) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthTken| Sub-Option Len| Algorithm | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Partial Proactive Context Transfer Option Format Option Type Partial Proactive Context Transfer (PPCT) Option Length Variable Geographic coverage information Covers the Geographic coverage area information (either coordinates or through symbolic means) Context Transfer Options Data Individual feature contexts in the form of sub options. These are encoded in Sub-Option Type and Sub-Option Length format, as in the structure of SHIN message [10]. Algorithm 8-bit algorithm indication for computing the Authentication Token [10]. Key Length 8-bit unsigned integer. The length of the key in units of 4 octets. Key Encrypted key. The Key is encrypted using a pre-existing shared key between the Access Routers. Satish et Al [Page 9] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 The identification of the GAARs and CARs should be done independently of the MN as this reduces delays for a MN during handover, to inform the AR about the identities of GAARs. The motivation is that the AR SHOULD provide the MAXIMUM support for any seamless handover. This is motivated by the fact that the MN can be constrained by power and over the air signaling issues. The SEAMOBY WG SHOULD lay more emphasis on evolving protocols that reduce the over-the-air signaling. The increase in the wire-line signaling is acceptable. 3.2. CT Messages to aid in TAR identification In our protocol (refer figure 2 and 3) we suggest the use of the SHREQ and SHREP [10] messages for the complete context exchange on a per mobile basis. This helps the MN or the AR in identifying the TAR. The TAR selection algorithm can be resident in the AR or the MN. During the TAR identification process a partial context transfer would have occurred. This can be used to reduce the signaling during the CT operation. 4. MOBILE NODE (MN) OPERATION The following item summarizes the operations at the MN: - Maintains information about current AR's IP Identity. - Listen to L2 triggers or any other triggers for the MN initiated TAR identification. - Sends the SHIN [10] message to the AR to initiate the TAR identification process. If the new AR field in the SHIN message is left blank, the AR initiates TAR selection process. - When a MN moves to a new AR it forwards the previous AR's IP Identity to the new AR. 5. ACCESS ROUTER (AR) OPERATION The following items summarize the operations at the AR: - The AR maintains a PNL. - Upon receiving a PPCT message containing the identity of a GAAR, the AR checks to see whether the entry for this GAAR exists in the PNL. If it does, the AR refreshes the lifetime of the entry. Satish et Al [Page 10] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 - Identifies CARs based on the MN's requirements and capability parameters of GAARs recorded in the PNL. The current AR may solicit any MN-specific requirements from the GAARs. - The AR solicits the complete context information of the CARs through the SHREQ and SHREP messages on a per MN basis on receipt of a trigger either at AR or at the MN. 6. SECURITY CONSIDERATIONS In our protocol the use of CT messages during the CAR discovery provides for some level of security as some security features are in built in the CT messages [10]. Further it is required to discuss the security considerations involved in performing GAAR discovery. The security association between GAARs for the exchange of capability information can be established using standard methods for device authentication, key exchange and encryption. 7. REFERENCES [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. [2] Mobility Support in IPv6, D. Johnson and C. Perkins, draft-ietf-mobileip-ipv6-13.txt, work in progress, November 2000. [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, draft-ietf-mobileip-lowlatency-handovers-v4-00.txt, work in progress, February 2001. [4] Fast handovers for Mobile IPv6, MIPv6 handover Design Team, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 2001. [5] Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network, O. H. Levkowetz et. al., draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in progress, May 2001. [6] General requirements for a context transfer framework, H. Sayed et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in progress, May 2001. [7] Buffer Management for Smooth handovers in Mobile IPv6, G. Krishnamurthi, R. Chalmers, C. Perkins, draft-krishnamurthi-mobileip-buffer6-01.txt, work in progress, March 2001. Satish et Al [Page 11] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 [8] Issues in Candidate Access Router Discovery, D. Trossen, G Krishnamurthi, H. Chaskar, J. Kempf, draft-ietf-seamoby-CARdiscovery-02.txt, work in progress, November 2001. [9] Protocol for Candidate Access Router Discovery for Seamless IP- level Handovers, Dirk Trossen, Govind Krishnamurthi, Hemant Chaskar, Eunsoo Shim, Richard D. Gitlin, draft-trossen-seamoby-cardiscovery-00.txt, work in progress, November 2001. [10] R Koodli, C.E. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ctv6-02.txt, November 2001. 8. AUTHOR'S ADDRESSES Satish Jamadagni, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3029 Fax: +91 80 5351133 Email: satishj@sasken.com Satish D, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3164 Fax: +91 80 5351133 Email: satishd@sasken.com Shiva Raman Pandey, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3296 Fax: +91 80 5351133 Email: shiva@sasken.com Satish et Al [Page 12] ------=_NextPart_000_0064_01C1DA38.F647F820-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 01:17: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 BAA29311 for ; Tue, 2 Apr 2002 01:17:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18183 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 01:17: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 AAA06833; Tue, 2 Apr 2002 00:38: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 AAA06805 for ; Tue, 2 Apr 2002 00:38:04 -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 AAA28516 for ; Tue, 2 Apr 2002 00:38:00 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g325buP07473; Tue, 2 Apr 2002 11:07:56 +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 g325btL19996; Tue, 2 Apr 2002 11:07:55 +0530 (IST) Message-ID: <001401c1da08$b15e37e0$9224010a@SATISHJ> From: "Satish Jamadagni" To: "Nakhjiri Madjid-MNAKHJI1" , "'Hemant Chaskar'" , References: <35DBB8B7AC89D4118E98009027B1009B0465000A@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 11:09:01 +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 All, I feel that CT and CAR should go hand in hand. The reasons are as follows (taking a Bottom - Up approach trying to arrive at a CAR protocol from a final TAR selection perspective assuming that this is what CAR discovery is supposed to assist in) Combining CT and CAR - 1. Saves signaling time (Time is one of the main factors for deciding seamless ness) 2. Makes sense as during a seamless HO "Context" preservation is what every mobile terminal aims at (we are not considering application adaptation and such kind of stuff) 3. Typical TAR selection would be based on a "MATCH" of the MN context and the AR context support capabilities (any other policies and user fancies can also be brougnt under the "Context" perspective (I assume that "context" reflects a desired QoS feel at the MT so for all practical purposes "Context" and QoS are the same). For a TAR selection the MT would send in his present "Context" list to find a match. This I guess would be sent to all CARs (with all the signaling overheads) So for all practical purposes by the time I would have done a TAR selection I would have at least achieved a partial CT if the new AR can preserve the messages that I use for initial inquiry for TAR selection. All other CARs where the MT would have sent a message with a wish list ( its present context) can release the context list if the MT finally does not choose them based on a timer. So I feel a CAR discovery protocol SHOULD identify and standardize "an ABSTRACT Context" notion for initial CAR selection and finally should provide for classes of Contexts to ease the TAR selection process. The exact match algorithms can be left to implementations. Such classes of contexts helps in either a partial or a full CT under TAR selection itself. Combining CT and CAR has signaling advantages and this can prove critical for a seamless handover where the "objective is Zero latency handover" Regards, Satish Jamadagni. ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Hemant Chaskar'" ; Sent: Tuesday, April 02, 2002 5:46 AM Subject: RE: [Seamoby] Examples of CAR discovery > Bingo, Hemant, > > you hit it right in the bulls eye. CAR discovery is > about finding the destination, CT will happen after you found > the destination. QoS CT will only help maintaining QoS after > (or during) the handoff, but it cannot be used to determine > where to handoff to. > > Madjid > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Monday, April 01, 2002 10:45 AM > To: seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hi James: > > Pardon my ignorance here, but isn't CT about *transferring* context rather > than negotiating capabilities. In other words, doesn't CT protocol take > source and dest. of CT as input? Now, source is obvious, we still need to > work on finding dest. which is target AR of handoff. > > BR, > Hemant > > > >From: "James Kempf" > >To: "Charlie Perkins" > >CC: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > >Hi Charlie, > > > > > > > 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. > > > > > > >This sounds like context transfer, not CAR discovery. QoS was one of the > >intended applications of context transfer, so I believe it is in scope. > > > > 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 > > _______________________________________________ > Seamoby mailing 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 Apr 2 01:17: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 BAA29322 for ; Tue, 2 Apr 2002 01:17:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18200 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 01:17: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 AAA07253; Tue, 2 Apr 2002 00:53: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 AAA07184 for ; Tue, 2 Apr 2002 00:53:43 -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 AAA28707 for ; Tue, 2 Apr 2002 00:53:37 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g325rTP08457; Tue, 2 Apr 2002 11:23:29 +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 g325rRL22682; Tue, 2 Apr 2002 11:23:27 +0530 (IST) Message-ID: <006701c1da0a$dc9a6a80$9224010a@SATISHJ> From: "Satish Jamadagni" To: "James Kempf" , "Phil Neumiller" , "Charlie Perkins" Cc: "Hemant Chaskar" , References: <00a201c1d8e7$9946e610$746015ac@T23KEMPF> <3CA77B0E.50FB4E20@iprg.nokia.com> <000f01c1d91e$60d395d0$0902a8c0@Study> <003b01c1d999$ec925040$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 11:24:32 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0064_01C1DA38.F647F820" 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 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_0064_01C1DA38.F647F820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please find a draft that proposes combining CT and CAR. This is just a beginning - QOS classes (or context classes can be identified and the proposal enhanced). Also this draws heavely from previous drafts on CT and CAR. Your comments please. Regards, Satish Jamadagni. Sasken Communication Technologies Ltd, Bangalore, India. ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller" ; "Charlie Perkins" Cc: "Hemant Chaskar" ; Sent: Monday, April 01, 2002 9:56 PM 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??? > > > > Um, it is only chopped liver to the extent that the WG members don't > contribute to technical discussion but rather snipe at each other when > having technical discussions and at the WG chair when trying to figure > out the right thing to do. :-) > > If you have some ideas about how to get around the nonlinear effects > caused by coupling two processes with time constants an order of > magnitude apart, to say nothing of how to incorporate additional > decision criteria besides power levels at the 10's of ms time constant > level, then by all means (broad and not so subtle hint) write a draft > about it and contribute on the mailing list to discussing it. > > I think Allison could be convinced (and certainly I could) to have > Seamoby working on these topics if we see people willing to engage in > self-sustaining technical discussion that entertains all viewpoints and > is oriented toward coming up with a concensus solution. That does not > mean that people come on the list when the topic first comes up and > agitate that it be considered, then vanish when there is work to do on > writing and reading drafts, and refining the design. It means that > people are engaged in the process from start to finish. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby ------=_NextPart_000_0064_01C1DA38.F647F820 Content-Type: text/plain; name="draft-satish-car-ct-00.txt" Content-Disposition: attachment; filename="draft-satish-car-ct-00.txt" Content-Transfer-Encoding: 7bit INTERNET DRAFT Satish Jamadagni March 2002 Satish D Shiva Raman Pandey Sasken Communication Technologies Ltd A combined Context Transfer and Candidate Access Router Discovery protocol draft-satish-car-ct-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an individual submission to the Seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to seamoby@diameter.org mailing list. Distribution of this memo is unlimited. Abstract Protocols being designed for seamless IP-level handovers, such as fast handover, context transfer (CT) and Candidate Access Router (CAR) discovery protocols will have to go hand in hand for any meaningful seamless handover implementation. The CAR discovery and subsequent Target Access Router (TAR) discovery is achieved through L3 QoS parameters, user preferences and application level QoS parameter match between the geographically adjacent access routers (GAAR). It is asserted in this draft that the primary consideration for fast handover and CAR discovery will still be layer 3 QoS parameters as supported by the ARs. The TAR selection demands that the capability set of the CARs is available and should necessarily meet the MN's requirements. While the TAR selection process can happen at the time of handover, the GAARs which have the capabilities to meet the MN's requirements can be identified in advance. Whether the CAR and subsequently the TAR identification is done in advance of at the time of handover there will have to be a constant exchange of capabilities between the current AR Satish et Al [Page 1] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 and the GAARs. This motivates us to propose a CAR discovery protocol using CT messages thus resulting in signaling advantages. Our protocol qualifies to be what is called the CAR discovery protocol. Table of Contents 1. Introduction 2 1.1. Conventions Used In This Document 4 1.2. Terminology 4 2. The CAR Discovery Protocol 5 2.1. Capability exchange between GAARs - From GAARs to CARs 6 2.1.1. Capability list in the PPCT 6 2.2. Target Access Router (TAR) Selection 7 3. Modified Messages used by the CAR Discovery Protocol 8 3.1. Modified PCT for GAAR identification 8 3.2. CT Messages to aid in TAR identification 10 4. Mobile Node (MN) Operation 10 5. Access Router (AR) Operation 10 6. Security Considerations 11 7. References 11 8. Author's Addresses 12 1. INTRODUCTION There are existing solutions [1, 2] that enable mobile nodes (MNs) to execute IP-level handovers between the points of attachment (called access routers or ARs) to IP network. Additionally, work is underway [3, 4, 5, 6, 7], to define protocols that would allow seamless, i.e., low latency and low packet loss, handovers of MNs between ARs. These seamless handover solutions assume that the identity of the target AR TAR) for the MN's handover is known to the current AR. It is required to develop a protocol that would allow an AR to identify the TAR for MN's handover. We identify two important components in the problem of TAR selection. They are as follows: 1) Identifying the neighboring or geographically adjacent ARs sufficiently in advance of the handover, which have the capability set required to meet the MN's requirements. This process leads to a set of CARs, which not only are geographically adjacent but also meet any initial context based filtering criteria that can be used. Such initial filtering to identify CARs based on a critical, common feature set as required by all or a subset of the MNs attached to an AR is briefly discussed in a later section. 2) Choosing the TAR either at the time of handover from the set of CARs, or much earlier if possible with the help of additional Satish et Al [Page 2] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 information such as any additional context information, local policy, MN's preferences etc. Three approaches, namely, anticipated, dynamic and hybrid, have been outlined in [8] for CAR discovery. In the "anticipated" approach, the current AR identifies the CARs for handover prior to the handover process. At the time of handover, the TAR is identified by the current AR from the set of CARs. If CAR selection is "dynamic", the MN is actively involved in the CAR discovery process. The MN identifies the neighboring ARs as well as their capabilities and selects the TAR. This information is then forwarded to the current AR. A "hybrid" approach lies in between these two. In this draft, we argue that any AR that embarks on the CAR discovery process to aid in seamless handover can achieve identification of geographically adjacent access routers at a high level and as a further step can identify those ARs that cover in some sense an aggregate of the QoS supported by the discovery initiating AR. We also argue that the process of specifically identifying the target access router should involve the MN or the MN specific QoS and policy considerations. We specify a protocol where the discovery initiating AR initially identifies the GAARs and then uses CT messages as described in [10] with the "aggregate QoS" to identify a broad set of CARs. Then the actual identification of the TAR from the CARs can involve the use of CT messages by the specific MN or the initiating AR. The identification of the TAR given a set of CARs can be initiated by the MN or can be proactively achieved by the AR on behalf of the MN. Here the initiating AR can use triggers as specified in the fast handover draft [3] to initiate a MN specific TAR identification based on the MNs context state in that AR. In our protocol we assume that the MN may not be in a position to listen to a neighboring beacon i.e. the MN may not have or might not prefer to have (due to power, interference considerations) two L2 connections UP simultaneously. The protocol should cater to this situation well. In case a MN has the capability to listen to advertisements over two L2s simultaneously A MN can listen to beacons from neighboring access points and forward the information in the beacon to the AR it is currently attached to. The TAR selection protocol can then take this as an initiation to identify the TAR. Our protocol can cater to both the cases though we believe that the former should be given more consideration because of power and other interference constraints that might arise with two L2s being UP simultaneously. TAR selection will have to consider other parameters like user preferences and policies along with CARs to uniquely identify the TAR. The algorithms (like distance measures between the QoS descriptors etc) used in TAR selection, however is out of scope for this document. Satish et Al [Page 3] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 1.2. Terminology Access Point (AP) : A layer 2 device to which the MN connects to through a wireless link. An AP may connect to one or more ARs. An AR may be connected to connected to APs belonging to different technologies. Access Router (AR) : An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MN. When dealing with IPv4 based networks running Mobile IPv4, Foreign Agents (FAs) take the place of ARs. Geographically Adjacent AR (GAAR) : An AR whose coverage area is such that an MN may move from the coverage area of the AR currently serving the MN into the coverage area of this AR. Physical Neighborhood List (PNL) : The set of GAARs along with their capabilities maintained at an AR. Candidate AR (CAR) : This is an AR that is a candidate for MN's handover. Candidate AR is "physically adjacent" to the AR currently serving the MN, and has the capability set required to serve the MN. Target AR (TAR) : This is an AR with which the procedures for MN's handover are initiated. Border Router (BR) : Globally IP addressable router through which a privately addressable network connects to the Internet. IP-level Identity of an AR : This is the IP address of an AR if the address is globally routable. However, if an AR resides in a private IP address space, this is a tuple (border router's globally routable IP address, AR identifier recognized by the BR). Satish et Al [Page 4] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 2. THE CAR DISCOVERY PROTOCOL A basic requirement for a new AR to be considered as a CAR for a MN is that the coverage area of the new AR be "geographically adjacent" to that of the AR currently serving the MN. Note that, the geographical adjacency of two ARs is not necessarily implied by their "logical" adjacency [9]. Manually configuring this physical neighborhood at each AR as described in [8] has disadvantages and in many cases, may not be feasible. We describe a dynamic mechanism to identify GAARs for each AR. It is described with reference to Figure 1. MN +-----------+ +-+ | Current | < | | ---------- | AR | ------ > ----\ +-+ | | < \ +-----------+ \ | +--------+ Handover | Capability ^ IP | Corr. | | Exchange | Network |Node(CN)| V (PPCT message) | +--------+ v / MN +-----------+ / +-+ --------> | New | < / | | ---------- | AR | ------ > ----/ +-+ | | < +-----------+ Figure 1: Reference Scenario for Handovers In Figure 1, the current AR broadcasts the "physical coverage area" to all its logically adjacent ARs and the new AR adds this identity to its Physical Neighborhood List (PNL) if this entry does not already exist and associates a lifetime to it. The lifetime field is refreshed if the entry already exists. This "Router Identity" message can be sent to the new AR as an ICMP option. The "Partial Proactive CT (PPCT)" is derived from the PCT message defined in [10] and this can be broadcast by an edge device or a border gateway or by the AR itself to the new AR. The PPCT broadcast SHOULD essentially be an edge device function. If the MN can detect the identity of the new AR by listening to its beacon while still connected to the old AR, then the MN MUST forward this identity to the old AR. It again uses the Router Identity message for this purpose. Satish et Al [Page 5] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 If the MN receives the L2 identity of the AP in the AP's beacon it forwards this information to the current AR also through the Router Identity message. A Physical Neighborhood List (PNL) [9] is maintained at an AR and there is one entry in the PNL for each GAAR of an AR that has been identified so far. The capability set maintained is not elaborate in the sense that a minimum but essential set is identified. The objective is just to be able to identify CARs from the GAARs. 2.1. Capability exchange between GAARs - From GAARs to CARs In future IP networks, the GAARs will be heterogeneous in administrative control, function, capability, link layer technology and resources available for packet sessions. Further the MN will have specific requirements as regards these parameters. The knowledge of GAARs' capabilities allows the current AR to choose CARs from GAARs. Hence, the current AR needs to identify the capability set of each of its GAARs to arrive at the CAR set. The PPCT message is sent to a new GAAR over the wired Internet enlisting the AR's capabilities. On receiving this message, the recipient GAAR responds with another PPCT message detailing its own capabilities. The capability information obtained via this message is used to populate the "Capability Set" field in the PNL. GAARs MAY also exchange the status of capabilities periodically or on-demand. 2.1.1. Capability list in the PPCT Capabilities can broadly be divided into dynamic and static. Static capabilities do not change over time, while dynamic capabilities do. Some of the capabilities are specific to a particular MN, and MAY be exchanged on demand. There may be other capabilities which are more generic and which may specify information relevant to all MNs. The capability exchange is achieved through the use of CT [10] messages. The CAR discovery protocol SHOULD make a distinction between that set of capabilities that can be used by the AR in choosing CARs from GAARs independent of the MN considerations and those that are used in the actual TAR identification. Some of the context parameter considerations that the RIM should support in order to help in CAR identification by any AR are listed below. - Administrative parameters: ISP name, organizational ownership, device authentication and authorization data, policy information; - Cost of access: Dollar cost per QoS class; Satish et Al [Page 6] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 - Available radio interfaces that are geographically adjacent to given AR: 802.11, WCDMA, GSM; - Availability of application logic: Multicast support, playout buffer hosting for streaming applications, TCP performance enhancing proxies (PEPs), media transcoding functionality, header compression functionality; - Internet connectivity parameters: NAT traversal for connectivity; - Resource parameters: Existing load, available bandwidth are some of the resource parameters that can be used. - Identities of APs (layer 2 identities) that are served by the AR. Once GAARs are identified through the PPCT messages, the current AR identifies the CARs for a particular MN as GAARs whose capabilities meets either a broad set of MNs grouped together based on the applications or services that they are running or the MN's capability requirements. 2.2. Target Access Router (TAR) Selection Assuming that the current AR has done a good job of identifying a minimal set of CARs from which the MN has to choose a TAR, the actual TAR selection can be based on explicit MN triggers (MN initiated) or the AR initiated. The TAR selection algorithm can reside in the MN or at the AR. The following figures (2 and 3) depicts the scenarios mentioned above. +----------+ +----------+ | | 3. SHREQ | | | |-----------------| | 2. Trigger | Prtr | 4. SHREP | Nrtr | ------> | | | | | | <-------------> | | | | 1. PPCT (CARs) | | +----------+ +----------+ | ^ ^ | | | | | 5. Proxy router | | | ~~ solicitation v | | V V +-+ +-+ | | 6. movement | | +-+ ---------------> +-+ Figure 2: CAR discovery protocol (AR initiated handover) Satish et Al [Page 7] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 In anticipated CAR discovery the AR can help find the exact TAR for the mobile node and then notify the MN about the new AR for handover. This can be the case under certain load conditions when the AR wants to force some MNs to new ARs. +----------+ +----------+ | | 3. SHREQ | | | Prtr |-----------------| Nrtr | | | 4. SHREP | | | | | | | | <-----------> | | +----------+ 1. PPCT (CARs) +----------+ ^ ^ | | | | 2. Trigger | | ~~ | | V V +-+ +-+ | | 5. movement | | +-+ ---------------> +-+ Figure 3: CAR discovery Protocol (MN initiated handover) In the case of the dynamic CAR discovery the MN initiates the TAR discovery. The process of identifying the TAR for the MN's handover forms the final step of the TAR selection process. This step is performed at the time of handover. The TAR selection algorithm selects a unique TAR from the set of CARs. For this it also uses the AR reachability information for the MN at the time of handover. In addition, other aspects such as local policy and MN's preferences are also applied during the decision- making. The details of TAR selection algorithm are not within the scope of CAR discovery protocol. The TAR selection is aided through the CT messages like SHREQ and SHREP [10] where the exact list of context parameters are exchanged on a per MN basis and the TAR selection algorithm run over these parameters. The MNs can be an active or a passive participant in the TAR selection process. 3. MODIFIED MESSAGES USED BY THE CAR DISCOVERY PROTOCOL 3.1. Modified PCT for GAAR identification We are using a modified PCT message [10] as mentioned below to achieve the GAAR list and further the CAR list from a given set of GAARs. We call this message the PPCT (Partial proactive context transfer). Satish et Al [Page 8] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=PPCT | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Multicast or broadcast IP Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit AR IP Address (Paddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Geographic coverage information +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Transfer Options Data... (Initial capability set) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthTken| Sub-Option Len| Algorithm | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Partial Proactive Context Transfer Option Format Option Type Partial Proactive Context Transfer (PPCT) Option Length Variable Geographic coverage information Covers the Geographic coverage area information (either coordinates or through symbolic means) Context Transfer Options Data Individual feature contexts in the form of sub options. These are encoded in Sub-Option Type and Sub-Option Length format, as in the structure of SHIN message [10]. Algorithm 8-bit algorithm indication for computing the Authentication Token [10]. Key Length 8-bit unsigned integer. The length of the key in units of 4 octets. Key Encrypted key. The Key is encrypted using a pre-existing shared key between the Access Routers. Satish et Al [Page 9] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 The identification of the GAARs and CARs should be done independently of the MN as this reduces delays for a MN during handover, to inform the AR about the identities of GAARs. The motivation is that the AR SHOULD provide the MAXIMUM support for any seamless handover. This is motivated by the fact that the MN can be constrained by power and over the air signaling issues. The SEAMOBY WG SHOULD lay more emphasis on evolving protocols that reduce the over-the-air signaling. The increase in the wire-line signaling is acceptable. 3.2. CT Messages to aid in TAR identification In our protocol (refer figure 2 and 3) we suggest the use of the SHREQ and SHREP [10] messages for the complete context exchange on a per mobile basis. This helps the MN or the AR in identifying the TAR. The TAR selection algorithm can be resident in the AR or the MN. During the TAR identification process a partial context transfer would have occurred. This can be used to reduce the signaling during the CT operation. 4. MOBILE NODE (MN) OPERATION The following item summarizes the operations at the MN: - Maintains information about current AR's IP Identity. - Listen to L2 triggers or any other triggers for the MN initiated TAR identification. - Sends the SHIN [10] message to the AR to initiate the TAR identification process. If the new AR field in the SHIN message is left blank, the AR initiates TAR selection process. - When a MN moves to a new AR it forwards the previous AR's IP Identity to the new AR. 5. ACCESS ROUTER (AR) OPERATION The following items summarize the operations at the AR: - The AR maintains a PNL. - Upon receiving a PPCT message containing the identity of a GAAR, the AR checks to see whether the entry for this GAAR exists in the PNL. If it does, the AR refreshes the lifetime of the entry. Satish et Al [Page 10] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 - Identifies CARs based on the MN's requirements and capability parameters of GAARs recorded in the PNL. The current AR may solicit any MN-specific requirements from the GAARs. - The AR solicits the complete context information of the CARs through the SHREQ and SHREP messages on a per MN basis on receipt of a trigger either at AR or at the MN. 6. SECURITY CONSIDERATIONS In our protocol the use of CT messages during the CAR discovery provides for some level of security as some security features are in built in the CT messages [10]. Further it is required to discuss the security considerations involved in performing GAAR discovery. The security association between GAARs for the exchange of capability information can be established using standard methods for device authentication, key exchange and encryption. 7. REFERENCES [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. [2] Mobility Support in IPv6, D. Johnson and C. Perkins, draft-ietf-mobileip-ipv6-13.txt, work in progress, November 2000. [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, draft-ietf-mobileip-lowlatency-handovers-v4-00.txt, work in progress, February 2001. [4] Fast handovers for Mobile IPv6, MIPv6 handover Design Team, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 2001. [5] Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network, O. H. Levkowetz et. al., draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in progress, May 2001. [6] General requirements for a context transfer framework, H. Sayed et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in progress, May 2001. [7] Buffer Management for Smooth handovers in Mobile IPv6, G. Krishnamurthi, R. Chalmers, C. Perkins, draft-krishnamurthi-mobileip-buffer6-01.txt, work in progress, March 2001. Satish et Al [Page 11] Internet Draft A Combined CT and CAR Discovery Protocol Mar 2002 [8] Issues in Candidate Access Router Discovery, D. Trossen, G Krishnamurthi, H. Chaskar, J. Kempf, draft-ietf-seamoby-CARdiscovery-02.txt, work in progress, November 2001. [9] Protocol for Candidate Access Router Discovery for Seamless IP- level Handovers, Dirk Trossen, Govind Krishnamurthi, Hemant Chaskar, Eunsoo Shim, Richard D. Gitlin, draft-trossen-seamoby-cardiscovery-00.txt, work in progress, November 2001. [10] R Koodli, C.E. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ctv6-02.txt, November 2001. 8. AUTHOR'S ADDRESSES Satish Jamadagni, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3029 Fax: +91 80 5351133 Email: satishj@sasken.com Satish D, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3164 Fax: +91 80 5351133 Email: satishd@sasken.com Shiva Raman Pandey, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3296 Fax: +91 80 5351133 Email: shiva@sasken.com Satish et Al [Page 12] ------=_NextPart_000_0064_01C1DA38.F647F820-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 02:09: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 BAA29304 for ; Tue, 2 Apr 2002 01:17:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18179 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 01:17: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 AAA07429; Tue, 2 Apr 2002 00:58: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 AAA07402 for ; Tue, 2 Apr 2002 00:58:44 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28808 for ; Tue, 2 Apr 2002 00:58:43 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g325weq19161; Tue, 2 Apr 2002 00:58:40 -0500 Message-Id: <200204020558.g325weq19161@minotaur.nge.isi.edu> To: kempf@docomolabsusa-com, hemant.chaskar@nokia.com, dirk.trossen@nokia.com, govind.krishnamurthi@nokia.com Cc: seamoby@ietf.org Reply-To: mankin@isi.edu Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Apr 2002 00:58:40 -0500 From: Allison Mankin Subject: [Seamoby] Revision of car discovery issues draft requested Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Jim, Pat, You asked for publication of draft-ietf-seamoby-cardiscovery-issues-02.txt. An initial review raised a couple of concerns that I think should be addressed before full IESG review: 1. There is only a tiny mention of inter-technology handoff (in 5.2), but enabling this is a seamoby charter goal. As Steve Deering advised during the MN meeting, this could even be CAR discovery when going from wired to wireless...There could be a fifth scenario of a technology change - going from a crowded 802.11b to an uncongested 802.11a is another thought here. 2. The references need to be split into normative and informative. If the draft must (as it now reads) be normatively dependent on the fast handoff drafts from mobileip, it will have to await their publication. 3. The points in section 7 should be prefaced with a comment on their sketchiness - they are a too brief treatment. It is not clear that any treatment of solutions belongs in this draft. Editorial: Grammar is shaky in "The following sections describe the specific issues in the CAR discovery, may it be done in anticipated, dynamic or hybrid way." _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 02:09: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 BAA29278 for ; Tue, 2 Apr 2002 01: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 AAA06833; Tue, 2 Apr 2002 00:38: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 AAA06805 for ; Tue, 2 Apr 2002 00:38:04 -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 AAA28516 for ; Tue, 2 Apr 2002 00:38:00 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g325buP07473; Tue, 2 Apr 2002 11:07:56 +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 g325btL19996; Tue, 2 Apr 2002 11:07:55 +0530 (IST) Message-ID: <001401c1da08$b15e37e0$9224010a@SATISHJ> From: "Satish Jamadagni" To: "Nakhjiri Madjid-MNAKHJI1" , "'Hemant Chaskar'" , References: <35DBB8B7AC89D4118E98009027B1009B0465000A@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 11:09:01 +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 All, I feel that CT and CAR should go hand in hand. The reasons are as follows (taking a Bottom - Up approach trying to arrive at a CAR protocol from a final TAR selection perspective assuming that this is what CAR discovery is supposed to assist in) Combining CT and CAR - 1. Saves signaling time (Time is one of the main factors for deciding seamless ness) 2. Makes sense as during a seamless HO "Context" preservation is what every mobile terminal aims at (we are not considering application adaptation and such kind of stuff) 3. Typical TAR selection would be based on a "MATCH" of the MN context and the AR context support capabilities (any other policies and user fancies can also be brougnt under the "Context" perspective (I assume that "context" reflects a desired QoS feel at the MT so for all practical purposes "Context" and QoS are the same). For a TAR selection the MT would send in his present "Context" list to find a match. This I guess would be sent to all CARs (with all the signaling overheads) So for all practical purposes by the time I would have done a TAR selection I would have at least achieved a partial CT if the new AR can preserve the messages that I use for initial inquiry for TAR selection. All other CARs where the MT would have sent a message with a wish list ( its present context) can release the context list if the MT finally does not choose them based on a timer. So I feel a CAR discovery protocol SHOULD identify and standardize "an ABSTRACT Context" notion for initial CAR selection and finally should provide for classes of Contexts to ease the TAR selection process. The exact match algorithms can be left to implementations. Such classes of contexts helps in either a partial or a full CT under TAR selection itself. Combining CT and CAR has signaling advantages and this can prove critical for a seamless handover where the "objective is Zero latency handover" Regards, Satish Jamadagni. ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'Hemant Chaskar'" ; Sent: Tuesday, April 02, 2002 5:46 AM Subject: RE: [Seamoby] Examples of CAR discovery > Bingo, Hemant, > > you hit it right in the bulls eye. CAR discovery is > about finding the destination, CT will happen after you found > the destination. QoS CT will only help maintaining QoS after > (or during) the handoff, but it cannot be used to determine > where to handoff to. > > Madjid > > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Monday, April 01, 2002 10:45 AM > To: seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hi James: > > Pardon my ignorance here, but isn't CT about *transferring* context rather > than negotiating capabilities. In other words, doesn't CT protocol take > source and dest. of CT as input? Now, source is obvious, we still need to > work on finding dest. which is target AR of handoff. > > BR, > Hemant > > > >From: "James Kempf" > >To: "Charlie Perkins" > >CC: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Examples of CAR discovery > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > >Hi Charlie, > > > > > > > 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. > > > > > > >This sounds like context transfer, not CAR discovery. QoS was one of the > >intended applications of context transfer, so I believe it is in scope. > > > > 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 > > _______________________________________________ > Seamoby mailing 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 Apr 2 03:37: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 DAA09924 for ; Tue, 2 Apr 2002 03:37:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26815 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 03:37: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 DAA25387; Tue, 2 Apr 2002 03:12: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 DAA25357 for ; Tue, 2 Apr 2002 03:12:51 -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 DAA09521 for ; Tue, 2 Apr 2002 03:12:48 -0500 (EST) From: john.loughney@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 g328D5527519 for ; Tue, 2 Apr 2002 11:13:05 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 11:12:49 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:12:49 +0300 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, 2 Apr 2002 11:12:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHXmMCOP9UWlkH2TbyN6LLpvZ5niACg8mmg To: , Cc: X-OriginalArrivalTime: 02 Apr 2002 08:12:49.0153 (UTC) FILETIME=[2D926F10:01C1DA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25358 Subject: [Seamoby] NSIS 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: 8bit Hi James, > > 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. NSIS will not be involved in the handoff, nor resource allocation. There may be some longer term work which would handle signaling between network elements that would look more like capability signaling, but that is outside of the current scope of NSIS. I think that NSIS and SeaMoby / Context Transfer may interwork to provide a good solution, in my opinion. NSIS most likely will be using a 'on path' signaling model, where the QoS signaling takes the same path as the data. > 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. Actually, this is current out of scope of NSIS. What NSIS will be working on is a generalized framework, to enable end to edge signaling, end to end signaling and perhaps edge to edge signaling. For the end-to-edge signaling, the access network (maybe even the access router) would/could be proxying QoS for network towards the end node. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 03:44: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 DAA10049 for ; Tue, 2 Apr 2002 03:44: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 DAA25516; Tue, 2 Apr 2002 03:16: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 DAA25486 for ; Tue, 2 Apr 2002 03:16:21 -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 DAA09567 for ; Tue, 2 Apr 2002 03:16:13 -0500 (EST) From: john.loughney@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 g328GU500606 for ; Tue, 2 Apr 2002 11:16:30 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 11:16:14 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:16:14 +0300 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: Tue, 2 Apr 2002 11:16:13 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D5F@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHY6vYASujVDUTPQYqsjmmIbtbpZABM0g0A To: , , X-OriginalArrivalTime: 02 Apr 2002 08:16:14.0441 (UTC) FILETIME=[A7EEE590:01C1DA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25487 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 it sounds to me like dynamic QoS negotiation for handover > has fallen between the cracks of the WGs. Do we need full-blown dynamic QoS negotiation for handover? Originally (meaning circa last spring, after the MicroMobility work was removed from SeaMoby), part of the access router section work was to be a capabilities exchange between ARs, or so I thought. Thinking in terms of baby steps, havning some mechanism which allows a basic mechanisms (which may end up looking like context tranfer) would not be a bad thing. To express it more concretely, AR1 and AR2 exchange capability information. This could be done using context transfer even ... John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 03:44: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 DAA10059 for ; Tue, 2 Apr 2002 03:44:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA27149 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 03:44: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 DAA25516; Tue, 2 Apr 2002 03:16: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 DAA25486 for ; Tue, 2 Apr 2002 03:16:21 -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 DAA09567 for ; Tue, 2 Apr 2002 03:16:13 -0500 (EST) From: john.loughney@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 g328GU500606 for ; Tue, 2 Apr 2002 11:16:30 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 11:16:14 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:16:14 +0300 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: Tue, 2 Apr 2002 11:16:13 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D5F@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHY6vYASujVDUTPQYqsjmmIbtbpZABM0g0A To: , , X-OriginalArrivalTime: 02 Apr 2002 08:16:14.0441 (UTC) FILETIME=[A7EEE590:01C1DA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25487 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 it sounds to me like dynamic QoS negotiation for handover > has fallen between the cracks of the WGs. Do we need full-blown dynamic QoS negotiation for handover? Originally (meaning circa last spring, after the MicroMobility work was removed from SeaMoby), part of the access router section work was to be a capabilities exchange between ARs, or so I thought. Thinking in terms of baby steps, havning some mechanism which allows a basic mechanisms (which may end up looking like context tranfer) would not be a bad thing. To express it more concretely, AR1 and AR2 exchange capability information. This could be done using context transfer even ... John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 03:44: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 DAA10077 for ; Tue, 2 Apr 2002 03:44: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 DAA25614; Tue, 2 Apr 2002 03:18: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 DAA25583 for ; Tue, 2 Apr 2002 03:18:19 -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 DAA09591 for ; Tue, 2 Apr 2002 03:18:14 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g328IV502282 for ; Tue, 2 Apr 2002 11:18:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 11:18:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:18:14 +0300 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, 2 Apr 2002 11:18:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D60@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHZIb/yHy8edXvvRw+jdv5heVMVmQA/PJsw To: Cc: X-OriginalArrivalTime: 02 Apr 2002 08:18:15.0130 (UTC) FILETIME=[EFDE93A0:01C1DA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25584 Subject: [Seamoby] NSIS 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: 8bit Hi Andrew, > NSIS has a very strong mobility dimension to it, > which I find very interesting, but odd. The reason being is that QoS generally has some problems with mobility (maybe that is what makes it 'interesting'). The signaling protocol that NSIS works on should be robust in the presence of mobility. One possible way to achieve this is to support context transfer between access routers within NSIS. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 04:19: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 EAA10406 for ; Tue, 2 Apr 2002 04:19: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 DAA27338; Tue, 2 Apr 2002 03:49: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 DAA27313 for ; Tue, 2 Apr 2002 03:49:28 -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 DAA10165 for ; Tue, 2 Apr 2002 03:49:26 -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 g328nNs22029; Tue, 2 Apr 2002 03:49:23 -0500 From: "Andrew T. Campbell" To: Cc: Subject: RE: [Seamoby] NSIS was: Examples of CAR discovery Date: Tue, 2 Apr 2002 03:46:22 -0500 Message-ID: <00e101c1da22$de6db700$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: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D60@esebe004.NOE.Nokia.com> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John: Thanks for the clarification. Good luck with NSIS. --- Andrew http://comet.columbia.edu/~campbell > -----Original Message----- > From: seamoby-admin@ietf.org > [mailto:seamoby-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Tuesday, April 02, 2002 3:18 AM > To: campbell@comet.columbia.edu > Cc: seamoby@ietf.org > Subject: [Seamoby] NSIS was: Examples of CAR discovery > > > Hi Andrew, > > > NSIS has a very strong mobility dimension to it, > > which I find very interesting, but odd. > > The reason being is that QoS generally has some problems > with mobility (maybe that is what makes it 'interesting'). > The signaling protocol that NSIS works on should be robust > in the presence of mobility. One possible way to achieve > this is to support context transfer between access routers > within NSIS. > > 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 Tue Apr 2 04:19: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 EAA10415 for ; Tue, 2 Apr 2002 04:19:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28673 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 04:19: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 DAA27338; Tue, 2 Apr 2002 03:49: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 DAA27313 for ; Tue, 2 Apr 2002 03:49:28 -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 DAA10165 for ; Tue, 2 Apr 2002 03:49:26 -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 g328nNs22029; Tue, 2 Apr 2002 03:49:23 -0500 From: "Andrew T. Campbell" To: Cc: Subject: RE: [Seamoby] NSIS was: Examples of CAR discovery Date: Tue, 2 Apr 2002 03:46:22 -0500 Message-ID: <00e101c1da22$de6db700$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: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D60@esebe004.NOE.Nokia.com> Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit John: Thanks for the clarification. Good luck with NSIS. --- Andrew http://comet.columbia.edu/~campbell > -----Original Message----- > From: seamoby-admin@ietf.org > [mailto:seamoby-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Tuesday, April 02, 2002 3:18 AM > To: campbell@comet.columbia.edu > Cc: seamoby@ietf.org > Subject: [Seamoby] NSIS was: Examples of CAR discovery > > > Hi Andrew, > > > NSIS has a very strong mobility dimension to it, > > which I find very interesting, but odd. > > The reason being is that QoS generally has some problems > with mobility (maybe that is what makes it 'interesting'). > The signaling protocol that NSIS works on should be robust > in the presence of mobility. One possible way to achieve > this is to support context transfer between access routers > within NSIS. > > 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 Tue Apr 2 04:24: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 DAA09915 for ; Tue, 2 Apr 2002 03:37: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 DAA25387; Tue, 2 Apr 2002 03:12: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 DAA25357 for ; Tue, 2 Apr 2002 03:12:51 -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 DAA09521 for ; Tue, 2 Apr 2002 03:12:48 -0500 (EST) From: john.loughney@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 g328D5527519 for ; Tue, 2 Apr 2002 11:13:05 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 11:12:49 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:12:49 +0300 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, 2 Apr 2002 11:12:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHXmMCOP9UWlkH2TbyN6LLpvZ5niACg8mmg To: , Cc: X-OriginalArrivalTime: 02 Apr 2002 08:12:49.0153 (UTC) FILETIME=[2D926F10:01C1DA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25358 Subject: [Seamoby] NSIS 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: 8bit Hi James, > > 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. NSIS will not be involved in the handoff, nor resource allocation. There may be some longer term work which would handle signaling between network elements that would look more like capability signaling, but that is outside of the current scope of NSIS. I think that NSIS and SeaMoby / Context Transfer may interwork to provide a good solution, in my opinion. NSIS most likely will be using a 'on path' signaling model, where the QoS signaling takes the same path as the data. > 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. Actually, this is current out of scope of NSIS. What NSIS will be working on is a generalized framework, to enable end to edge signaling, end to end signaling and perhaps edge to edge signaling. For the end-to-edge signaling, the access network (maybe even the access router) would/could be proxying QoS for network towards the end node. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 04:39: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 DAA10086 for ; Tue, 2 Apr 2002 03:44:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA27170 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 03: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 DAA25614; Tue, 2 Apr 2002 03:18: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 DAA25583 for ; Tue, 2 Apr 2002 03:18:19 -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 DAA09591 for ; Tue, 2 Apr 2002 03:18:14 -0500 (EST) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g328IV502282 for ; Tue, 2 Apr 2002 11:18:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Apr 2002 11:18:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 2 Apr 2002 11:18:14 +0300 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, 2 Apr 2002 11:18:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D60@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHZIb/yHy8edXvvRw+jdv5heVMVmQA/PJsw To: Cc: X-OriginalArrivalTime: 02 Apr 2002 08:18:15.0130 (UTC) FILETIME=[EFDE93A0:01C1DA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25584 Subject: [Seamoby] NSIS 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: 8bit Hi Andrew, > NSIS has a very strong mobility dimension to it, > which I find very interesting, but odd. The reason being is that QoS generally has some problems with mobility (maybe that is what makes it 'interesting'). The signaling protocol that NSIS works on should be robust in the presence of mobility. One possible way to achieve this is to support context transfer between access routers within NSIS. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 04: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 EAA10675 for ; Tue, 2 Apr 2002 04: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 EAA28716; Tue, 2 Apr 2002 04:20: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 EAA28687 for ; Tue, 2 Apr 2002 04:20: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 EAA10439 for ; Tue, 2 Apr 2002 04:20:11 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 6EF8B22E15; Tue, 2 Apr 2002 12:19:42 +0300 (EEST) Date: Tue, 2 Apr 2002 12:19:00 +0300 (EEST) From: Teemu Rinta-aho To: James Kempf Cc: Phillip Neumiller , "'Charlie Perkins'" , Subject: Re: [Seamoby] Examples of CAR discovery In-Reply-To: <00d801c1d744$b7a3fc50$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 Fri, 29 Mar 2002, James Kempf wrote: > > > 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. What if these two access points doing the same wireless link protocol are connected to different access routers, possibly belonging to different ISPs? Then they can have different QoS all the way from the MN to the CN. For example, the first access router may be connected to the internet with broadband cable and the other access router may be a mobile router using satellite uplink? 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 Apr 2 04: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 EAA10683 for ; Tue, 2 Apr 2002 04:39:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29896 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 04:39: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 EAA28716; Tue, 2 Apr 2002 04:20: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 EAA28687 for ; Tue, 2 Apr 2002 04:20: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 EAA10439 for ; Tue, 2 Apr 2002 04:20:11 -0500 (EST) Received: from n42.nomadiclab.com (n42.nomadiclab.com [131.160.193.42]) by n2.nomadiclab.com (Postfix) with ESMTP id 6EF8B22E15; Tue, 2 Apr 2002 12:19:42 +0300 (EEST) Date: Tue, 2 Apr 2002 12:19:00 +0300 (EEST) From: Teemu Rinta-aho To: James Kempf Cc: Phillip Neumiller , "'Charlie Perkins'" , Subject: Re: [Seamoby] Examples of CAR discovery In-Reply-To: <00d801c1d744$b7a3fc50$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 Fri, 29 Mar 2002, James Kempf wrote: > > > 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. What if these two access points doing the same wireless link protocol are connected to different access routers, possibly belonging to different ISPs? Then they can have different QoS all the way from the MN to the CN. For example, the first access router may be connected to the internet with broadband cable and the other access router may be a mobile router using satellite uplink? 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 Apr 2 10:54: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 KAA20049 for ; Tue, 2 Apr 2002 10:54: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 KAA18371; Tue, 2 Apr 2002 10:26: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 KAA18338 for ; Tue, 2 Apr 2002 10:26:15 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18938 for ; Tue, 2 Apr 2002 10:26:12 -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 g32FPTU00175; Tue, 2 Apr 2002 10:25:30 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:25:30 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 10:25:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA5A.9E2A743E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA5A.9E2A743E Content-Type: text/plain; charset="iso-8859-1" Satish: The reason that CT should remain separate from CAR is that CT is useful in many scenarios where CAR is not required. Consider the (trivial) case of an access network engineered to provide all the necessary QoS capabilities at each AR (note: this does not mean that the network is homogenous, just designed/configure with forethought). Indeed, if saving time during handover is the issue, then it is always faster to do as little signalling as possible, which, for some networks, would be CT without CAR. A similar argument can be put forth for the use of an NSIS solution during handover. Note that I am talking in the general case here, there will always be situations where the network (including the MNs) will have to resort to signalling to maintain or re-establish sessions. Mobility is always about probabilistic success, and it is overkill to apply worse case solutions to all scenarios. Gary > -----Original Message----- > From: Satish Jamadagni [mailto:satishj@sasken.com] > Sent: April 2, 2002 00:39 > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hi All, > I feel that CT and CAR should go hand in hand. The reasons > are as follows > (taking a Bottom - Up approach trying to arrive at a CAR > protocol from a > final TAR selection perspective assuming that this is what > CAR discovery is > supposed to assist in) > > Combining CT and CAR - > 1. Saves signaling time (Time is one of the main factors for deciding > seamless ness) > 2. Makes sense as during a seamless HO "Context" preservation > is what every > mobile terminal aims at (we are not considering application > adaptation and > such kind of stuff) > 3. Typical TAR selection would be based on a "MATCH" of the > MN context and > the AR context support capabilities (any other policies and > user fancies can > also be brougnt under the "Context" perspective (I assume > that "context" > reflects a desired QoS feel at the MT so for all practical purposes > "Context" and QoS are the same). > > For a TAR selection the MT would send in his present > "Context" list to find > a match. This I guess would be sent to all CARs (with all the > signaling > overheads) > > So for all practical purposes by the time I would have done a > TAR selection > I would have at least achieved a partial CT if the new AR can > preserve the > messages that I use for initial inquiry for TAR selection. > All other CARs > where the MT would have sent a message with a wish list ( its present > context) can release the context list if the MT finally does > not choose them > based on a timer. > > So I feel a CAR discovery protocol SHOULD identify and standardize "an > ABSTRACT Context" notion for initial CAR selection and finally should > provide for classes of Contexts to ease the TAR selection > process. The exact > match algorithms can be left to implementations. Such > classes of contexts > helps in either a partial or a full CT under TAR selection itself. > > Combining CT and CAR has signaling advantages and this can > prove critical > for a seamless handover where the "objective is Zero latency handover" > > Regards, > Satish Jamadagni. > > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'Hemant Chaskar'" ; > Sent: Tuesday, April 02, 2002 5:46 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > Bingo, Hemant, > > > > you hit it right in the bulls eye. CAR discovery is > > about finding the destination, CT will happen after you found > > the destination. QoS CT will only help maintaining QoS after > > (or during) the handoff, but it cannot be used to determine > > where to handoff to. > > > > Madjid > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Monday, April 01, 2002 10:45 AM > > To: seamoby@ietf.org > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hi James: > > > > Pardon my ignorance here, but isn't CT about *transferring* > context rather > > than negotiating capabilities. In other words, doesn't CT > protocol take > > source and dest. of CT as input? Now, source is obvious, we > still need to > > work on finding dest. which is target AR of handoff. > > > > BR, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Charlie Perkins" > > >CC: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > >Hi Charlie, > > > > > > > > > > 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. > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > was one of the > > >intended applications of context transfer, so I believe it > is in scope. > > > > > > 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 > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C1DA5A.9E2A743E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery

Satish:

  The reason that CT should remain separate from CAR is that
CT is useful in many scenarios where CAR is not required. Consider
the (trivial) case of an access network engineered to provide all
the necessary QoS capabilities at each AR (note: this does not mean
that the network is homogenous, just designed/configure with forethought).

  Indeed, if saving time during handover is the issue, then it is
always faster to do as little signalling as possible, which, for
some networks, would be CT without CAR.

  A similar argument can be put forth for the use of an NSIS solution
during handover. Note that I am talking in the general case here, there will
always be situations where the network (including the MNs) will have to
resort to signalling to maintain or re-establish sessions. Mobility is
always about probabilistic success, and it is overkill to apply worse
case solutions to all scenarios.

Gary

> -----Original Message-----
> From: Satish Jamadagni [mailto:satishj@sasken.com]
> Sent: April 2, 2002 00:39
> To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR discovery
>
>
> Hi All,
> I feel that CT and CAR should go hand in hand. The reasons
> are as follows
> (taking a Bottom - Up approach trying to arrive at a CAR
> protocol from a
> final TAR selection perspective assuming that this is what
> CAR discovery is
> supposed to assist in)
>
> Combining CT and CAR -
> 1. Saves signaling time (Time is one of the main factors for deciding
> seamless ness)
> 2. Makes sense as during a seamless HO "Context" preservation
> is what every
> mobile terminal aims at (we are not considering application
> adaptation and
> such kind of stuff)
> 3. Typical TAR selection would be based on a "MATCH" of the
> MN context and
> the AR context support capabilities (any other policies and
> user fancies can
> also be brougnt under the "Context" perspective (I assume
> that "context"
> reflects a desired QoS feel at the MT so for all practical purposes
> "Context" and QoS are the same).
>
> For a TAR selection the MT would send in his present
> "Context" list to find
> a match. This I guess would be sent to all CARs (with all the
> signaling
> overheads)
>
> So for all practical purposes by the time I would have done a
> TAR selection
> I would have at least achieved a partial CT if the new AR can
> preserve the
> messages that I use for initial inquiry for TAR selection.
> All other CARs
> where the MT would have sent a message with a wish list ( its present
> context) can release the context list if the MT finally does
> not choose them
> based on a timer.
>
> So I feel a CAR discovery protocol SHOULD identify and standardize "an
> ABSTRACT Context" notion for initial CAR selection and finally should
> provide for classes of Contexts to ease the TAR selection
> process. The exact
> match algorithms  can be left to implementations. Such
> classes of contexts
> helps in either a partial or a full CT under TAR selection itself.
>
> Combining CT and CAR has signaling advantages and this can
> prove critical
> for a seamless handover where the "objective is Zero latency handover"
>
> Regards,
> Satish Jamadagni.
>
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> To: "'Hemant Chaskar'" <hchaskar@hotmail.com>; <seamoby@ietf.org>
> Sent: Tuesday, April 02, 2002 5:46 AM
> Subject: RE: [Seamoby] Examples of CAR discovery
>
>
> > Bingo, Hemant,
> >
> > you hit it right in the bulls eye. CAR discovery is
> > about finding the destination, CT will happen after you found
> > the destination. QoS CT will only help maintaining QoS after
> > (or during) the handoff, but it cannot be used to determine
> > where to handoff to.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> > Sent: Monday, April 01, 2002 10:45 AM
> > To: seamoby@ietf.org
> > Subject: Re: [Seamoby] Examples of CAR discovery
> >
> >
> > Hi James:
> >
> > Pardon my ignorance here, but isn't CT about *transferring*
> context rather
> > than negotiating capabilities. In other words, doesn't CT
> protocol take
> > source and dest. of CT as input? Now, source is obvious, we
> still need to
> > work on finding dest. which is target AR of handoff.
> >
> > BR,
> > Hemant
> >
> >
> > >From: "James Kempf" <kempf@docomolabs-usa.com>
> > >To: "Charlie Perkins" <charliep@iprg.nokia.com>
> > >CC: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] Examples of CAR discovery
> > >Date: Mon, 1 Apr 2002 08:16:02 -0800
> > >
> > >Hi Charlie,
> > >
> > >
> > > > 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.
> > > >
> > >
> > >This sounds like context transfer, not CAR discovery. QoS
> was one of the
> > >intended applications of context transfer, so I believe it
> is in scope.
> > >
> > >             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
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby


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

------_=_NextPart_001_01C1DA5A.9E2A743E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 10: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 KAA20059 for ; Tue, 2 Apr 2002 10:54:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20179 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 10:54: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 KAA18371; Tue, 2 Apr 2002 10:26: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 KAA18338 for ; Tue, 2 Apr 2002 10:26:15 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18938 for ; Tue, 2 Apr 2002 10:26:12 -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 g32FPTU00175; Tue, 2 Apr 2002 10:25:30 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 10:25:30 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 10:25:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA5A.9E2A743E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA5A.9E2A743E Content-Type: text/plain; charset="iso-8859-1" Satish: The reason that CT should remain separate from CAR is that CT is useful in many scenarios where CAR is not required. Consider the (trivial) case of an access network engineered to provide all the necessary QoS capabilities at each AR (note: this does not mean that the network is homogenous, just designed/configure with forethought). Indeed, if saving time during handover is the issue, then it is always faster to do as little signalling as possible, which, for some networks, would be CT without CAR. A similar argument can be put forth for the use of an NSIS solution during handover. Note that I am talking in the general case here, there will always be situations where the network (including the MNs) will have to resort to signalling to maintain or re-establish sessions. Mobility is always about probabilistic success, and it is overkill to apply worse case solutions to all scenarios. Gary > -----Original Message----- > From: Satish Jamadagni [mailto:satishj@sasken.com] > Sent: April 2, 2002 00:39 > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > Hi All, > I feel that CT and CAR should go hand in hand. The reasons > are as follows > (taking a Bottom - Up approach trying to arrive at a CAR > protocol from a > final TAR selection perspective assuming that this is what > CAR discovery is > supposed to assist in) > > Combining CT and CAR - > 1. Saves signaling time (Time is one of the main factors for deciding > seamless ness) > 2. Makes sense as during a seamless HO "Context" preservation > is what every > mobile terminal aims at (we are not considering application > adaptation and > such kind of stuff) > 3. Typical TAR selection would be based on a "MATCH" of the > MN context and > the AR context support capabilities (any other policies and > user fancies can > also be brougnt under the "Context" perspective (I assume > that "context" > reflects a desired QoS feel at the MT so for all practical purposes > "Context" and QoS are the same). > > For a TAR selection the MT would send in his present > "Context" list to find > a match. This I guess would be sent to all CARs (with all the > signaling > overheads) > > So for all practical purposes by the time I would have done a > TAR selection > I would have at least achieved a partial CT if the new AR can > preserve the > messages that I use for initial inquiry for TAR selection. > All other CARs > where the MT would have sent a message with a wish list ( its present > context) can release the context list if the MT finally does > not choose them > based on a timer. > > So I feel a CAR discovery protocol SHOULD identify and standardize "an > ABSTRACT Context" notion for initial CAR selection and finally should > provide for classes of Contexts to ease the TAR selection > process. The exact > match algorithms can be left to implementations. Such > classes of contexts > helps in either a partial or a full CT under TAR selection itself. > > Combining CT and CAR has signaling advantages and this can > prove critical > for a seamless handover where the "objective is Zero latency handover" > > Regards, > Satish Jamadagni. > > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'Hemant Chaskar'" ; > Sent: Tuesday, April 02, 2002 5:46 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > Bingo, Hemant, > > > > you hit it right in the bulls eye. CAR discovery is > > about finding the destination, CT will happen after you found > > the destination. QoS CT will only help maintaining QoS after > > (or during) the handoff, but it cannot be used to determine > > where to handoff to. > > > > Madjid > > > > -----Original Message----- > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > Sent: Monday, April 01, 2002 10:45 AM > > To: seamoby@ietf.org > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hi James: > > > > Pardon my ignorance here, but isn't CT about *transferring* > context rather > > than negotiating capabilities. In other words, doesn't CT > protocol take > > source and dest. of CT as input? Now, source is obvious, we > still need to > > work on finding dest. which is target AR of handoff. > > > > BR, > > Hemant > > > > > > >From: "James Kempf" > > >To: "Charlie Perkins" > > >CC: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Examples of CAR discovery > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > >Hi Charlie, > > > > > > > > > > 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. > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > was one of the > > >intended applications of context transfer, so I believe it > is in scope. > > > > > > 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 > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C1DA5A.9E2A743E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery

Satish:

  The reason that CT should remain separate from CAR is that
CT is useful in many scenarios where CAR is not required. Consider
the (trivial) case of an access network engineered to provide all
the necessary QoS capabilities at each AR (note: this does not mean
that the network is homogenous, just designed/configure with forethought).

  Indeed, if saving time during handover is the issue, then it is
always faster to do as little signalling as possible, which, for
some networks, would be CT without CAR.

  A similar argument can be put forth for the use of an NSIS solution
during handover. Note that I am talking in the general case here, there will
always be situations where the network (including the MNs) will have to
resort to signalling to maintain or re-establish sessions. Mobility is
always about probabilistic success, and it is overkill to apply worse
case solutions to all scenarios.

Gary

> -----Original Message-----
> From: Satish Jamadagni [mailto:satishj@sasken.com]
> Sent: April 2, 2002 00:39
> To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR discovery
>
>
> Hi All,
> I feel that CT and CAR should go hand in hand. The reasons
> are as follows
> (taking a Bottom - Up approach trying to arrive at a CAR
> protocol from a
> final TAR selection perspective assuming that this is what
> CAR discovery is
> supposed to assist in)
>
> Combining CT and CAR -
> 1. Saves signaling time (Time is one of the main factors for deciding
> seamless ness)
> 2. Makes sense as during a seamless HO "Context" preservation
> is what every
> mobile terminal aims at (we are not considering application
> adaptation and
> such kind of stuff)
> 3. Typical TAR selection would be based on a "MATCH" of the
> MN context and
> the AR context support capabilities (any other policies and
> user fancies can
> also be brougnt under the "Context" perspective (I assume
> that "context"
> reflects a desired QoS feel at the MT so for all practical purposes
> "Context" and QoS are the same).
>
> For a TAR selection the MT would send in his present
> "Context" list to find
> a match. This I guess would be sent to all CARs (with all the
> signaling
> overheads)
>
> So for all practical purposes by the time I would have done a
> TAR selection
> I would have at least achieved a partial CT if the new AR can
> preserve the
> messages that I use for initial inquiry for TAR selection.
> All other CARs
> where the MT would have sent a message with a wish list ( its present
> context) can release the context list if the MT finally does
> not choose them
> based on a timer.
>
> So I feel a CAR discovery protocol SHOULD identify and standardize "an
> ABSTRACT Context" notion for initial CAR selection and finally should
> provide for classes of Contexts to ease the TAR selection
> process. The exact
> match algorithms  can be left to implementations. Such
> classes of contexts
> helps in either a partial or a full CT under TAR selection itself.
>
> Combining CT and CAR has signaling advantages and this can
> prove critical
> for a seamless handover where the "objective is Zero latency handover"
>
> Regards,
> Satish Jamadagni.
>
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> To: "'Hemant Chaskar'" <hchaskar@hotmail.com>; <seamoby@ietf.org>
> Sent: Tuesday, April 02, 2002 5:46 AM
> Subject: RE: [Seamoby] Examples of CAR discovery
>
>
> > Bingo, Hemant,
> >
> > you hit it right in the bulls eye. CAR discovery is
> > about finding the destination, CT will happen after you found
> > the destination. QoS CT will only help maintaining QoS after
> > (or during) the handoff, but it cannot be used to determine
> > where to handoff to.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> > Sent: Monday, April 01, 2002 10:45 AM
> > To: seamoby@ietf.org
> > Subject: Re: [Seamoby] Examples of CAR discovery
> >
> >
> > Hi James:
> >
> > Pardon my ignorance here, but isn't CT about *transferring*
> context rather
> > than negotiating capabilities. In other words, doesn't CT
> protocol take
> > source and dest. of CT as input? Now, source is obvious, we
> still need to
> > work on finding dest. which is target AR of handoff.
> >
> > BR,
> > Hemant
> >
> >
> > >From: "James Kempf" <kempf@docomolabs-usa.com>
> > >To: "Charlie Perkins" <charliep@iprg.nokia.com>
> > >CC: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] Examples of CAR discovery
> > >Date: Mon, 1 Apr 2002 08:16:02 -0800
> > >
> > >Hi Charlie,
> > >
> > >
> > > > 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.
> > > >
> > >
> > >This sounds like context transfer, not CAR discovery. QoS
> was one of the
> > >intended applications of context transfer, so I believe it
> is in scope.
> > >
> > >             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
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby


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

------_=_NextPart_001_01C1DA5A.9E2A743E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 11:02: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 LAA20387 for ; Tue, 2 Apr 2002 11:02: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 KAA19724; Tue, 2 Apr 2002 10:43: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 KAA19643 for ; Tue, 2 Apr 2002 10:43:52 -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 KAA19512 for ; Tue, 2 Apr 2002 10:43:49 -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 g32Fhps7026747 for ; Tue, 2 Apr 2002 17:43:51 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 17:41:36 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:43:30 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABEE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:43:23 +0200 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 Charlie, Just catching up with the Easter email! > I'd like to suggest that we allow handovers based on availability > of resources for less than 100ms. The handover can be accomplished > in a lot shorter than that amount of time, and the CAR discovery is > exactly for the purposes of doing a handover. Why disallow the more > dynamic behavior? => Do you have some proof that this assertion will hold in all cases? I mean the 100 ms time limit. I'm curious because I haven't seen anything published on that and I'd like to know under what assumptions this statement would hold. Hesham > > > There is another issue here. Suppose we consider a dynamic QoS > > measurement on the order of 200 ms and a total (L2 + L3) > handover time > > of 40 ms as in previous email. Now, just for the sake of argument, > > suppose we consider that the QoS measurement delivers 20 > bytes of data, > > minus IPv6 headers which are removed by header > compression. This should > > be enough for the IPv6 address of the access router and a > 4 byte QoS > > level. By my calculation, that is approximately 8kbps > just to deliver > > QoS measurement data to the mobile node. That's a lot of > bandwidth. In > > fact, it is more bandwidth than is used to deliver > cellular voice in > > current 3G systems. > > Are you worried about delivering _any_ data to the mobile node? > What was special about QoS data here? If we had 20 bytes of data > to be delivered to the mobile node, that wouldn't take very long > compared to the handover time. Do you suggest that this be > delivered > periodically? I would not like that! Otherwise, I don't see how > the 8kbps figure was arrived at... > > >> I would think that CARD would "naturally" be constrained > to consider > >> dynamic behavior with time constants not less than, say, 30 ms. > > > > I see the time constant as rather higher, more like seconds. > > Are you saying that a quantity being measured has to be stable for > seconds, before a mobile node can act on the measurement? > > This is not right, I'm pretty sure. Consider the following: > > - CAR agrees to provide video QoS to a mobile node. CAR even > reserves the capacity for 100ms, waiting for the node to arrive. > > - Another customer shows up 120ms later (we have lots of > customers :-) > and uses up that video bandwidth > > By your definition, the mobile node should not even consider CAR, > because CAR is unwilling to tie up its resources for more than 100ms > just on the _prospect_ of a handover. By my understanding, it would > be better (for smoother handovers) for the CAR to reserve > the bandwidth, > but it would be uneconomical to do so for "seconds". > > > I think one needs to distinguish between InterTHO and IntraTHO. I > > believe the time constants can be considerably different, > and the need > > for involvement of the mobile, it's user, or potentially > software agents > > acting on behalf of the user, are considerably different. > For InterTHO, > > the time constant can be up to seconds, for IntraTHO it > is 10's of ms. > > The time constant _could_ be large, but even for InterTHO it does > not have to be -- the two interfaces could (and often would) be on > the same router. I would hope that we don't have to deal > with mobile > agents here. > > Besides that, IP-layer stuff should not depend on the specifics > of the technology (i.e., the 'T'). It should work over whatever > reasonable technology is going to support handovers. Maybe not > carrier pigeons. > > >> Regarding (3), note that a local optimization for time and > >> smoothness is "typically" not good for wide-area optimization > >> of network paths. Chained tunnels provide a good illustration > >> about why this is the case. It would be even worse for extended > >> patch-ups to QoS. > > > > I'm not sure I understand your point. I agree about > chained tunnels, but > > I don't see how this applies to QoS. > > Nothing deep here... If I get QoS at the router, by appending a > QoS-reserved path between access routers to a QoS-reserved path > ending at the previous access router, I get QoS, but it takes more > network resources than would otherwise be necessary. > > >> Another way of saying this, is that although CARD is separable > >> from smooth handover, it has to be considered in light of what > >> is likely to happen once the discovery takes place. And, I > >> would also say that we should be allowed to discover whatever > >> information by way of (1) that would be use during process (2). > > > > Again, I think the distinction between InterTHO and IntraTHO is > > important. > > I don't think we should design CAR discovery around such a > distinction. Of course, it's important for any reasonable > system design, but that does not have to affect the discovery > protocol by which CARs are identified. > > 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 Tue Apr 2 11:02: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 LAA20409 for ; Tue, 2 Apr 2002 11:02:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21154 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 11:02: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 KAA19724; Tue, 2 Apr 2002 10:43: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 KAA19643 for ; Tue, 2 Apr 2002 10:43:52 -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 KAA19512 for ; Tue, 2 Apr 2002 10:43:49 -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 g32Fhps7026747 for ; Tue, 2 Apr 2002 17:43:51 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 02 17:41:36 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:43:30 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABEE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:43:23 +0200 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 Charlie, Just catching up with the Easter email! > I'd like to suggest that we allow handovers based on availability > of resources for less than 100ms. The handover can be accomplished > in a lot shorter than that amount of time, and the CAR discovery is > exactly for the purposes of doing a handover. Why disallow the more > dynamic behavior? => Do you have some proof that this assertion will hold in all cases? I mean the 100 ms time limit. I'm curious because I haven't seen anything published on that and I'd like to know under what assumptions this statement would hold. Hesham > > > There is another issue here. Suppose we consider a dynamic QoS > > measurement on the order of 200 ms and a total (L2 + L3) > handover time > > of 40 ms as in previous email. Now, just for the sake of argument, > > suppose we consider that the QoS measurement delivers 20 > bytes of data, > > minus IPv6 headers which are removed by header > compression. This should > > be enough for the IPv6 address of the access router and a > 4 byte QoS > > level. By my calculation, that is approximately 8kbps > just to deliver > > QoS measurement data to the mobile node. That's a lot of > bandwidth. In > > fact, it is more bandwidth than is used to deliver > cellular voice in > > current 3G systems. > > Are you worried about delivering _any_ data to the mobile node? > What was special about QoS data here? If we had 20 bytes of data > to be delivered to the mobile node, that wouldn't take very long > compared to the handover time. Do you suggest that this be > delivered > periodically? I would not like that! Otherwise, I don't see how > the 8kbps figure was arrived at... > > >> I would think that CARD would "naturally" be constrained > to consider > >> dynamic behavior with time constants not less than, say, 30 ms. > > > > I see the time constant as rather higher, more like seconds. > > Are you saying that a quantity being measured has to be stable for > seconds, before a mobile node can act on the measurement? > > This is not right, I'm pretty sure. Consider the following: > > - CAR agrees to provide video QoS to a mobile node. CAR even > reserves the capacity for 100ms, waiting for the node to arrive. > > - Another customer shows up 120ms later (we have lots of > customers :-) > and uses up that video bandwidth > > By your definition, the mobile node should not even consider CAR, > because CAR is unwilling to tie up its resources for more than 100ms > just on the _prospect_ of a handover. By my understanding, it would > be better (for smoother handovers) for the CAR to reserve > the bandwidth, > but it would be uneconomical to do so for "seconds". > > > I think one needs to distinguish between InterTHO and IntraTHO. I > > believe the time constants can be considerably different, > and the need > > for involvement of the mobile, it's user, or potentially > software agents > > acting on behalf of the user, are considerably different. > For InterTHO, > > the time constant can be up to seconds, for IntraTHO it > is 10's of ms. > > The time constant _could_ be large, but even for InterTHO it does > not have to be -- the two interfaces could (and often would) be on > the same router. I would hope that we don't have to deal > with mobile > agents here. > > Besides that, IP-layer stuff should not depend on the specifics > of the technology (i.e., the 'T'). It should work over whatever > reasonable technology is going to support handovers. Maybe not > carrier pigeons. > > >> Regarding (3), note that a local optimization for time and > >> smoothness is "typically" not good for wide-area optimization > >> of network paths. Chained tunnels provide a good illustration > >> about why this is the case. It would be even worse for extended > >> patch-ups to QoS. > > > > I'm not sure I understand your point. I agree about > chained tunnels, but > > I don't see how this applies to QoS. > > Nothing deep here... If I get QoS at the router, by appending a > QoS-reserved path between access routers to a QoS-reserved path > ending at the previous access router, I get QoS, but it takes more > network resources than would otherwise be necessary. > > >> Another way of saying this, is that although CARD is separable > >> from smooth handover, it has to be considered in light of what > >> is likely to happen once the discovery takes place. And, I > >> would also say that we should be allowed to discover whatever > >> information by way of (1) that would be use during process (2). > > > > Again, I think the distinction between InterTHO and IntraTHO is > > important. > > I don't think we should design CAR discovery around such a > distinction. Of course, it's important for any reasonable > system design, but that does not have to affect the discovery > protocol by which CARs are identified. > > 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 Tue Apr 2 11:03: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 LAA20453 for ; Tue, 2 Apr 2002 11:03: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 KAA20060; Tue, 2 Apr 2002 10:51: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 KAA20031 for ; Tue, 2 Apr 2002 10:51:35 -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 KAA19805 for ; Tue, 2 Apr 2002 10:51:33 -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 HAA16375; Tue, 2 Apr 2002 07:51:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32Fp3H09982; Tue, 2 Apr 2002 07:51:03 -0800 X-mProtect: <200204021551> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdri1VK0; Tue, 02 Apr 2002 07:51:01 PST Message-ID: <3CA9D366.4736C6AE@iprg.nokia.com> Date: Tue, 02 Apr 2002 07:51:02 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <4DA6EA82906FD511BE2F00508BCF053802C6ABEE@Esealnt861.al.sw.ericsson.se> 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 Hesham, "Hesham Soliman (ERA)" wrote: > => Do you have some proof that this assertion will > hold in all cases? I mean the 100 ms time limit. > I'm curious because I haven't seen anything published > on that and I'd like to know under what assumptions > this statement would hold. Of course it does not hold in all cases. But it does hold in some cases of interest (e.g., 802.11), and we ought to be making the protocol work for those cases. I don't know what kind of assumptions you would want to hear. One easy assumption is, "the handover can occur in under 100ms" -- but somehow I expect you were asking for more... Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 11:03: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 LAA20462 for ; Tue, 2 Apr 2002 11:03:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21246 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 11:03: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 KAA20060; Tue, 2 Apr 2002 10:51: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 KAA20031 for ; Tue, 2 Apr 2002 10:51:35 -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 KAA19805 for ; Tue, 2 Apr 2002 10:51:33 -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 HAA16375; Tue, 2 Apr 2002 07:51:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32Fp3H09982; Tue, 2 Apr 2002 07:51:03 -0800 X-mProtect: <200204021551> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdri1VK0; Tue, 02 Apr 2002 07:51:01 PST Message-ID: <3CA9D366.4736C6AE@iprg.nokia.com> Date: Tue, 02 Apr 2002 07:51:02 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <4DA6EA82906FD511BE2F00508BCF053802C6ABEE@Esealnt861.al.sw.ericsson.se> 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 Hesham, "Hesham Soliman (ERA)" wrote: > => Do you have some proof that this assertion will > hold in all cases? I mean the 100 ms time limit. > I'm curious because I haven't seen anything published > on that and I'd like to know under what assumptions > this statement would hold. Of course it does not hold in all cases. But it does hold in some cases of interest (e.g., 802.11), and we ought to be making the protocol work for those cases. I don't know what kind of assumptions you would want to hear. One easy assumption is, "the handover can occur in under 100ms" -- but somehow I expect you were asking for more... Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 11:08: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 LAA20723 for ; Tue, 2 Apr 2002 11:08: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 KAA20285; Tue, 2 Apr 2002 10:55: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 KAA20242 for ; Tue, 2 Apr 2002 10:55: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 KAA20094 for ; Tue, 2 Apr 2002 10:55: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 g32Fti3G017549 for ; Tue, 2 Apr 2002 17:55:44 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 17:55:43 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:55:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABF0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , "Hesham Soliman (ERA)" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:55:38 +0200 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 > > => Do you have some proof that this assertion will > > hold in all cases? I mean the 100 ms time limit. > > I'm curious because I haven't seen anything published > > on that and I'd like to know under what assumptions > > this statement would hold. > > Of course it does not hold in all cases. But it does > hold in some cases of interest (e.g., 802.11), and we ought > to be making the protocol work for those cases. > > I don't know what kind of assumptions you would want > to hear. One easy assumption is, "the handover can > occur in under 100ms" -- but somehow I expect you > were asking for more... => Yes, I meant the assumptions related to movement detection. It seems that (in the absence of Fast Handovers) we would need to crank up the RA rate on all links to satisfy this time limit. I don't know how network administrators would like that. I don't think it would be a problem for a small sized RA though (without all the options), the big RAs can be sent when the options are timing out. Regs, Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 11: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 LAA20736 for ; Tue, 2 Apr 2002 11:08:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21447 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 11:08: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 KAA20285; Tue, 2 Apr 2002 10:55: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 KAA20242 for ; Tue, 2 Apr 2002 10:55: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 KAA20094 for ; Tue, 2 Apr 2002 10:55: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 g32Fti3G017549 for ; Tue, 2 Apr 2002 17:55:44 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 17:55:43 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:55:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABF0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , "Hesham Soliman (ERA)" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:55:38 +0200 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 > > => Do you have some proof that this assertion will > > hold in all cases? I mean the 100 ms time limit. > > I'm curious because I haven't seen anything published > > on that and I'd like to know under what assumptions > > this statement would hold. > > Of course it does not hold in all cases. But it does > hold in some cases of interest (e.g., 802.11), and we ought > to be making the protocol work for those cases. > > I don't know what kind of assumptions you would want > to hear. One easy assumption is, "the handover can > occur in under 100ms" -- but somehow I expect you > were asking for more... => Yes, I meant the assumptions related to movement detection. It seems that (in the absence of Fast Handovers) we would need to crank up the RA rate on all links to satisfy this time limit. I don't know how network administrators would like that. I don't think it would be a problem for a small sized RA though (without all the options), the big RAs can be sent when the options are timing out. Regs, Hesham _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 11:18: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 LAA21239 for ; Tue, 2 Apr 2002 11:18: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 KAA20390; Tue, 2 Apr 2002 10:57: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 KAA20360 for ; Tue, 2 Apr 2002 10:57:42 -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 KAA20146 for ; Tue, 2 Apr 2002 10:57:40 -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 g32Fvf3G018208 for ; Tue, 2 Apr 2002 17:57:42 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 17:57:41 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:47:28 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABF1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Charles E. Perkins'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:57:40 +0200 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 > => Yes, I meant the assumptions related to > movement detection. It seems that (in the absence > of Fast Handovers) we would need to crank up > the RA rate on all links to satisfy this time > limit. I don't know how network administrators > would like that. I don't think it would ^ please add 'not' be a problem > for a small sized RA though (without all the options), > the big RAs can be sent when the options are timing out. > > Regs, > Hesham > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 11:18: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 LAA21249 for ; Tue, 2 Apr 2002 11:18:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22097 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 11:18: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 KAA20390; Tue, 2 Apr 2002 10:57: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 KAA20360 for ; Tue, 2 Apr 2002 10:57:42 -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 KAA20146 for ; Tue, 2 Apr 2002 10:57:40 -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 g32Fvf3G018208 for ; Tue, 2 Apr 2002 17:57:42 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 02 17:57:41 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:47:28 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABF1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Charles E. Perkins'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:57:40 +0200 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 > => Yes, I meant the assumptions related to > movement detection. It seems that (in the absence > of Fast Handovers) we would need to crank up > the RA rate on all links to satisfy this time > limit. I don't know how network administrators > would like that. I don't think it would ^ please add 'not' be a problem > for a small sized RA though (without all the options), > the big RAs can be sent when the options are timing out. > > Regs, > Hesham > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 11:31: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 LAA21752 for ; Tue, 2 Apr 2002 11:31: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 LAA22171; Tue, 2 Apr 2002 11:19: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 LAA22142 for ; Tue, 2 Apr 2002 11:19:53 -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 LAA21330 for ; Tue, 2 Apr 2002 11:19:50 -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 IAA17810; Tue, 2 Apr 2002 08:19:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32GJMi32217; Tue, 2 Apr 2002 08:19:22 -0800 X-mProtect: <200204021619> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdB0Ygtz; Tue, 02 Apr 2002 08:19:20 PST Message-ID: <3CA9DA08.3835C63D@iprg.nokia.com> Date: Tue, 02 Apr 2002 08:19:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <4DA6EA82906FD511BE2F00508BCF053802C6ABF0@Esealnt861.al.sw.ericsson.se> 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 Hesham, "Hesham Soliman (ERA)" wrote: > > I don't know what kind of assumptions you would want > > to hear. One easy assumption is, "the handover can > > occur in under 100ms" -- but somehow I expect you > > were asking for more... > > => Yes, I meant the assumptions related to > movement detection. It seems that (in the absence > of Fast Handovers) we would need to crank up > the RA rate on all links to satisfy this time > limit. I don't know how network administrators > would like that. I don't think it would be a problem > for a small sized RA though (without all the options), > the big RAs can be sent when the options are timing out. I would not like to see the CAR discovery protocol depend upon information within a periodic Router Advertisement. I would like to see that it should be possible to initiate CARDiscovery based on other signaling within the access network -- perhaps not even IP-based signaling, but instead something else which would initiate the handover process. Stuff in the Router Advertisement could indeed supply information to the mobile node. That could be solicited, and based on some sort of layer-two trigger within the mobile node. The CAR discovery could be done "long" before the layer-2 trigger occurred (even as much as 100ms!). Once the trigger occurs, things have to happen fast, and it would be nice if we had some candidates lined up. If you favor a periodic RA solution, that's fine with me too as long as it isn't the only way that CARD can be used. Earlier in my note, I had said: >> Of course it does not hold in all cases. But it does >> hold in some cases of interest (e.g., 802.11), and we ought >> to be making the protocol work for those cases. Actually, we ought to make the protocol "work" in _all_ cases. Some cases might allow faster operation of the protocol, or for it to be more useful. But, just as with context transfer, I would like to suggest that any such movement should not _require_ CAR discovery -- only that it work faster and better when it's available. A mobile node should be able to attach at a new access router with no context transfer, no CARD, and in fact no context at all. Everything could be built up from scratch, at the cost of additional latency and loss of performance. One might not deploy some context transfers or CAR discovery for carrier-pigeon layer-2s, but the protocol ought to still work at least to the extent of not crashing the mobile nodes. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 11:31: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 LAA21758 for ; Tue, 2 Apr 2002 11:31:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22951 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 11:31: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 LAA22171; Tue, 2 Apr 2002 11:19: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 LAA22142 for ; Tue, 2 Apr 2002 11:19:53 -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 LAA21330 for ; Tue, 2 Apr 2002 11:19:50 -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 IAA17810; Tue, 2 Apr 2002 08:19:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32GJMi32217; Tue, 2 Apr 2002 08:19:22 -0800 X-mProtect: <200204021619> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdB0Ygtz; Tue, 02 Apr 2002 08:19:20 PST Message-ID: <3CA9DA08.3835C63D@iprg.nokia.com> Date: Tue, 02 Apr 2002 08:19:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <4DA6EA82906FD511BE2F00508BCF053802C6ABF0@Esealnt861.al.sw.ericsson.se> 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 Hesham, "Hesham Soliman (ERA)" wrote: > > I don't know what kind of assumptions you would want > > to hear. One easy assumption is, "the handover can > > occur in under 100ms" -- but somehow I expect you > > were asking for more... > > => Yes, I meant the assumptions related to > movement detection. It seems that (in the absence > of Fast Handovers) we would need to crank up > the RA rate on all links to satisfy this time > limit. I don't know how network administrators > would like that. I don't think it would be a problem > for a small sized RA though (without all the options), > the big RAs can be sent when the options are timing out. I would not like to see the CAR discovery protocol depend upon information within a periodic Router Advertisement. I would like to see that it should be possible to initiate CARDiscovery based on other signaling within the access network -- perhaps not even IP-based signaling, but instead something else which would initiate the handover process. Stuff in the Router Advertisement could indeed supply information to the mobile node. That could be solicited, and based on some sort of layer-two trigger within the mobile node. The CAR discovery could be done "long" before the layer-2 trigger occurred (even as much as 100ms!). Once the trigger occurs, things have to happen fast, and it would be nice if we had some candidates lined up. If you favor a periodic RA solution, that's fine with me too as long as it isn't the only way that CARD can be used. Earlier in my note, I had said: >> Of course it does not hold in all cases. But it does >> hold in some cases of interest (e.g., 802.11), and we ought >> to be making the protocol work for those cases. Actually, we ought to make the protocol "work" in _all_ cases. Some cases might allow faster operation of the protocol, or for it to be more useful. But, just as with context transfer, I would like to suggest that any such movement should not _require_ CAR discovery -- only that it work faster and better when it's available. A mobile node should be able to attach at a new access router with no context transfer, no CARD, and in fact no context at all. Everything could be built up from scratch, at the cost of additional latency and loss of performance. One might not deploy some context transfers or CAR discovery for carrier-pigeon layer-2s, but the protocol ought to still work at least to the extent of not crashing the mobile nodes. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 11:57: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 LAA22931 for ; Tue, 2 Apr 2002 11:57: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 LAA23694; Tue, 2 Apr 2002 11: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 LAA23664 for ; Tue, 2 Apr 2002 11:45: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 LAA22295 for ; Tue, 2 Apr 2002 11: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 g32GiTI07345; Tue, 2 Apr 2002 08:44:29 -0800 (PST) Message-ID: <00b801c1da65$6f3ec020$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> Date: Tue, 2 Apr 2002 08:42:53 -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: NSIS 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 > What NSIS will be working on is a generalized framework, to enable > end to edge signaling, end to end signaling and perhaps edge to edge > signaling. > > For the end-to-edge signaling, the access network (maybe even the access > router) would/could be proxying QoS for network towards the end node. > So it sounds to me the only issue is that NSIS would look at prehandoff or posthandoff end to edge (host to network?) signaling rather than at the time of handoff, is that right? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 11:57: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 LAA22942 for ; Tue, 2 Apr 2002 11:57:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24722 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 11:57: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 LAA23694; Tue, 2 Apr 2002 11: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 LAA23664 for ; Tue, 2 Apr 2002 11:45: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 LAA22295 for ; Tue, 2 Apr 2002 11: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 g32GiTI07345; Tue, 2 Apr 2002 08:44:29 -0800 (PST) Message-ID: <00b801c1da65$6f3ec020$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> Date: Tue, 2 Apr 2002 08:42:53 -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: NSIS 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 > What NSIS will be working on is a generalized framework, to enable > end to edge signaling, end to end signaling and perhaps edge to edge > signaling. > > For the end-to-edge signaling, the access network (maybe even the access > router) would/could be proxying QoS for network towards the end node. > So it sounds to me the only issue is that NSIS would look at prehandoff or posthandoff end to edge (host to network?) signaling rather than at the time of handoff, is that right? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 12:04: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 MAA23350 for ; Tue, 2 Apr 2002 12:04: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 LAA23894; Tue, 2 Apr 2002 11:46: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 LAA23863 for ; Tue, 2 Apr 2002 11:46: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 LAA22334 for ; Tue, 2 Apr 2002 11:46: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 g32GjsI07381; Tue, 2 Apr 2002 08:45:54 -0800 (PST) Message-ID: <00be01c1da65$a18effe0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D5F@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 08:44: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 John, > > So it sounds to me like dynamic QoS negotiation for handover > > has fallen between the cracks of the WGs. > > Do we need full-blown dynamic QoS negotiation for handover? Originally > (meaning circa last spring, after the MicroMobility work was removed from > SeaMoby), part of the access router section work was to be a capabilities > exchange between ARs, or so I thought. Thinking in terms of baby steps, > havning some mechanism which allows a basic mechanisms (which may end up > looking like context tranfer) would not be a bad thing. > > To express it more concretely, AR1 and AR2 exchange capability information. > This could be done using context transfer even ... > I think what is desired here is a way to take IP level QoS into consideration when selecting the next access point and access router to move to. Today only power is taken into consideration, and that at Layer 2. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 12:04: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 MAA23361 for ; Tue, 2 Apr 2002 12:04:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26353 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 12:04: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 LAA23894; Tue, 2 Apr 2002 11:46: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 LAA23863 for ; Tue, 2 Apr 2002 11:46: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 LAA22334 for ; Tue, 2 Apr 2002 11:46: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 g32GjsI07381; Tue, 2 Apr 2002 08:45:54 -0800 (PST) Message-ID: <00be01c1da65$a18effe0$7e6015ac@T23KEMPF> From: "James Kempf" To: , , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D5F@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 08:44: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 John, > > So it sounds to me like dynamic QoS negotiation for handover > > has fallen between the cracks of the WGs. > > Do we need full-blown dynamic QoS negotiation for handover? Originally > (meaning circa last spring, after the MicroMobility work was removed from > SeaMoby), part of the access router section work was to be a capabilities > exchange between ARs, or so I thought. Thinking in terms of baby steps, > havning some mechanism which allows a basic mechanisms (which may end up > looking like context tranfer) would not be a bad thing. > > To express it more concretely, AR1 and AR2 exchange capability information. > This could be done using context transfer even ... > I think what is desired here is a way to take IP level QoS into consideration when selecting the next access point and access router to move to. Today only power is taken into consideration, and that at Layer 2. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 12:17: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 MAA24099 for ; Tue, 2 Apr 2002 12: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 MAA26645; Tue, 2 Apr 2002 12:07: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 MAA26571 for ; Tue, 2 Apr 2002 12:07:21 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23515 for ; Tue, 2 Apr 2002 12:07:19 -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 g32H6OZ03398; Tue, 2 Apr 2002 12:06:25 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:06:26 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA498B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 12:06:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA68.21714590" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA68.21714590 Content-Type: text/plain; charset="iso-8859-1" Actually, the usual measures for handover for wireless networks are very much QoS related. In noise limited systems (e.g. AMPS), the measure used is Signal to Noise Ratio (SNR); in interference limited systems (e.g. CDMA) the measure used is Carrier to Interference Ratio (CIR), where the interference comes from primarly other MNs. There are also a number of wireless data systems out there that use BER as a measure. In all of these cases, the measure is used to determine whether there is a "better" channel for communications. This is L2 QoS. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 2, 2002 11:44 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > John, > > > > So it sounds to me like dynamic QoS negotiation for handover > > > has fallen between the cracks of the WGs. > > > > Do we need full-blown dynamic QoS negotiation for handover? > Originally > > (meaning circa last spring, after the MicroMobility work was removed > from > > SeaMoby), part of the access router section work was to be a > capabilities > > exchange between ARs, or so I thought. Thinking in terms of baby > steps, > > havning some mechanism which allows a basic mechanisms > (which may end > up > > looking like context tranfer) would not be a bad thing. > > > > To express it more concretely, AR1 and AR2 exchange capability > information. > > This could be done using context transfer even ... > > > > I think what is desired here is a way to take IP level QoS into > consideration when selecting the next access point and access > router to > move to. Today only power is taken into consideration, and > that at Layer > 2. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DA68.21714590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Examples of CAR discovery

Actually, the usual measures for handover for = wireless networks are
very much QoS related. In noise limited systems = (e.g. AMPS), the measure
used is Signal to Noise Ratio (SNR); in interference = limited systems (e.g. CDMA)
the measure used is Carrier to Interference Ratio = (CIR), where the interference
comes from primarly other MNs. There are also a = number of wireless data systems
out there that use BER as a measure.

In all of these cases, the measure is used to = determine whether there is a "better"
channel for communications. This is L2 QoS.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: April 2, 2002 11:44
> To: john.loughney@nokia.com; = hchaskar@hotmail.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR = discovery
>
>
> John,
>
> > > So it sounds to me like dynamic QoS = negotiation for handover
> > > has fallen between the cracks of the = WGs.
> >
> > Do we need full-blown dynamic QoS = negotiation for handover?
> Originally
> > (meaning circa last spring, after the = MicroMobility work was removed
> from
> > SeaMoby), part of the access router = section work was to be a
> capabilities
> > exchange between ARs, or so I = thought.  Thinking in terms of baby
> steps,
> > havning some mechanism which allows a = basic mechanisms
> (which may end
> up
> > looking like context tranfer) would not be = a bad thing.
> >
> > To express it more concretely, AR1 and AR2 = exchange capability
> information.
> > This could be done using context transfer = even ...
> >
>
> I think what is desired here is a way to take = IP level QoS into
> consideration when selecting the next access = point and access
> router to
> move to. Today only power is taken into = consideration, and
> that at Layer
> 2.
>
>          = ;   jak
>
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DA68.21714590-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 12:17: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 MAA24109 for ; Tue, 2 Apr 2002 12:17:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28274 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 12:17: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 MAA26645; Tue, 2 Apr 2002 12:07: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 MAA26571 for ; Tue, 2 Apr 2002 12:07:21 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23515 for ; Tue, 2 Apr 2002 12:07:19 -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 g32H6OZ03398; Tue, 2 Apr 2002 12:06:25 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:06:26 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA498B@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 12:06:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA68.21714590" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA68.21714590 Content-Type: text/plain; charset="iso-8859-1" Actually, the usual measures for handover for wireless networks are very much QoS related. In noise limited systems (e.g. AMPS), the measure used is Signal to Noise Ratio (SNR); in interference limited systems (e.g. CDMA) the measure used is Carrier to Interference Ratio (CIR), where the interference comes from primarly other MNs. There are also a number of wireless data systems out there that use BER as a measure. In all of these cases, the measure is used to determine whether there is a "better" channel for communications. This is L2 QoS. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 2, 2002 11:44 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > John, > > > > So it sounds to me like dynamic QoS negotiation for handover > > > has fallen between the cracks of the WGs. > > > > Do we need full-blown dynamic QoS negotiation for handover? > Originally > > (meaning circa last spring, after the MicroMobility work was removed > from > > SeaMoby), part of the access router section work was to be a > capabilities > > exchange between ARs, or so I thought. Thinking in terms of baby > steps, > > havning some mechanism which allows a basic mechanisms > (which may end > up > > looking like context tranfer) would not be a bad thing. > > > > To express it more concretely, AR1 and AR2 exchange capability > information. > > This could be done using context transfer even ... > > > > I think what is desired here is a way to take IP level QoS into > consideration when selecting the next access point and access > router to > move to. Today only power is taken into consideration, and > that at Layer > 2. > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DA68.21714590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Examples of CAR discovery

Actually, the usual measures for handover for = wireless networks are
very much QoS related. In noise limited systems = (e.g. AMPS), the measure
used is Signal to Noise Ratio (SNR); in interference = limited systems (e.g. CDMA)
the measure used is Carrier to Interference Ratio = (CIR), where the interference
comes from primarly other MNs. There are also a = number of wireless data systems
out there that use BER as a measure.

In all of these cases, the measure is used to = determine whether there is a "better"
channel for communications. This is L2 QoS.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: April 2, 2002 11:44
> To: john.loughney@nokia.com; = hchaskar@hotmail.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR = discovery
>
>
> John,
>
> > > So it sounds to me like dynamic QoS = negotiation for handover
> > > has fallen between the cracks of the = WGs.
> >
> > Do we need full-blown dynamic QoS = negotiation for handover?
> Originally
> > (meaning circa last spring, after the = MicroMobility work was removed
> from
> > SeaMoby), part of the access router = section work was to be a
> capabilities
> > exchange between ARs, or so I = thought.  Thinking in terms of baby
> steps,
> > havning some mechanism which allows a = basic mechanisms
> (which may end
> up
> > looking like context tranfer) would not be = a bad thing.
> >
> > To express it more concretely, AR1 and AR2 = exchange capability
> information.
> > This could be done using context transfer = even ...
> >
>
> I think what is desired here is a way to take = IP level QoS into
> consideration when selecting the next access = point and access
> router to
> move to. Today only power is taken into = consideration, and
> that at Layer
> 2.
>
>          = ;   jak
>
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DA68.21714590-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 12:19: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 MAA24257 for ; Tue, 2 Apr 2002 12:19: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 MAA26464; Tue, 2 Apr 2002 12:05: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 MAA26439 for ; Tue, 2 Apr 2002 12: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 MAA23416 for ; Tue, 2 Apr 2002 12:05: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 g32H4RI08043; Tue, 2 Apr 2002 09:04:27 -0800 (PST) Message-ID: <012101c1da68$396c7e30$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> Date: Tue, 2 Apr 2002 09:02: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 Subject: [Seamoby] Re: NSIS 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 John, My concern here is that the right people may not be involved in Seamoby to adequately address this issue. People with QoS expertiese would not necessarily come to Seamoby. jak ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, April 02, 2002 12:12 AM Subject: NSIS was:Examples of CAR discovery > Hi James, > > > > 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. > > NSIS will not be involved in the handoff, nor resource allocation. > There may be some longer term work which would handle signaling between > network elements that would look more like capability signaling, > but that is outside of the current scope of NSIS. > > I think that NSIS and SeaMoby / Context Transfer may interwork to provide > a good solution, in my opinion. > > NSIS most likely will be using a 'on path' signaling model, where the > QoS signaling takes the same path as the data. > > > 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. > > Actually, this is current out of scope of NSIS. > > What NSIS will be working on is a generalized framework, to enable > end to edge signaling, end to end signaling and perhaps edge to edge > signaling. > > For the end-to-edge signaling, the access network (maybe even the access > router) would/could be proxying QoS for network towards the end node. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 12:19: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 MAA24266 for ; Tue, 2 Apr 2002 12:19:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28590 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 12:19: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 MAA26464; Tue, 2 Apr 2002 12:05: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 MAA26439 for ; Tue, 2 Apr 2002 12: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 MAA23416 for ; Tue, 2 Apr 2002 12:05: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 g32H4RI08043; Tue, 2 Apr 2002 09:04:27 -0800 (PST) Message-ID: <012101c1da68$396c7e30$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> Date: Tue, 2 Apr 2002 09:02: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 Subject: [Seamoby] Re: NSIS 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 John, My concern here is that the right people may not be involved in Seamoby to adequately address this issue. People with QoS expertiese would not necessarily come to Seamoby. jak ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, April 02, 2002 12:12 AM Subject: NSIS was:Examples of CAR discovery > Hi James, > > > > 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. > > NSIS will not be involved in the handoff, nor resource allocation. > There may be some longer term work which would handle signaling between > network elements that would look more like capability signaling, > but that is outside of the current scope of NSIS. > > I think that NSIS and SeaMoby / Context Transfer may interwork to provide > a good solution, in my opinion. > > NSIS most likely will be using a 'on path' signaling model, where the > QoS signaling takes the same path as the data. > > > 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. > > Actually, this is current out of scope of NSIS. > > What NSIS will be working on is a generalized framework, to enable > end to edge signaling, end to end signaling and perhaps edge to edge > signaling. > > For the end-to-edge signaling, the access network (maybe even the access > router) would/could be proxying QoS for network towards the end node. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 12: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 MAA24916 for ; Tue, 2 Apr 2002 12: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 MAA28174; Tue, 2 Apr 2002 12:16: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 MAA28136 for ; Tue, 2 Apr 2002 12:16:10 -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 MAA24077 for ; Tue, 2 Apr 2002 12:16: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 g32HFPI08440; Tue, 2 Apr 2002 09:15:25 -0800 (PST) Message-ID: <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Satish Jamadagni'" , "Nakhjiri Madjid-MNAKHJI1" , "'Hemant Chaskar'" , References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Tue, 2 Apr 2002 09:13: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 Gary/All, So I think what it comes down to is this. Is handover: 1) An opportunity for the mobile node to express its preferences for a new access router with characteristics that better match what the mobile node and its user need, 2) A link/routing failure that needs to be fixed up as quickly as possible. 3) Both of the above. Most of the discussion/disagreement/confusion (including my own) I've seen on this list seems to revolve around this question. My opinion: For intratechnology, Door Number 2. For intertechnology, Door Number 1. Comments? jak ----- Original Message ----- From: "Gary Kenward" To: "'Satish Jamadagni'" ; "Nakhjiri Madjid-MNAKHJI1" ; "'Hemant Chaskar'" ; Sent: Tuesday, April 02, 2002 7:25 AM Subject: RE: [Seamoby] Examples of CAR discovery > Satish: > > The reason that CT should remain separate from CAR is that > CT is useful in many scenarios where CAR is not required. Consider > the (trivial) case of an access network engineered to provide all > the necessary QoS capabilities at each AR (note: this does not mean > that the network is homogenous, just designed/configure with forethought). > > Indeed, if saving time during handover is the issue, then it is > always faster to do as little signalling as possible, which, for > some networks, would be CT without CAR. > > A similar argument can be put forth for the use of an NSIS solution > during handover. Note that I am talking in the general case here, there will > always be situations where the network (including the MNs) will have to > resort to signalling to maintain or re-establish sessions. Mobility is > always about probabilistic success, and it is overkill to apply worse > case solutions to all scenarios. > > Gary > > > -----Original Message----- > > From: Satish Jamadagni [mailto:satishj@sasken.com] > > Sent: April 2, 2002 00:39 > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hi All, > > I feel that CT and CAR should go hand in hand. The reasons > > are as follows > > (taking a Bottom - Up approach trying to arrive at a CAR > > protocol from a > > final TAR selection perspective assuming that this is what > > CAR discovery is > > supposed to assist in) > > > > Combining CT and CAR - > > 1. Saves signaling time (Time is one of the main factors for deciding > > seamless ness) > > 2. Makes sense as during a seamless HO "Context" preservation > > is what every > > mobile terminal aims at (we are not considering application > > adaptation and > > such kind of stuff) > > 3. Typical TAR selection would be based on a "MATCH" of the > > MN context and > > the AR context support capabilities (any other policies and > > user fancies can > > also be brougnt under the "Context" perspective (I assume > > that "context" > > reflects a desired QoS feel at the MT so for all practical purposes > > "Context" and QoS are the same). > > > > For a TAR selection the MT would send in his present > > "Context" list to find > > a match. This I guess would be sent to all CARs (with all the > > signaling > > overheads) > > > > So for all practical purposes by the time I would have done a > > TAR selection > > I would have at least achieved a partial CT if the new AR can > > preserve the > > messages that I use for initial inquiry for TAR selection. > > All other CARs > > where the MT would have sent a message with a wish list ( its present > > context) can release the context list if the MT finally does > > not choose them > > based on a timer. > > > > So I feel a CAR discovery protocol SHOULD identify and standardize "an > > ABSTRACT Context" notion for initial CAR selection and finally should > > provide for classes of Contexts to ease the TAR selection > > process. The exact > > match algorithms can be left to implementations. Such > > classes of contexts > > helps in either a partial or a full CT under TAR selection itself. > > > > Combining CT and CAR has signaling advantages and this can > > prove critical > > for a seamless handover where the "objective is Zero latency handover" > > > > Regards, > > Satish Jamadagni. > > > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'Hemant Chaskar'" ; > > Sent: Tuesday, April 02, 2002 5:46 AM > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > Bingo, Hemant, > > > > > > you hit it right in the bulls eye. CAR discovery is > > > about finding the destination, CT will happen after you found > > > the destination. QoS CT will only help maintaining QoS after > > > (or during) the handoff, but it cannot be used to determine > > > where to handoff to. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > Sent: Monday, April 01, 2002 10:45 AM > > > To: seamoby@ietf.org > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > Hi James: > > > > > > Pardon my ignorance here, but isn't CT about *transferring* > > context rather > > > than negotiating capabilities. In other words, doesn't CT > > protocol take > > > source and dest. of CT as input? Now, source is obvious, we > > still need to > > > work on finding dest. which is target AR of handoff. > > > > > > BR, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Charlie Perkins" > > > >CC: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > > > >Hi Charlie, > > > > > > > > > > > > > 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. > > > > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > > was one of the > > > >intended applications of context transfer, so I believe it > > is in scope. > > > > > > > > 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 > > > > _______________________________________________ > > Seamoby mailing 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 Tue Apr 2 12: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 MAA24926 for ; Tue, 2 Apr 2002 12:33:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00439 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 12: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 MAA28174; Tue, 2 Apr 2002 12:16: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 MAA28136 for ; Tue, 2 Apr 2002 12:16:10 -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 MAA24077 for ; Tue, 2 Apr 2002 12:16: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 g32HFPI08440; Tue, 2 Apr 2002 09:15:25 -0800 (PST) Message-ID: <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Satish Jamadagni'" , "Nakhjiri Madjid-MNAKHJI1" , "'Hemant Chaskar'" , References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Tue, 2 Apr 2002 09:13: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 Gary/All, So I think what it comes down to is this. Is handover: 1) An opportunity for the mobile node to express its preferences for a new access router with characteristics that better match what the mobile node and its user need, 2) A link/routing failure that needs to be fixed up as quickly as possible. 3) Both of the above. Most of the discussion/disagreement/confusion (including my own) I've seen on this list seems to revolve around this question. My opinion: For intratechnology, Door Number 2. For intertechnology, Door Number 1. Comments? jak ----- Original Message ----- From: "Gary Kenward" To: "'Satish Jamadagni'" ; "Nakhjiri Madjid-MNAKHJI1" ; "'Hemant Chaskar'" ; Sent: Tuesday, April 02, 2002 7:25 AM Subject: RE: [Seamoby] Examples of CAR discovery > Satish: > > The reason that CT should remain separate from CAR is that > CT is useful in many scenarios where CAR is not required. Consider > the (trivial) case of an access network engineered to provide all > the necessary QoS capabilities at each AR (note: this does not mean > that the network is homogenous, just designed/configure with forethought). > > Indeed, if saving time during handover is the issue, then it is > always faster to do as little signalling as possible, which, for > some networks, would be CT without CAR. > > A similar argument can be put forth for the use of an NSIS solution > during handover. Note that I am talking in the general case here, there will > always be situations where the network (including the MNs) will have to > resort to signalling to maintain or re-establish sessions. Mobility is > always about probabilistic success, and it is overkill to apply worse > case solutions to all scenarios. > > Gary > > > -----Original Message----- > > From: Satish Jamadagni [mailto:satishj@sasken.com] > > Sent: April 2, 2002 00:39 > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > Hi All, > > I feel that CT and CAR should go hand in hand. The reasons > > are as follows > > (taking a Bottom - Up approach trying to arrive at a CAR > > protocol from a > > final TAR selection perspective assuming that this is what > > CAR discovery is > > supposed to assist in) > > > > Combining CT and CAR - > > 1. Saves signaling time (Time is one of the main factors for deciding > > seamless ness) > > 2. Makes sense as during a seamless HO "Context" preservation > > is what every > > mobile terminal aims at (we are not considering application > > adaptation and > > such kind of stuff) > > 3. Typical TAR selection would be based on a "MATCH" of the > > MN context and > > the AR context support capabilities (any other policies and > > user fancies can > > also be brougnt under the "Context" perspective (I assume > > that "context" > > reflects a desired QoS feel at the MT so for all practical purposes > > "Context" and QoS are the same). > > > > For a TAR selection the MT would send in his present > > "Context" list to find > > a match. This I guess would be sent to all CARs (with all the > > signaling > > overheads) > > > > So for all practical purposes by the time I would have done a > > TAR selection > > I would have at least achieved a partial CT if the new AR can > > preserve the > > messages that I use for initial inquiry for TAR selection. > > All other CARs > > where the MT would have sent a message with a wish list ( its present > > context) can release the context list if the MT finally does > > not choose them > > based on a timer. > > > > So I feel a CAR discovery protocol SHOULD identify and standardize "an > > ABSTRACT Context" notion for initial CAR selection and finally should > > provide for classes of Contexts to ease the TAR selection > > process. The exact > > match algorithms can be left to implementations. Such > > classes of contexts > > helps in either a partial or a full CT under TAR selection itself. > > > > Combining CT and CAR has signaling advantages and this can > > prove critical > > for a seamless handover where the "objective is Zero latency handover" > > > > Regards, > > Satish Jamadagni. > > > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'Hemant Chaskar'" ; > > Sent: Tuesday, April 02, 2002 5:46 AM > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > Bingo, Hemant, > > > > > > you hit it right in the bulls eye. CAR discovery is > > > about finding the destination, CT will happen after you found > > > the destination. QoS CT will only help maintaining QoS after > > > (or during) the handoff, but it cannot be used to determine > > > where to handoff to. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > Sent: Monday, April 01, 2002 10:45 AM > > > To: seamoby@ietf.org > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > Hi James: > > > > > > Pardon my ignorance here, but isn't CT about *transferring* > > context rather > > > than negotiating capabilities. In other words, doesn't CT > > protocol take > > > source and dest. of CT as input? Now, source is obvious, we > > still need to > > > work on finding dest. which is target AR of handoff. > > > > > > BR, > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Charlie Perkins" > > > >CC: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > > > >Hi Charlie, > > > > > > > > > > > > > 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. > > > > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > > was one of the > > > >intended applications of context transfer, so I believe it > > is in scope. > > > > > > > > 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 > > > > _______________________________________________ > > Seamoby mailing 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 Apr 2 12:51: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 MAA25897 for ; Tue, 2 Apr 2002 12:51: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 MAA00921; Tue, 2 Apr 2002 12:39: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 MAA00888 for ; Tue, 2 Apr 2002 12:38:57 -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 MAA25234 for ; Tue, 2 Apr 2002 12:38:55 -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 JAA23615; Tue, 2 Apr 2002 09:36:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32HaKF15763; Tue, 2 Apr 2002 09:36:20 -0800 X-mProtect: <200204021736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRSNoej; Tue, 02 Apr 2002 09:36:19 PST Message-ID: <3CA9EC14.8E24B9B2@iprg.nokia.com> Date: Tue, 02 Apr 2002 09:36:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$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, I have some comments, as requested :-) James Kempf wrote: > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what the mobile > node and its user need, No, this is preparation for handover. > 2) A link/routing failure that needs to be fixed up as quickly as > possible. Handover is not a failure. Handover is a success. It happens in response to an actual or likely routing failure. The former is "reactive", the latter "predictive". > 3) Both of the above. I would say that handover is neither, but closer to (2) as I have just indicated. If pressed, I would define handover as "operations which expedite the establishment of a new link by a mobile node". This definition probably still needs some refinement. > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. Maybe, but on the other hand "handover" is like "art". I might not be able to articulate exactly what it is, but I know it when I see it. > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. I would instead strongly suggest that the definition of "handover" should have no dependence on whether the access points offer the same technology{,ies} for establishing links. Of course, certain things not related to IP connectivity might depend on that (e.g., framing, data rates), but the IP mechanisms and the definition should not exhibit any dependence. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 12:51: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 MAA25906 for ; Tue, 2 Apr 2002 12:51:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01852 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 12:51: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 MAA00921; Tue, 2 Apr 2002 12:39: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 MAA00888 for ; Tue, 2 Apr 2002 12:38:57 -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 MAA25234 for ; Tue, 2 Apr 2002 12:38:55 -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 JAA23615; Tue, 2 Apr 2002 09:36:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32HaKF15763; Tue, 2 Apr 2002 09:36:20 -0800 X-mProtect: <200204021736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRSNoej; Tue, 02 Apr 2002 09:36:19 PST Message-ID: <3CA9EC14.8E24B9B2@iprg.nokia.com> Date: Tue, 02 Apr 2002 09:36:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$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, I have some comments, as requested :-) James Kempf wrote: > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what the mobile > node and its user need, No, this is preparation for handover. > 2) A link/routing failure that needs to be fixed up as quickly as > possible. Handover is not a failure. Handover is a success. It happens in response to an actual or likely routing failure. The former is "reactive", the latter "predictive". > 3) Both of the above. I would say that handover is neither, but closer to (2) as I have just indicated. If pressed, I would define handover as "operations which expedite the establishment of a new link by a mobile node". This definition probably still needs some refinement. > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. Maybe, but on the other hand "handover" is like "art". I might not be able to articulate exactly what it is, but I know it when I see it. > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. I would instead strongly suggest that the definition of "handover" should have no dependence on whether the access points offer the same technology{,ies} for establishing links. Of course, certain things not related to IP connectivity might depend on that (e.g., framing, data rates), but the IP mechanisms and the definition should not exhibit any dependence. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 13:50: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 NAA27797 for ; Tue, 2 Apr 2002 13:50:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05266 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 13:50: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 NAA04927; Tue, 2 Apr 2002 13:37: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 NAA04885 for ; Tue, 2 Apr 2002 13:37: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 NAA27344 for ; Tue, 2 Apr 2002 13:37:18 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.11.6/8.9.3) with ESMTP id g32IYeA29344; Tue, 2 Apr 2002 20:34:45 +0200 From: "Henrik Levkowetz" To: Cc: "Charles E. Perkins" , "James Kempf" Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 20:30:17 +0200 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) In-Reply-To: <3CA8B533.EA0F51BA@iprg.nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Charlie, James, A question for clarification: When talking about QoS here, do you mean specifically QoS as in diffserv or RSVP, or do you mean a more general 'quality of service, as determined by first hop available bandwidth, latency, SIR etc.' ? The first might be close to intractable for CARD, while I believe the latter is not. Best, Henrik Charlie Perkins wrote: > > > James Kempf wrote: > > >> For instance, can you identify the processes that you think might > >> be coupled? Can you say something more about the decision criteria? > > > > Obtaining measurements of IP level QoS is one process. Per our previous > > discussion, the estimate was a time constant on the order of 100's of > > msec. The other process is making the handover decision. That is 10's of > > msec estimated. > > I'd like to suggest that we allow handovers based on availability > of resources for less than 100ms. The handover can be accomplished > in a lot shorter than that amount of time, and the CAR discovery is > exactly for the purposes of doing a handover. Why disallow the more > dynamic behavior? > > > There is another issue here. Suppose we consider a dynamic QoS > > measurement on the order of 200 ms and a total (L2 + L3) handover time > > of 40 ms as in previous email. Now, just for the sake of argument, > > suppose we consider that the QoS measurement delivers 20 bytes of data, > > minus IPv6 headers which are removed by header compression. This should > > be enough for the IPv6 address of the access router and a 4 byte QoS > > level. By my calculation, that is approximately 8kbps just to deliver > > QoS measurement data to the mobile node. That's a lot of bandwidth. In > > fact, it is more bandwidth than is used to deliver cellular voice in > > current 3G systems. > > Are you worried about delivering _any_ data to the mobile node? > What was special about QoS data here? If we had 20 bytes of data > to be delivered to the mobile node, that wouldn't take very long > compared to the handover time. Do you suggest that this be delivered > periodically? I would not like that! Otherwise, I don't see how > the 8kbps figure was arrived at... > > >> I would think that CARD would "naturally" be constrained to consider > >> dynamic behavior with time constants not less than, say, 30 ms. > > > > I see the time constant as rather higher, more like seconds. > > Are you saying that a quantity being measured has to be stable for > seconds, before a mobile node can act on the measurement? > > This is not right, I'm pretty sure. Consider the following: > > - CAR agrees to provide video QoS to a mobile node. CAR even > reserves the capacity for 100ms, waiting for the node to arrive. > > - Another customer shows up 120ms later (we have lots of customers :-) > and uses up that video bandwidth > > By your definition, the mobile node should not even consider CAR, > because CAR is unwilling to tie up its resources for more than 100ms > just on the _prospect_ of a handover. By my understanding, it would > be better (for smoother handovers) for the CAR to reserve the bandwidth, > but it would be uneconomical to do so for "seconds". > > > I think one needs to distinguish between InterTHO and IntraTHO. I > > believe the time constants can be considerably different, and the need > > for involvement of the mobile, it's user, or potentially software agents > > acting on behalf of the user, are considerably different. For InterTHO, > > the time constant can be up to seconds, for IntraTHO it is 10's of ms. > > The time constant _could_ be large, but even for InterTHO it does > not have to be -- the two interfaces could (and often would) be on > the same router. I would hope that we don't have to deal with mobile > agents here. > > Besides that, IP-layer stuff should not depend on the specifics > of the technology (i.e., the 'T'). It should work over whatever > reasonable technology is going to support handovers. Maybe not > carrier pigeons. > > >> Regarding (3), note that a local optimization for time and > >> smoothness is "typically" not good for wide-area optimization > >> of network paths. Chained tunnels provide a good illustration > >> about why this is the case. It would be even worse for extended > >> patch-ups to QoS. > > > > I'm not sure I understand your point. I agree about chained tunnels, but > > I don't see how this applies to QoS. > > Nothing deep here... If I get QoS at the router, by appending a > QoS-reserved path between access routers to a QoS-reserved path > ending at the previous access router, I get QoS, but it takes more > network resources than would otherwise be necessary. > > >> Another way of saying this, is that although CARD is separable > >> from smooth handover, it has to be considered in light of what > >> is likely to happen once the discovery takes place. And, I > >> would also say that we should be allowed to discover whatever > >> information by way of (1) that would be use during process (2). > > > > Again, I think the distinction between InterTHO and IntraTHO is > > important. > > I don't think we should design CAR discovery around such a > distinction. Of course, it's important for any reasonable > system design, but that does not have to affect the discovery > protocol by which CARs are identified. > > 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 Tue Apr 2 13:59: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 NAA28067 for ; Tue, 2 Apr 2002 13:59: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 NAA04927; Tue, 2 Apr 2002 13:37: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 NAA04885 for ; Tue, 2 Apr 2002 13:37: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 NAA27344 for ; Tue, 2 Apr 2002 13:37:18 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.11.6/8.9.3) with ESMTP id g32IYeA29344; Tue, 2 Apr 2002 20:34:45 +0200 From: "Henrik Levkowetz" To: Cc: "Charles E. Perkins" , "James Kempf" Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 20:30:17 +0200 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) In-Reply-To: <3CA8B533.EA0F51BA@iprg.nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Charlie, James, A question for clarification: When talking about QoS here, do you mean specifically QoS as in diffserv or RSVP, or do you mean a more general 'quality of service, as determined by first hop available bandwidth, latency, SIR etc.' ? The first might be close to intractable for CARD, while I believe the latter is not. Best, Henrik Charlie Perkins wrote: > > > James Kempf wrote: > > >> For instance, can you identify the processes that you think might > >> be coupled? Can you say something more about the decision criteria? > > > > Obtaining measurements of IP level QoS is one process. Per our previous > > discussion, the estimate was a time constant on the order of 100's of > > msec. The other process is making the handover decision. That is 10's of > > msec estimated. > > I'd like to suggest that we allow handovers based on availability > of resources for less than 100ms. The handover can be accomplished > in a lot shorter than that amount of time, and the CAR discovery is > exactly for the purposes of doing a handover. Why disallow the more > dynamic behavior? > > > There is another issue here. Suppose we consider a dynamic QoS > > measurement on the order of 200 ms and a total (L2 + L3) handover time > > of 40 ms as in previous email. Now, just for the sake of argument, > > suppose we consider that the QoS measurement delivers 20 bytes of data, > > minus IPv6 headers which are removed by header compression. This should > > be enough for the IPv6 address of the access router and a 4 byte QoS > > level. By my calculation, that is approximately 8kbps just to deliver > > QoS measurement data to the mobile node. That's a lot of bandwidth. In > > fact, it is more bandwidth than is used to deliver cellular voice in > > current 3G systems. > > Are you worried about delivering _any_ data to the mobile node? > What was special about QoS data here? If we had 20 bytes of data > to be delivered to the mobile node, that wouldn't take very long > compared to the handover time. Do you suggest that this be delivered > periodically? I would not like that! Otherwise, I don't see how > the 8kbps figure was arrived at... > > >> I would think that CARD would "naturally" be constrained to consider > >> dynamic behavior with time constants not less than, say, 30 ms. > > > > I see the time constant as rather higher, more like seconds. > > Are you saying that a quantity being measured has to be stable for > seconds, before a mobile node can act on the measurement? > > This is not right, I'm pretty sure. Consider the following: > > - CAR agrees to provide video QoS to a mobile node. CAR even > reserves the capacity for 100ms, waiting for the node to arrive. > > - Another customer shows up 120ms later (we have lots of customers :-) > and uses up that video bandwidth > > By your definition, the mobile node should not even consider CAR, > because CAR is unwilling to tie up its resources for more than 100ms > just on the _prospect_ of a handover. By my understanding, it would > be better (for smoother handovers) for the CAR to reserve the bandwidth, > but it would be uneconomical to do so for "seconds". > > > I think one needs to distinguish between InterTHO and IntraTHO. I > > believe the time constants can be considerably different, and the need > > for involvement of the mobile, it's user, or potentially software agents > > acting on behalf of the user, are considerably different. For InterTHO, > > the time constant can be up to seconds, for IntraTHO it is 10's of ms. > > The time constant _could_ be large, but even for InterTHO it does > not have to be -- the two interfaces could (and often would) be on > the same router. I would hope that we don't have to deal with mobile > agents here. > > Besides that, IP-layer stuff should not depend on the specifics > of the technology (i.e., the 'T'). It should work over whatever > reasonable technology is going to support handovers. Maybe not > carrier pigeons. > > >> Regarding (3), note that a local optimization for time and > >> smoothness is "typically" not good for wide-area optimization > >> of network paths. Chained tunnels provide a good illustration > >> about why this is the case. It would be even worse for extended > >> patch-ups to QoS. > > > > I'm not sure I understand your point. I agree about chained tunnels, but > > I don't see how this applies to QoS. > > Nothing deep here... If I get QoS at the router, by appending a > QoS-reserved path between access routers to a QoS-reserved path > ending at the previous access router, I get QoS, but it takes more > network resources than would otherwise be necessary. > > >> Another way of saying this, is that although CARD is separable > >> from smooth handover, it has to be considered in light of what > >> is likely to happen once the discovery takes place. And, I > >> would also say that we should be allowed to discover whatever > >> information by way of (1) that would be use during process (2). > > > > Again, I think the distinction between InterTHO and IntraTHO is > > important. > > I don't think we should design CAR discovery around such a > distinction. Of course, it's important for any reasonable > system design, but that does not have to affect the discovery > protocol by which CARs are identified. > > 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 Tue Apr 2 14:14: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 OAA28528 for ; Tue, 2 Apr 2002 14: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 NAA05442; Tue, 2 Apr 2002 13:52: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 NAA05374 for ; Tue, 2 Apr 2002 13:52:40 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27941 for ; Tue, 2 Apr 2002 13:52:37 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32Iq6Z24609; Tue, 2 Apr 2002 13:52:06 -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 g32Iq5h19291; Tue, 2 Apr 2002 13:52:05 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 13:52:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA498D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: What is Handover? (was: Re: [Seamoby] Examples of CAR discove ry) Date: Tue, 2 Apr 2002 13:51:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA77.77607CA0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA77.77607CA0 Content-Type: text/plain; charset="iso-8859-1" James: My position on CAR/CT/whatever is that it would be nice to have as many tools as possible to promote seamless handovers in any wireless scenarios. Seamless (in my view) means unnoticeable by the end-user, which is actual a very broad definition, allowing lots of negative effects to be tolerated at lower layers (e.g. look at a typical 2G/3G handover). However, as an IETF wg we struggle to deal with the gap between "user perception of QoS", (for which there is no real definitive body of work, except for voice), and L2/L3 performance. It doesn't help that it is outside of the scope of a wg to discuss performance except in very relative, qualitative terms. In opposition to the struggle for seamless handover are the costs: measured in the wireless IP world in terms of complexity, saleability, overhead, over-the-air bandwidth use. Since no one knows how much revenue will be generated by wireless data, it is not possible to set a limit on the "tolerable cost". My points are that in any wireless handover situation, the net objective is to hide the handover from the end-user. This is as true for inter-technology handovers as it is for intra-network handovers. There is a difference in difficulty in achieving these goals, but the difficulty of the solution should not change the objective. To respond your three points: 1) handover is a necessary evil which is intrinsic to the network service. IMHO, it is up to the network to maintain the service level, not the device. I am not a proponent of "dumb devices", but there is an economy of scale in putting certain support in the network rather then the device. As a counter analogy, why do hosts not determine the forwarding route for an IP packet? BUT, you will say, the MN knows best what services it needs. Poppycock, the applications running on the MN know best, and if things get that bad, there are mechanisms being worked on to mitigate QoS changes at the application (e.g. MPEG-4 adaptive coding). These mechanisms cannot be relied upon, in general, for a variety of reasons not worth getting into here, but the provide a last measure for recovery. 2) If handover is treated as a link/routing failure, then I would propose that NSIS is the better answer. The reasons being that a) the service has already been lost; b) there is no real way of determining how far the "link/route failure" extends. With respect to (a): yes, one could switch links so quickly that impact on QoS is marginal at the IP layer, but this would require "micromobility"-like link re-establishment/re-routing, which for the moment is a big assumption (clearly this statement is more valid for inter-technology handover then for, say, soft handover in CDMA). With respect to b), I can only ask the question: is it reasonable to assume that a link/routing failure is always localized, and does not effect the path? If the path is effected, then something more is involved then simple access point selection. Yes, the offering at each access point might be engineered such that the corresponding paths are available for each QoS. However, I find it difficult to understand how this differences can be accurately capture with some advertisement to the MN, in what would have to be a standardized format. If the standardized format was, for example, DS code points, then I don't see what decision is to be made by the MN. Is it not enough for the new network to say either it supports DSCP nnnn or not? 3) see above. It should be evident from the above that I see a lot of functionality being proposed to re-establish QoS during handover. rather then sustaining it. For example 100ms drop in service is anywhere from 5 to 10 voice frames dropped. This is a noticeable audio effect, even if it occurs rarely. For me, this approach brings into question the whole concept of what QoS during handover really means. My vision for CT included inter-network, intra-network and inter-technology handover. It is my expectation that CT will not be performed between unfriendly or unacquainted operators, and that, at worse, there will be SLAs in place for service, QoS, and AAA considerations. Whatever solutions are derived must work together, and independently, that latter allowing network designers to experiment with the technology and find the best solution for each network operator. Just my delusional opinion, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 2, 2002 12:14 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Satish Jamadagni'; Nakhjiri > Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR > discovery) > > > Gary/All, > > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what > the mobile > node and its user need, > > 2) A link/routing failure that needs to be fixed up as quickly as > possible. > > 3) Both of the above. > > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. > > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. > > Comments? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'Satish Jamadagni'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "'Hemant Chaskar'" > ; > Sent: Tuesday, April 02, 2002 7:25 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > Satish: > > > > The reason that CT should remain separate from CAR is that > > CT is useful in many scenarios where CAR is not required. Consider > > the (trivial) case of an access network engineered to provide all > > the necessary QoS capabilities at each AR (note: this does not mean > > that the network is homogenous, just designed/configure with > forethought). > > > > Indeed, if saving time during handover is the issue, then it is > > always faster to do as little signalling as possible, which, for > > some networks, would be CT without CAR. > > > > A similar argument can be put forth for the use of an > NSIS solution > > during handover. Note that I am talking in the general case here, > there will > > always be situations where the network (including the MNs) will have > to > > resort to signalling to maintain or re-establish sessions. > Mobility is > > always about probabilistic success, and it is overkill to > apply worse > > case solutions to all scenarios. > > > > Gary > > > > > -----Original Message----- > > > From: Satish Jamadagni [mailto:satishj@sasken.com] > > > Sent: April 2, 2002 00:39 > > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > Hi All, > > > I feel that CT and CAR should go hand in hand. The reasons > > > are as follows > > > (taking a Bottom - Up approach trying to arrive at a CAR > > > protocol from a > > > final TAR selection perspective assuming that this is what > > > CAR discovery is > > > supposed to assist in) > > > > > > Combining CT and CAR - > > > 1. Saves signaling time (Time is one of the main factors for > deciding > > > seamless ness) > > > 2. Makes sense as during a seamless HO "Context" preservation > > > is what every > > > mobile terminal aims at (we are not considering application > > > adaptation and > > > such kind of stuff) > > > 3. Typical TAR selection would be based on a "MATCH" of the > > > MN context and > > > the AR context support capabilities (any other policies and > > > user fancies can > > > also be brougnt under the "Context" perspective (I assume > > > that "context" > > > reflects a desired QoS feel at the MT so for all > practical purposes > > > "Context" and QoS are the same). > > > > > > For a TAR selection the MT would send in his present > > > "Context" list to find > > > a match. This I guess would be sent to all CARs (with all the > > > signaling > > > overheads) > > > > > > So for all practical purposes by the time I would have done a > > > TAR selection > > > I would have at least achieved a partial CT if the new AR can > > > preserve the > > > messages that I use for initial inquiry for TAR selection. > > > All other CARs > > > where the MT would have sent a message with a wish list ( its > present > > > context) can release the context list if the MT finally does > > > not choose them > > > based on a timer. > > > > > > So I feel a CAR discovery protocol SHOULD identify and standardize > "an > > > ABSTRACT Context" notion for initial CAR selection and finally > should > > > provide for classes of Contexts to ease the TAR selection > > > process. The exact > > > match algorithms can be left to implementations. Such > > > classes of contexts > > > helps in either a partial or a full CT under TAR selection itself. > > > > > > Combining CT and CAR has signaling advantages and this can > > > prove critical > > > for a seamless handover where the "objective is Zero latency > handover" > > > > > > Regards, > > > Satish Jamadagni. > > > > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'Hemant Chaskar'" ; > > > Sent: Tuesday, April 02, 2002 5:46 AM > > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > > > > Bingo, Hemant, > > > > > > > > you hit it right in the bulls eye. CAR discovery is > > > > about finding the destination, CT will happen after you found > > > > the destination. QoS CT will only help maintaining QoS after > > > > (or during) the handoff, but it cannot be used to determine > > > > where to handoff to. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Monday, April 01, 2002 10:45 AM > > > > To: seamoby@ietf.org > > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > > > > Hi James: > > > > > > > > Pardon my ignorance here, but isn't CT about *transferring* > > > context rather > > > > than negotiating capabilities. In other words, doesn't CT > > > protocol take > > > > source and dest. of CT as input? Now, source is obvious, we > > > still need to > > > > work on finding dest. which is target AR of handoff. > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Charlie Perkins" > > > > >CC: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > > > > > >Hi Charlie, > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > > > was one of the > > > > >intended applications of context transfer, so I believe it > > > is in scope. > > > > > > > > > > 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 > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C1DA77.77607CA0 Content-Type: text/html; charset="iso-8859-1" RE: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery)

James:

  My position on CAR/CT/whatever is that it would be nice to have as
many tools as possible to promote seamless handovers in any wireless
scenarios. Seamless (in my view) means unnoticeable by the end-user,
which is actual a very broad definition, allowing lots of negative
effects to be tolerated at lower layers (e.g. look at a typical 2G/3G
handover). However, as an IETF wg we struggle to deal with the gap
between "user perception of QoS", (for which there is no real definitive
body of work, except for voice), and L2/L3 performance. It doesn't help
that it is outside of the scope of a wg to discuss performance except in
very relative, qualitative terms.

  In opposition to the struggle for seamless handover are the costs:
measured in the wireless IP world in terms of complexity, saleability,
overhead, over-the-air bandwidth use. Since no one knows how much revenue
will be generated by wireless data, it is not possible to set a limit on
the "tolerable cost".

  My points are that in any wireless handover situation, the net objective
is to hide the handover from the end-user. This is as true for inter-technology
handovers as it is for intra-network handovers. There is a difference in
difficulty in achieving these goals, but the difficulty of the solution
should not change the objective.

  To respond your three points:

  1) handover is a necessary evil which is intrinsic to the network service.
IMHO, it is up to the network to maintain the service level, not the device.
I am not a proponent of "dumb devices", but there is an economy of scale in
putting certain support in the network rather then the device. As a counter
analogy, why do hosts not determine the forwarding route for an IP
packet?

     BUT, you will say, the MN knows best what services it needs. Poppycock,
the applications running on the MN know best, and if things get that bad, there
are mechanisms being worked on to mitigate QoS changes at the application (e.g.
MPEG-4 adaptive coding). These mechanisms cannot be relied upon, in general,
for a variety of reasons not worth getting into here, but the provide a last
measure for recovery.

  2) If handover is treated as a link/routing failure, then I would propose that
NSIS is the better answer. The reasons being that a) the service has already been
lost; b) there is no real way of determining how far the "link/route failure" extends.
With respect to (a): yes, one could switch links so quickly that impact on QoS is
marginal at the IP layer, but this would require "micromobility"-like link
re-establishment/re-routing, which for the moment is a big assumption (clearly
this statement is more valid for inter-technology handover then for, say, soft
handover in CDMA).

     With respect to b), I can only ask the question: is it reasonable to assume
that a link/routing failure is always localized, and does not effect the path?
If the path is effected, then something more is involved then simple access point
selection. Yes, the offering at each access point might be engineered such
that the corresponding paths are available for each QoS. However, I find it difficult
to understand how this differences can be accurately capture with some advertisement
to the MN, in what would have to be a standardized format. If the standardized format
was, for example, DS code points, then I don't see what decision is to be made by the MN.
Is it not enough for the new network to say either it supports DSCP nnnn or not?

  3) see above.

  It should be evident from the above that I see a lot of functionality being proposed
to re-establish QoS during handover. rather then sustaining it. For example 100ms drop
in service is anywhere from 5 to 10 voice frames dropped. This is a noticeable audio
effect, even if it occurs rarely. For me, this approach brings into question the whole
concept of what QoS during handover really means.

My vision for CT included inter-network, intra-network and inter-technology handover.
It is my expectation that CT will not be performed between unfriendly or unacquainted
operators, and that, at worse, there will be SLAs in place for service, QoS, and AAA
considerations.

  Whatever solutions are derived must work together, and independently, that
latter allowing network designers to experiment with the technology and find the
best solution for each network operator.

Just my delusional opinion,
Gary

 

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 2, 2002 12:14
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Satish Jamadagni'; Nakhjiri
> Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org
> Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR
> discovery)
>
>
> Gary/All,
>
> So I think what it comes down to is this. Is handover:
>
> 1) An opportunity for the mobile node to express its preferences for a
> new access router with characteristics that better match what
> the mobile
> node and its user need,
>
> 2) A link/routing failure that needs to be fixed up as quickly as
> possible.
>
> 3) Both of the above.
>
> Most of the discussion/disagreement/confusion (including my own) I've
> seen on this list seems to revolve around this question.
>
> My opinion:
>
> For intratechnology, Door Number 2.
>
> For intertechnology, Door Number 1.
>
> Comments?
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'Satish Jamadagni'" <satishj@sasken.com>; "Nakhjiri
> Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>; "'Hemant Chaskar'"
> <hchaskar@hotmail.com>; <seamoby@ietf.org>
> Sent: Tuesday, April 02, 2002 7:25 AM
> Subject: RE: [Seamoby] Examples of CAR discovery
>
>
> > Satish:
> >
> >   The reason that CT should remain separate from CAR is that
> > CT is useful in many scenarios where CAR is not required. Consider
> > the (trivial) case of an access network engineered to provide all
> > the necessary QoS capabilities at each AR (note: this does not mean
> > that the network is homogenous, just designed/configure with
> forethought).
> >
> >   Indeed, if saving time during handover is the issue, then it is
> > always faster to do as little signalling as possible, which, for
> > some networks, would be CT without CAR.
> >
> >   A similar argument can be put forth for the use of an
> NSIS solution
> > during handover. Note that I am talking in the general case here,
> there will
> > always be situations where the network (including the MNs) will have
> to
> > resort to signalling to maintain or re-establish sessions.
> Mobility is
> > always about probabilistic success, and it is overkill to
> apply worse
> > case solutions to all scenarios.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Satish Jamadagni [mailto:satishj@sasken.com]
> > > Sent: April 2, 2002 00:39
> > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Examples of CAR discovery
> > >
> > >
> > > Hi All,
> > > I feel that CT and CAR should go hand in hand. The reasons
> > > are as follows
> > > (taking a Bottom - Up approach trying to arrive at a CAR
> > > protocol from a
> > > final TAR selection perspective assuming that this is what
> > > CAR discovery is
> > > supposed to assist in)
> > >
> > > Combining CT and CAR -
> > > 1. Saves signaling time (Time is one of the main factors for
> deciding
> > > seamless ness)
> > > 2. Makes sense as during a seamless HO "Context" preservation
> > > is what every
> > > mobile terminal aims at (we are not considering application
> > > adaptation and
> > > such kind of stuff)
> > > 3. Typical TAR selection would be based on a "MATCH" of the
> > > MN context and
> > > the AR context support capabilities (any other policies and
> > > user fancies can
> > > also be brougnt under the "Context" perspective (I assume
> > > that "context"
> > > reflects a desired QoS feel at the MT so for all
> practical purposes
> > > "Context" and QoS are the same).
> > >
> > > For a TAR selection the MT would send in his present
> > > "Context" list to find
> > > a match. This I guess would be sent to all CARs (with all the
> > > signaling
> > > overheads)
> > >
> > > So for all practical purposes by the time I would have done a
> > > TAR selection
> > > I would have at least achieved a partial CT if the new AR can
> > > preserve the
> > > messages that I use for initial inquiry for TAR selection.
> > > All other CARs
> > > where the MT would have sent a message with a wish list ( its
> present
> > > context) can release the context list if the MT finally does
> > > not choose them
> > > based on a timer.
> > >
> > > So I feel a CAR discovery protocol SHOULD identify and standardize
> "an
> > > ABSTRACT Context" notion for initial CAR selection and finally
> should
> > > provide for classes of Contexts to ease the TAR selection
> > > process. The exact
> > > match algorithms  can be left to implementations. Such
> > > classes of contexts
> > > helps in either a partial or a full CT under TAR selection itself.
> > >
> > > Combining CT and CAR has signaling advantages and this can
> > > prove critical
> > > for a seamless handover where the "objective is Zero latency
> handover"
> > >
> > > Regards,
> > > Satish Jamadagni.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> > > To: "'Hemant Chaskar'" <hchaskar@hotmail.com>; <seamoby@ietf.org>
> > > Sent: Tuesday, April 02, 2002 5:46 AM
> > > Subject: RE: [Seamoby] Examples of CAR discovery
> > >
> > >
> > > > Bingo, Hemant,
> > > >
> > > > you hit it right in the bulls eye. CAR discovery is
> > > > about finding the destination, CT will happen after you found
> > > > the destination. QoS CT will only help maintaining QoS after
> > > > (or during) the handoff, but it cannot be used to determine
> > > > where to handoff to.
> > > >
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> > > > Sent: Monday, April 01, 2002 10:45 AM
> > > > To: seamoby@ietf.org
> > > > Subject: Re: [Seamoby] Examples of CAR discovery
> > > >
> > > >
> > > > Hi James:
> > > >
> > > > Pardon my ignorance here, but isn't CT about *transferring*
> > > context rather
> > > > than negotiating capabilities. In other words, doesn't CT
> > > protocol take
> > > > source and dest. of CT as input? Now, source is obvious, we
> > > still need to
> > > > work on finding dest. which is target AR of handoff.
> > > >
> > > > BR,
> > > > Hemant
> > > >
> > > >
> > > > >From: "James Kempf" <kempf@docomolabs-usa.com>
> > > > >To: "Charlie Perkins" <charliep@iprg.nokia.com>
> > > > >CC: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
> > > > >Subject: Re: [Seamoby] Examples of CAR discovery
> > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800
> > > > >
> > > > >Hi Charlie,
> > > > >
> > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > >This sounds like context transfer, not CAR discovery. QoS
> > > was one of the
> > > > >intended applications of context transfer, so I believe it
> > > is in scope.
> > > > >
> > > > >             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
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C1DA77.77607CA0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 14:14: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 OAA28539 for ; Tue, 2 Apr 2002 14:14:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06768 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 14:14: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 NAA05442; Tue, 2 Apr 2002 13:52: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 NAA05374 for ; Tue, 2 Apr 2002 13:52:40 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27941 for ; Tue, 2 Apr 2002 13:52:37 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32Iq6Z24609; Tue, 2 Apr 2002 13:52:06 -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 g32Iq5h19291; Tue, 2 Apr 2002 13:52:05 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 13:52:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA498D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: RE: What is Handover? (was: Re: [Seamoby] Examples of CAR discove ry) Date: Tue, 2 Apr 2002 13:51:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA77.77607CA0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA77.77607CA0 Content-Type: text/plain; charset="iso-8859-1" James: My position on CAR/CT/whatever is that it would be nice to have as many tools as possible to promote seamless handovers in any wireless scenarios. Seamless (in my view) means unnoticeable by the end-user, which is actual a very broad definition, allowing lots of negative effects to be tolerated at lower layers (e.g. look at a typical 2G/3G handover). However, as an IETF wg we struggle to deal with the gap between "user perception of QoS", (for which there is no real definitive body of work, except for voice), and L2/L3 performance. It doesn't help that it is outside of the scope of a wg to discuss performance except in very relative, qualitative terms. In opposition to the struggle for seamless handover are the costs: measured in the wireless IP world in terms of complexity, saleability, overhead, over-the-air bandwidth use. Since no one knows how much revenue will be generated by wireless data, it is not possible to set a limit on the "tolerable cost". My points are that in any wireless handover situation, the net objective is to hide the handover from the end-user. This is as true for inter-technology handovers as it is for intra-network handovers. There is a difference in difficulty in achieving these goals, but the difficulty of the solution should not change the objective. To respond your three points: 1) handover is a necessary evil which is intrinsic to the network service. IMHO, it is up to the network to maintain the service level, not the device. I am not a proponent of "dumb devices", but there is an economy of scale in putting certain support in the network rather then the device. As a counter analogy, why do hosts not determine the forwarding route for an IP packet? BUT, you will say, the MN knows best what services it needs. Poppycock, the applications running on the MN know best, and if things get that bad, there are mechanisms being worked on to mitigate QoS changes at the application (e.g. MPEG-4 adaptive coding). These mechanisms cannot be relied upon, in general, for a variety of reasons not worth getting into here, but the provide a last measure for recovery. 2) If handover is treated as a link/routing failure, then I would propose that NSIS is the better answer. The reasons being that a) the service has already been lost; b) there is no real way of determining how far the "link/route failure" extends. With respect to (a): yes, one could switch links so quickly that impact on QoS is marginal at the IP layer, but this would require "micromobility"-like link re-establishment/re-routing, which for the moment is a big assumption (clearly this statement is more valid for inter-technology handover then for, say, soft handover in CDMA). With respect to b), I can only ask the question: is it reasonable to assume that a link/routing failure is always localized, and does not effect the path? If the path is effected, then something more is involved then simple access point selection. Yes, the offering at each access point might be engineered such that the corresponding paths are available for each QoS. However, I find it difficult to understand how this differences can be accurately capture with some advertisement to the MN, in what would have to be a standardized format. If the standardized format was, for example, DS code points, then I don't see what decision is to be made by the MN. Is it not enough for the new network to say either it supports DSCP nnnn or not? 3) see above. It should be evident from the above that I see a lot of functionality being proposed to re-establish QoS during handover. rather then sustaining it. For example 100ms drop in service is anywhere from 5 to 10 voice frames dropped. This is a noticeable audio effect, even if it occurs rarely. For me, this approach brings into question the whole concept of what QoS during handover really means. My vision for CT included inter-network, intra-network and inter-technology handover. It is my expectation that CT will not be performed between unfriendly or unacquainted operators, and that, at worse, there will be SLAs in place for service, QoS, and AAA considerations. Whatever solutions are derived must work together, and independently, that latter allowing network designers to experiment with the technology and find the best solution for each network operator. Just my delusional opinion, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 2, 2002 12:14 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Satish Jamadagni'; Nakhjiri > Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR > discovery) > > > Gary/All, > > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what > the mobile > node and its user need, > > 2) A link/routing failure that needs to be fixed up as quickly as > possible. > > 3) Both of the above. > > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. > > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. > > Comments? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'Satish Jamadagni'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "'Hemant Chaskar'" > ; > Sent: Tuesday, April 02, 2002 7:25 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > > Satish: > > > > The reason that CT should remain separate from CAR is that > > CT is useful in many scenarios where CAR is not required. Consider > > the (trivial) case of an access network engineered to provide all > > the necessary QoS capabilities at each AR (note: this does not mean > > that the network is homogenous, just designed/configure with > forethought). > > > > Indeed, if saving time during handover is the issue, then it is > > always faster to do as little signalling as possible, which, for > > some networks, would be CT without CAR. > > > > A similar argument can be put forth for the use of an > NSIS solution > > during handover. Note that I am talking in the general case here, > there will > > always be situations where the network (including the MNs) will have > to > > resort to signalling to maintain or re-establish sessions. > Mobility is > > always about probabilistic success, and it is overkill to > apply worse > > case solutions to all scenarios. > > > > Gary > > > > > -----Original Message----- > > > From: Satish Jamadagni [mailto:satishj@sasken.com] > > > Sent: April 2, 2002 00:39 > > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > Hi All, > > > I feel that CT and CAR should go hand in hand. The reasons > > > are as follows > > > (taking a Bottom - Up approach trying to arrive at a CAR > > > protocol from a > > > final TAR selection perspective assuming that this is what > > > CAR discovery is > > > supposed to assist in) > > > > > > Combining CT and CAR - > > > 1. Saves signaling time (Time is one of the main factors for > deciding > > > seamless ness) > > > 2. Makes sense as during a seamless HO "Context" preservation > > > is what every > > > mobile terminal aims at (we are not considering application > > > adaptation and > > > such kind of stuff) > > > 3. Typical TAR selection would be based on a "MATCH" of the > > > MN context and > > > the AR context support capabilities (any other policies and > > > user fancies can > > > also be brougnt under the "Context" perspective (I assume > > > that "context" > > > reflects a desired QoS feel at the MT so for all > practical purposes > > > "Context" and QoS are the same). > > > > > > For a TAR selection the MT would send in his present > > > "Context" list to find > > > a match. This I guess would be sent to all CARs (with all the > > > signaling > > > overheads) > > > > > > So for all practical purposes by the time I would have done a > > > TAR selection > > > I would have at least achieved a partial CT if the new AR can > > > preserve the > > > messages that I use for initial inquiry for TAR selection. > > > All other CARs > > > where the MT would have sent a message with a wish list ( its > present > > > context) can release the context list if the MT finally does > > > not choose them > > > based on a timer. > > > > > > So I feel a CAR discovery protocol SHOULD identify and standardize > "an > > > ABSTRACT Context" notion for initial CAR selection and finally > should > > > provide for classes of Contexts to ease the TAR selection > > > process. The exact > > > match algorithms can be left to implementations. Such > > > classes of contexts > > > helps in either a partial or a full CT under TAR selection itself. > > > > > > Combining CT and CAR has signaling advantages and this can > > > prove critical > > > for a seamless handover where the "objective is Zero latency > handover" > > > > > > Regards, > > > Satish Jamadagni. > > > > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'Hemant Chaskar'" ; > > > Sent: Tuesday, April 02, 2002 5:46 AM > > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > > > > Bingo, Hemant, > > > > > > > > you hit it right in the bulls eye. CAR discovery is > > > > about finding the destination, CT will happen after you found > > > > the destination. QoS CT will only help maintaining QoS after > > > > (or during) the handoff, but it cannot be used to determine > > > > where to handoff to. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Monday, April 01, 2002 10:45 AM > > > > To: seamoby@ietf.org > > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > > > > Hi James: > > > > > > > > Pardon my ignorance here, but isn't CT about *transferring* > > > context rather > > > > than negotiating capabilities. In other words, doesn't CT > > > protocol take > > > > source and dest. of CT as input? Now, source is obvious, we > > > still need to > > > > work on finding dest. which is target AR of handoff. > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Charlie Perkins" > > > > >CC: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > > > > > >Hi Charlie, > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > > > was one of the > > > > >intended applications of context transfer, so I believe it > > > is in scope. > > > > > > > > > > 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 > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C1DA77.77607CA0 Content-Type: text/html; charset="iso-8859-1" RE: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery)

James:

  My position on CAR/CT/whatever is that it would be nice to have as
many tools as possible to promote seamless handovers in any wireless
scenarios. Seamless (in my view) means unnoticeable by the end-user,
which is actual a very broad definition, allowing lots of negative
effects to be tolerated at lower layers (e.g. look at a typical 2G/3G
handover). However, as an IETF wg we struggle to deal with the gap
between "user perception of QoS", (for which there is no real definitive
body of work, except for voice), and L2/L3 performance. It doesn't help
that it is outside of the scope of a wg to discuss performance except in
very relative, qualitative terms.

  In opposition to the struggle for seamless handover are the costs:
measured in the wireless IP world in terms of complexity, saleability,
overhead, over-the-air bandwidth use. Since no one knows how much revenue
will be generated by wireless data, it is not possible to set a limit on
the "tolerable cost".

  My points are that in any wireless handover situation, the net objective
is to hide the handover from the end-user. This is as true for inter-technology
handovers as it is for intra-network handovers. There is a difference in
difficulty in achieving these goals, but the difficulty of the solution
should not change the objective.

  To respond your three points:

  1) handover is a necessary evil which is intrinsic to the network service.
IMHO, it is up to the network to maintain the service level, not the device.
I am not a proponent of "dumb devices", but there is an economy of scale in
putting certain support in the network rather then the device. As a counter
analogy, why do hosts not determine the forwarding route for an IP
packet?

     BUT, you will say, the MN knows best what services it needs. Poppycock,
the applications running on the MN know best, and if things get that bad, there
are mechanisms being worked on to mitigate QoS changes at the application (e.g.
MPEG-4 adaptive coding). These mechanisms cannot be relied upon, in general,
for a variety of reasons not worth getting into here, but the provide a last
measure for recovery.

  2) If handover is treated as a link/routing failure, then I would propose that
NSIS is the better answer. The reasons being that a) the service has already been
lost; b) there is no real way of determining how far the "link/route failure" extends.
With respect to (a): yes, one could switch links so quickly that impact on QoS is
marginal at the IP layer, but this would require "micromobility"-like link
re-establishment/re-routing, which for the moment is a big assumption (clearly
this statement is more valid for inter-technology handover then for, say, soft
handover in CDMA).

     With respect to b), I can only ask the question: is it reasonable to assume
that a link/routing failure is always localized, and does not effect the path?
If the path is effected, then something more is involved then simple access point
selection. Yes, the offering at each access point might be engineered such
that the corresponding paths are available for each QoS. However, I find it difficult
to understand how this differences can be accurately capture with some advertisement
to the MN, in what would have to be a standardized format. If the standardized format
was, for example, DS code points, then I don't see what decision is to be made by the MN.
Is it not enough for the new network to say either it supports DSCP nnnn or not?

  3) see above.

  It should be evident from the above that I see a lot of functionality being proposed
to re-establish QoS during handover. rather then sustaining it. For example 100ms drop
in service is anywhere from 5 to 10 voice frames dropped. This is a noticeable audio
effect, even if it occurs rarely. For me, this approach brings into question the whole
concept of what QoS during handover really means.

My vision for CT included inter-network, intra-network and inter-technology handover.
It is my expectation that CT will not be performed between unfriendly or unacquainted
operators, and that, at worse, there will be SLAs in place for service, QoS, and AAA
considerations.

  Whatever solutions are derived must work together, and independently, that
latter allowing network designers to experiment with the technology and find the
best solution for each network operator.

Just my delusional opinion,
Gary

 

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 2, 2002 12:14
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Satish Jamadagni'; Nakhjiri
> Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org
> Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR
> discovery)
>
>
> Gary/All,
>
> So I think what it comes down to is this. Is handover:
>
> 1) An opportunity for the mobile node to express its preferences for a
> new access router with characteristics that better match what
> the mobile
> node and its user need,
>
> 2) A link/routing failure that needs to be fixed up as quickly as
> possible.
>
> 3) Both of the above.
>
> Most of the discussion/disagreement/confusion (including my own) I've
> seen on this list seems to revolve around this question.
>
> My opinion:
>
> For intratechnology, Door Number 2.
>
> For intertechnology, Door Number 1.
>
> Comments?
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'Satish Jamadagni'" <satishj@sasken.com>; "Nakhjiri
> Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>; "'Hemant Chaskar'"
> <hchaskar@hotmail.com>; <seamoby@ietf.org>
> Sent: Tuesday, April 02, 2002 7:25 AM
> Subject: RE: [Seamoby] Examples of CAR discovery
>
>
> > Satish:
> >
> >   The reason that CT should remain separate from CAR is that
> > CT is useful in many scenarios where CAR is not required. Consider
> > the (trivial) case of an access network engineered to provide all
> > the necessary QoS capabilities at each AR (note: this does not mean
> > that the network is homogenous, just designed/configure with
> forethought).
> >
> >   Indeed, if saving time during handover is the issue, then it is
> > always faster to do as little signalling as possible, which, for
> > some networks, would be CT without CAR.
> >
> >   A similar argument can be put forth for the use of an
> NSIS solution
> > during handover. Note that I am talking in the general case here,
> there will
> > always be situations where the network (including the MNs) will have
> to
> > resort to signalling to maintain or re-establish sessions.
> Mobility is
> > always about probabilistic success, and it is overkill to
> apply worse
> > case solutions to all scenarios.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Satish Jamadagni [mailto:satishj@sasken.com]
> > > Sent: April 2, 2002 00:39
> > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org
> > > Subject: Re: [Seamoby] Examples of CAR discovery
> > >
> > >
> > > Hi All,
> > > I feel that CT and CAR should go hand in hand. The reasons
> > > are as follows
> > > (taking a Bottom - Up approach trying to arrive at a CAR
> > > protocol from a
> > > final TAR selection perspective assuming that this is what
> > > CAR discovery is
> > > supposed to assist in)
> > >
> > > Combining CT and CAR -
> > > 1. Saves signaling time (Time is one of the main factors for
> deciding
> > > seamless ness)
> > > 2. Makes sense as during a seamless HO "Context" preservation
> > > is what every
> > > mobile terminal aims at (we are not considering application
> > > adaptation and
> > > such kind of stuff)
> > > 3. Typical TAR selection would be based on a "MATCH" of the
> > > MN context and
> > > the AR context support capabilities (any other policies and
> > > user fancies can
> > > also be brougnt under the "Context" perspective (I assume
> > > that "context"
> > > reflects a desired QoS feel at the MT so for all
> practical purposes
> > > "Context" and QoS are the same).
> > >
> > > For a TAR selection the MT would send in his present
> > > "Context" list to find
> > > a match. This I guess would be sent to all CARs (with all the
> > > signaling
> > > overheads)
> > >
> > > So for all practical purposes by the time I would have done a
> > > TAR selection
> > > I would have at least achieved a partial CT if the new AR can
> > > preserve the
> > > messages that I use for initial inquiry for TAR selection.
> > > All other CARs
> > > where the MT would have sent a message with a wish list ( its
> present
> > > context) can release the context list if the MT finally does
> > > not choose them
> > > based on a timer.
> > >
> > > So I feel a CAR discovery protocol SHOULD identify and standardize
> "an
> > > ABSTRACT Context" notion for initial CAR selection and finally
> should
> > > provide for classes of Contexts to ease the TAR selection
> > > process. The exact
> > > match algorithms  can be left to implementations. Such
> > > classes of contexts
> > > helps in either a partial or a full CT under TAR selection itself.
> > >
> > > Combining CT and CAR has signaling advantages and this can
> > > prove critical
> > > for a seamless handover where the "objective is Zero latency
> handover"
> > >
> > > Regards,
> > > Satish Jamadagni.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> > > To: "'Hemant Chaskar'" <hchaskar@hotmail.com>; <seamoby@ietf.org>
> > > Sent: Tuesday, April 02, 2002 5:46 AM
> > > Subject: RE: [Seamoby] Examples of CAR discovery
> > >
> > >
> > > > Bingo, Hemant,
> > > >
> > > > you hit it right in the bulls eye. CAR discovery is
> > > > about finding the destination, CT will happen after you found
> > > > the destination. QoS CT will only help maintaining QoS after
> > > > (or during) the handoff, but it cannot be used to determine
> > > > where to handoff to.
> > > >
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> > > > Sent: Monday, April 01, 2002 10:45 AM
> > > > To: seamoby@ietf.org
> > > > Subject: Re: [Seamoby] Examples of CAR discovery
> > > >
> > > >
> > > > Hi James:
> > > >
> > > > Pardon my ignorance here, but isn't CT about *transferring*
> > > context rather
> > > > than negotiating capabilities. In other words, doesn't CT
> > > protocol take
> > > > source and dest. of CT as input? Now, source is obvious, we
> > > still need to
> > > > work on finding dest. which is target AR of handoff.
> > > >
> > > > BR,
> > > > Hemant
> > > >
> > > >
> > > > >From: "James Kempf" <kempf@docomolabs-usa.com>
> > > > >To: "Charlie Perkins" <charliep@iprg.nokia.com>
> > > > >CC: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
> > > > >Subject: Re: [Seamoby] Examples of CAR discovery
> > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800
> > > > >
> > > > >Hi Charlie,
> > > > >
> > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > >This sounds like context transfer, not CAR discovery. QoS
> > > was one of the
> > > > >intended applications of context transfer, so I believe it
> > > is in scope.
> > > > >
> > > > >             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
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C1DA77.77607CA0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 14:14: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 OAA28574 for ; Tue, 2 Apr 2002 14:14: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 NAA05750; Tue, 2 Apr 2002 13:58: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 NAA05721 for ; Tue, 2 Apr 2002 13:58:52 -0500 (EST) Received: from hotmail.com (f11.law9.hotmail.com [64.4.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28062 for ; Tue, 2 Apr 2002 13:58:51 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Apr 2002 10:57:51 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 02 Apr 2002 18:57:50 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, satishj@sasken.com, Madjid.Nakhjiri@motorola.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Tue, 02 Apr 2002 13:57:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Apr 2002 18:57:51.0155 (UTC) FILETIME=[49C34830:01C1DA78] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, My comments inline: >1) An opportunity for the mobile node to express its preferences for a >new access router with characteristics that better match what the mobile >node and its user need, [Govind] This is an optimization to handover not handover itself, that helps CAR discovery and TAR selection algorithms to best choose the TAR. > >2) A link/routing failure that needs to be fixed up as quickly as >possible. > [Govind] Clearly handovers for no link failure case is possible. FMIPv6 is being designed for a case when there is no link failure. Also, handovers could happen for load balancing/cost reasons too. >3) Both of the above. > >Most of the discussion/disagreement/confusion (including my own) I've >seen on this list seems to revolve around this question. > >My opinion: > >For intratechnology, Door Number 2. > [Govind] I think same technology handovers can happen for reasons other than link failure, as pointed earlier for load/cost reasons. 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 Tue Apr 2 14:14: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 OAA28590 for ; Tue, 2 Apr 2002 14:14:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06797 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 14:14: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 NAA05750; Tue, 2 Apr 2002 13:58: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 NAA05721 for ; Tue, 2 Apr 2002 13:58:52 -0500 (EST) Received: from hotmail.com (f11.law9.hotmail.com [64.4.9.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28062 for ; Tue, 2 Apr 2002 13:58:51 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Apr 2002 10:57:51 -0800 Received: from 63.78.179.5 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 02 Apr 2002 18:57:50 GMT X-Originating-IP: [63.78.179.5] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, gkenward@nortelnetworks.com, satishj@sasken.com, Madjid.Nakhjiri@motorola.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Tue, 02 Apr 2002 13:57:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Apr 2002 18:57:51.0155 (UTC) FILETIME=[49C34830:01C1DA78] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, My comments inline: >1) An opportunity for the mobile node to express its preferences for a >new access router with characteristics that better match what the mobile >node and its user need, [Govind] This is an optimization to handover not handover itself, that helps CAR discovery and TAR selection algorithms to best choose the TAR. > >2) A link/routing failure that needs to be fixed up as quickly as >possible. > [Govind] Clearly handovers for no link failure case is possible. FMIPv6 is being designed for a case when there is no link failure. Also, handovers could happen for load balancing/cost reasons too. >3) Both of the above. > >Most of the discussion/disagreement/confusion (including my own) I've >seen on this list seems to revolve around this question. > >My opinion: > >For intratechnology, Door Number 2. > [Govind] I think same technology handovers can happen for reasons other than link failure, as pointed earlier for load/cost reasons. 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 Tue Apr 2 14:18: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 OAA28709 for ; Tue, 2 Apr 2002 14:18: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 NAA05529; Tue, 2 Apr 2002 13:54: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 NAA05502 for ; Tue, 2 Apr 2002 13:54: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 NAA27988 for ; Tue, 2 Apr 2002 13:54: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 g32IrrI11675; Tue, 2 Apr 2002 10:53:53 -0800 (PST) Message-ID: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Henrik Levkowetz" , Cc: "Charles E. Perkins" References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 10:52: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 > A question for clarification: When talking about QoS here, do you > mean specifically QoS as in diffserv or RSVP, or do you mean a more > general 'quality of service, as determined by first hop available > bandwidth, latency, SIR etc.' ? > I've been under the assumption that it's the first, i.e. IP QoS. jak > The first might be close to intractable for CARD, while I believe > the latter is not. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 2 14:18: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 OAA28722 for ; Tue, 2 Apr 2002 14:18:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06986 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 14:18: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 NAA05529; Tue, 2 Apr 2002 13:54: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 NAA05502 for ; Tue, 2 Apr 2002 13:54: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 NAA27988 for ; Tue, 2 Apr 2002 13:54: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 g32IrrI11675; Tue, 2 Apr 2002 10:53:53 -0800 (PST) Message-ID: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Henrik Levkowetz" , Cc: "Charles E. Perkins" References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 10:52: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 > A question for clarification: When talking about QoS here, do you > mean specifically QoS as in diffserv or RSVP, or do you mean a more > general 'quality of service, as determined by first hop available > bandwidth, latency, SIR etc.' ? > I've been under the assumption that it's the first, i.e. IP QoS. jak > The first might be close to intractable for CARD, while I believe > the latter is not. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 14:51: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 OAA29958 for ; Tue, 2 Apr 2002 14:51: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 OAA08482; Tue, 2 Apr 2002 14:42: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 OAA08451 for ; Tue, 2 Apr 2002 14:42:27 -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 OAA29695 for ; Tue, 2 Apr 2002 14:42:20 -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 g32JfpV01105; Tue, 2 Apr 2002 13:41:51 -0600 (CST) Message-ID: <3CAA097D.4000300@alcatel.com> Date: Tue, 02 Apr 2002 13:41:49 -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 CC: seamoby@ietf.org, stefano.faccin@nokia.com References: <3CA39DBD.6040300@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: [mobile-ip] ip-paging work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, As promised, here is more info: Stefano and I would like to sollicit your participation in the new work on ip-paging. The proposed charter which will be base to the discussions on the mailing can be obtained from: http://pages.sbcglobal.net/bsarikaya/ip-paging/charter.htm If you have not done so you can get to the list by sending an email to behcet.sarikaya@alcatel.com Regards, -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 14:51: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 OAA29982 for ; Tue, 2 Apr 2002 14:51:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA08853 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 14:51: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 OAA08482; Tue, 2 Apr 2002 14:42: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 OAA08451 for ; Tue, 2 Apr 2002 14:42:27 -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 OAA29695 for ; Tue, 2 Apr 2002 14:42:20 -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 g32JfpV01105; Tue, 2 Apr 2002 13:41:51 -0600 (CST) Message-ID: <3CAA097D.4000300@alcatel.com> Date: Tue, 02 Apr 2002 13:41:49 -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 CC: seamoby@ietf.org, stefano.faccin@nokia.com References: <3CA39DBD.6040300@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: [mobile-ip] ip-paging work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, As promised, here is more info: Stefano and I would like to sollicit your participation in the new work on ip-paging. The proposed charter which will be base to the discussions on the mailing can be obtained from: http://pages.sbcglobal.net/bsarikaya/ip-paging/charter.htm If you have not done so you can get to the list by sending an email to behcet.sarikaya@alcatel.com Regards, -- Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 15:02: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 PAA00391 for ; Tue, 2 Apr 2002 15:02: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 OAA08957; Tue, 2 Apr 2002 14:53: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 OAA08928 for ; Tue, 2 Apr 2002 14:52:59 -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 OAA00039 for ; Tue, 2 Apr 2002 14:52:56 -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 LAA03249; Tue, 2 Apr 2002 11:52:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32JqMp20120; Tue, 2 Apr 2002 11:52:22 -0800 X-mProtect: <200204021952> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdh2bTrh; Tue, 02 Apr 2002 11:52:21 PST Message-ID: <3CAA0BF4.60149725@iprg.nokia.com> Date: Tue, 02 Apr 2002 11:52:21 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$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 Jim, we had a lot of discussion on this. For instance, take a look at http://www.ietf.org/proceedings/01aug/51-132.htm#TopOfPage Anyway, here is my (re)take on this. IP handover: a process that enables a MN to acquire network layer _connectivity_ when it changes access routers, allowing it to send and receive IP packets. IP handover is a routing issue. CT: a process that facilitates continued offering of IP features, typically during terminal mobility. CT addresses performance of transport protocols assuming IP connectivity is available. It is a transport issue. I thought we had a good understanding on this, especially after London IETF meeting. Let me extend the above and say.. CARD: a process that facilitates resolving the prospective link (identifier) with its prefix and assocaited capabilities. This comes out as off-link ARP with extensions. TARS: a process that assists in selecting _a_ router from among multiple candidates. For what it is worth.. I do feel strongly however that these be treated as separate protocols. Regards, -Rajeev James Kempf wrote: > Gary/All, > > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what the mobile > node and its user need, > > 2) A link/routing failure that needs to be fixed up as quickly as > possible. > > 3) Both of the above. > > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. > > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. > > Comments? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'Satish Jamadagni'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "'Hemant Chaskar'" > ; > Sent: Tuesday, April 02, 2002 7:25 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > Satish: > > > > The reason that CT should remain separate from CAR is that > > CT is useful in many scenarios where CAR is not required. Consider > > the (trivial) case of an access network engineered to provide all > > the necessary QoS capabilities at each AR (note: this does not mean > > that the network is homogenous, just designed/configure with > forethought). > > > > Indeed, if saving time during handover is the issue, then it is > > always faster to do as little signalling as possible, which, for > > some networks, would be CT without CAR. > > > > A similar argument can be put forth for the use of an NSIS solution > > during handover. Note that I am talking in the general case here, > there will > > always be situations where the network (including the MNs) will have > to > > resort to signalling to maintain or re-establish sessions. Mobility is > > always about probabilistic success, and it is overkill to apply worse > > case solutions to all scenarios. > > > > Gary > > > > > -----Original Message----- > > > From: Satish Jamadagni [mailto:satishj@sasken.com] > > > Sent: April 2, 2002 00:39 > > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > Hi All, > > > I feel that CT and CAR should go hand in hand. The reasons > > > are as follows > > > (taking a Bottom - Up approach trying to arrive at a CAR > > > protocol from a > > > final TAR selection perspective assuming that this is what > > > CAR discovery is > > > supposed to assist in) > > > > > > Combining CT and CAR - > > > 1. Saves signaling time (Time is one of the main factors for > deciding > > > seamless ness) > > > 2. Makes sense as during a seamless HO "Context" preservation > > > is what every > > > mobile terminal aims at (we are not considering application > > > adaptation and > > > such kind of stuff) > > > 3. Typical TAR selection would be based on a "MATCH" of the > > > MN context and > > > the AR context support capabilities (any other policies and > > > user fancies can > > > also be brougnt under the "Context" perspective (I assume > > > that "context" > > > reflects a desired QoS feel at the MT so for all practical purposes > > > "Context" and QoS are the same). > > > > > > For a TAR selection the MT would send in his present > > > "Context" list to find > > > a match. This I guess would be sent to all CARs (with all the > > > signaling > > > overheads) > > > > > > So for all practical purposes by the time I would have done a > > > TAR selection > > > I would have at least achieved a partial CT if the new AR can > > > preserve the > > > messages that I use for initial inquiry for TAR selection. > > > All other CARs > > > where the MT would have sent a message with a wish list ( its > present > > > context) can release the context list if the MT finally does > > > not choose them > > > based on a timer. > > > > > > So I feel a CAR discovery protocol SHOULD identify and standardize > "an > > > ABSTRACT Context" notion for initial CAR selection and finally > should > > > provide for classes of Contexts to ease the TAR selection > > > process. The exact > > > match algorithms can be left to implementations. Such > > > classes of contexts > > > helps in either a partial or a full CT under TAR selection itself. > > > > > > Combining CT and CAR has signaling advantages and this can > > > prove critical > > > for a seamless handover where the "objective is Zero latency > handover" > > > > > > Regards, > > > Satish Jamadagni. > > > > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'Hemant Chaskar'" ; > > > Sent: Tuesday, April 02, 2002 5:46 AM > > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > > > > Bingo, Hemant, > > > > > > > > you hit it right in the bulls eye. CAR discovery is > > > > about finding the destination, CT will happen after you found > > > > the destination. QoS CT will only help maintaining QoS after > > > > (or during) the handoff, but it cannot be used to determine > > > > where to handoff to. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Monday, April 01, 2002 10:45 AM > > > > To: seamoby@ietf.org > > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > > > > Hi James: > > > > > > > > Pardon my ignorance here, but isn't CT about *transferring* > > > context rather > > > > than negotiating capabilities. In other words, doesn't CT > > > protocol take > > > > source and dest. of CT as input? Now, source is obvious, we > > > still need to > > > > work on finding dest. which is target AR of handoff. > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Charlie Perkins" > > > > >CC: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > > > > > >Hi Charlie, > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > > > was one of the > > > > >intended applications of context transfer, so I believe it > > > is in scope. > > > > > > > > > > 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 > > > > > > _______________________________________________ > > > Seamoby mailing 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 Tue Apr 2 15:02: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 PAA00401 for ; Tue, 2 Apr 2002 15:02:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09914 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 15:02: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 OAA08957; Tue, 2 Apr 2002 14:53: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 OAA08928 for ; Tue, 2 Apr 2002 14:52:59 -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 OAA00039 for ; Tue, 2 Apr 2002 14:52:56 -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 LAA03249; Tue, 2 Apr 2002 11:52:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32JqMp20120; Tue, 2 Apr 2002 11:52:22 -0800 X-mProtect: <200204021952> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdh2bTrh; Tue, 02 Apr 2002 11:52:21 PST Message-ID: <3CAA0BF4.60149725@iprg.nokia.com> Date: Tue, 02 Apr 2002 11:52:21 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$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 Jim, we had a lot of discussion on this. For instance, take a look at http://www.ietf.org/proceedings/01aug/51-132.htm#TopOfPage Anyway, here is my (re)take on this. IP handover: a process that enables a MN to acquire network layer _connectivity_ when it changes access routers, allowing it to send and receive IP packets. IP handover is a routing issue. CT: a process that facilitates continued offering of IP features, typically during terminal mobility. CT addresses performance of transport protocols assuming IP connectivity is available. It is a transport issue. I thought we had a good understanding on this, especially after London IETF meeting. Let me extend the above and say.. CARD: a process that facilitates resolving the prospective link (identifier) with its prefix and assocaited capabilities. This comes out as off-link ARP with extensions. TARS: a process that assists in selecting _a_ router from among multiple candidates. For what it is worth.. I do feel strongly however that these be treated as separate protocols. Regards, -Rajeev James Kempf wrote: > Gary/All, > > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what the mobile > node and its user need, > > 2) A link/routing failure that needs to be fixed up as quickly as > possible. > > 3) Both of the above. > > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. > > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. > > Comments? > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'Satish Jamadagni'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "'Hemant Chaskar'" > ; > Sent: Tuesday, April 02, 2002 7:25 AM > Subject: RE: [Seamoby] Examples of CAR discovery > > > Satish: > > > > The reason that CT should remain separate from CAR is that > > CT is useful in many scenarios where CAR is not required. Consider > > the (trivial) case of an access network engineered to provide all > > the necessary QoS capabilities at each AR (note: this does not mean > > that the network is homogenous, just designed/configure with > forethought). > > > > Indeed, if saving time during handover is the issue, then it is > > always faster to do as little signalling as possible, which, for > > some networks, would be CT without CAR. > > > > A similar argument can be put forth for the use of an NSIS solution > > during handover. Note that I am talking in the general case here, > there will > > always be situations where the network (including the MNs) will have > to > > resort to signalling to maintain or re-establish sessions. Mobility is > > always about probabilistic success, and it is overkill to apply worse > > case solutions to all scenarios. > > > > Gary > > > > > -----Original Message----- > > > From: Satish Jamadagni [mailto:satishj@sasken.com] > > > Sent: April 2, 2002 00:39 > > > To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; seamoby@ietf.org > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > Hi All, > > > I feel that CT and CAR should go hand in hand. The reasons > > > are as follows > > > (taking a Bottom - Up approach trying to arrive at a CAR > > > protocol from a > > > final TAR selection perspective assuming that this is what > > > CAR discovery is > > > supposed to assist in) > > > > > > Combining CT and CAR - > > > 1. Saves signaling time (Time is one of the main factors for > deciding > > > seamless ness) > > > 2. Makes sense as during a seamless HO "Context" preservation > > > is what every > > > mobile terminal aims at (we are not considering application > > > adaptation and > > > such kind of stuff) > > > 3. Typical TAR selection would be based on a "MATCH" of the > > > MN context and > > > the AR context support capabilities (any other policies and > > > user fancies can > > > also be brougnt under the "Context" perspective (I assume > > > that "context" > > > reflects a desired QoS feel at the MT so for all practical purposes > > > "Context" and QoS are the same). > > > > > > For a TAR selection the MT would send in his present > > > "Context" list to find > > > a match. This I guess would be sent to all CARs (with all the > > > signaling > > > overheads) > > > > > > So for all practical purposes by the time I would have done a > > > TAR selection > > > I would have at least achieved a partial CT if the new AR can > > > preserve the > > > messages that I use for initial inquiry for TAR selection. > > > All other CARs > > > where the MT would have sent a message with a wish list ( its > present > > > context) can release the context list if the MT finally does > > > not choose them > > > based on a timer. > > > > > > So I feel a CAR discovery protocol SHOULD identify and standardize > "an > > > ABSTRACT Context" notion for initial CAR selection and finally > should > > > provide for classes of Contexts to ease the TAR selection > > > process. The exact > > > match algorithms can be left to implementations. Such > > > classes of contexts > > > helps in either a partial or a full CT under TAR selection itself. > > > > > > Combining CT and CAR has signaling advantages and this can > > > prove critical > > > for a seamless handover where the "objective is Zero latency > handover" > > > > > > Regards, > > > Satish Jamadagni. > > > > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'Hemant Chaskar'" ; > > > Sent: Tuesday, April 02, 2002 5:46 AM > > > Subject: RE: [Seamoby] Examples of CAR discovery > > > > > > > > > > Bingo, Hemant, > > > > > > > > you hit it right in the bulls eye. CAR discovery is > > > > about finding the destination, CT will happen after you found > > > > the destination. QoS CT will only help maintaining QoS after > > > > (or during) the handoff, but it cannot be used to determine > > > > where to handoff to. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > > > > Sent: Monday, April 01, 2002 10:45 AM > > > > To: seamoby@ietf.org > > > > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > > > > > Hi James: > > > > > > > > Pardon my ignorance here, but isn't CT about *transferring* > > > context rather > > > > than negotiating capabilities. In other words, doesn't CT > > > protocol take > > > > source and dest. of CT as input? Now, source is obvious, we > > > still need to > > > > work on finding dest. which is target AR of handoff. > > > > > > > > BR, > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Charlie Perkins" > > > > >CC: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Examples of CAR discovery > > > > >Date: Mon, 1 Apr 2002 08:16:02 -0800 > > > > > > > > > >Hi Charlie, > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > >This sounds like context transfer, not CAR discovery. QoS > > > was one of the > > > > >intended applications of context transfer, so I believe it > > > is in scope. > > > > > > > > > > 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 > > > > > > _______________________________________________ > > > Seamoby mailing 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 Tue Apr 2 15:02: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 PAA00419 for ; Tue, 2 Apr 2002 15: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 OAA08818; Tue, 2 Apr 2002 14:50: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 OAA08791 for ; Tue, 2 Apr 2002 14:50:22 -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 OAA29941 for ; Tue, 2 Apr 2002 14:50:20 -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 LAA03140; Tue, 2 Apr 2002 11:49:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32Jnn717326; Tue, 2 Apr 2002 11:49:49 -0800 X-mProtect: <200204021949> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd24JVE2; Tue, 02 Apr 2002 11:49:47 PST Message-ID: <3CAA0B62.950347CE@iprg.nokia.com> Date: Tue, 02 Apr 2002 11:49:54 -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: Henrik Levkowetz , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <02b801c1da77$82a8f9c0$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 Henrik Levkowetz wrote: > > A question for clarification: When talking about QoS here, do you > > mean specifically QoS as in diffserv or RSVP, or do you mean a more > > general 'quality of service, as determined by first hop available > > bandwidth, latency, SIR etc.' ? I was not intending to bring RSVP or diffserv into the discussion, since I think they are either end-to-end, or else related to infrastructure protocol. I wouldn't call handover an infrastructure operation. To this end, we have made a definition for a "QoS object" which is not oriented towards RSVP or diffserv, and is intended exactly to describe the more general QoS reqiurement that may be specified by a node. We did this for specifying QoS contexts, as would be useful within a context transfer framework. I believe that the same general data layout would be useful in suboptions to a CAR discovery protocol, to identify the QoS requirements or preferences for target access routers. > > The first might be close to intractable for CARD, while I believe > > the latter is not. I agree completely. > James Kempf wrote in response: > > I've been under the assumption that it's the first, i.e. IP QoS. That would give a much different perspective on the issues, but I hope we can eventually agree to leave RSVP and diffserv problems out of the discussion. Otherwise, we might have to spend as many months as they have to get answers, and still not be done, as Henrik pointed out. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 15:02: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 PAA00434 for ; Tue, 2 Apr 2002 15:02:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09933 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 15:02: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 OAA08818; Tue, 2 Apr 2002 14:50: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 OAA08791 for ; Tue, 2 Apr 2002 14:50:22 -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 OAA29941 for ; Tue, 2 Apr 2002 14:50:20 -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 LAA03140; Tue, 2 Apr 2002 11:49:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32Jnn717326; Tue, 2 Apr 2002 11:49:49 -0800 X-mProtect: <200204021949> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd24JVE2; Tue, 02 Apr 2002 11:49:47 PST Message-ID: <3CAA0B62.950347CE@iprg.nokia.com> Date: Tue, 02 Apr 2002 11:49:54 -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: Henrik Levkowetz , seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <02b801c1da77$82a8f9c0$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 Henrik Levkowetz wrote: > > A question for clarification: When talking about QoS here, do you > > mean specifically QoS as in diffserv or RSVP, or do you mean a more > > general 'quality of service, as determined by first hop available > > bandwidth, latency, SIR etc.' ? I was not intending to bring RSVP or diffserv into the discussion, since I think they are either end-to-end, or else related to infrastructure protocol. I wouldn't call handover an infrastructure operation. To this end, we have made a definition for a "QoS object" which is not oriented towards RSVP or diffserv, and is intended exactly to describe the more general QoS reqiurement that may be specified by a node. We did this for specifying QoS contexts, as would be useful within a context transfer framework. I believe that the same general data layout would be useful in suboptions to a CAR discovery protocol, to identify the QoS requirements or preferences for target access routers. > > The first might be close to intractable for CARD, while I believe > > the latter is not. I agree completely. > James Kempf wrote in response: > > I've been under the assumption that it's the first, i.e. IP QoS. That would give a much different perspective on the issues, but I hope we can eventually agree to leave RSVP and diffserv problems out of the discussion. Otherwise, we might have to spend as many months as they have to get answers, and still not be done, as Henrik pointed out. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 15:23: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 PAA01398 for ; Tue, 2 Apr 2002 15:23: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 PAA10398; Tue, 2 Apr 2002 15: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 PAA10371 for ; Tue, 2 Apr 2002 15:10:20 -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 PAA00862 for ; Tue, 2 Apr 2002 15:10:17 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.11.6/8.9.3) with ESMTP id g32KEWA32740; Tue, 2 Apr 2002 22:14:33 +0200 From: "Henrik Levkowetz" To: "Charlie Perkins" , "James Kempf" Cc: Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 22:10:10 +0200 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) In-Reply-To: <3CAA0B62.950347CE@iprg.nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit 2 comments inline: Henrik Charlie Perkins wrote: > Henrik Levkowetz wrote: > > > > A question for clarification: When talking about QoS here, do you > > > mean specifically QoS as in diffserv or RSVP, or do you mean a more > > > general 'quality of service, as determined by first hop available > > > bandwidth, latency, SIR etc.' ? > > I was not intending to bring RSVP or diffserv into the discussion, since > I think they are either end-to-end, or else related to infrastructure > protocol. I wouldn't call handover an infrastructure operation. > > To this end, we have made a definition for a "QoS object" which > is not oriented towards RSVP or diffserv, and is intended exactly to > describe the more general QoS reqiurement that may be specified > by a node. We did this for specifying QoS contexts, as would be > useful within a context transfer framework. I believe that the same > general data layout would be useful in suboptions to a CAR discovery > protocol, to identify the QoS requirements or preferences for target > access routers. Yes, this makes sense. I used some very rough general quality of service quantifications in draft-levkowetz-seamoby-sample-00.txt, where I described an experimental combined CAR and CT protocol we implemented at my previous employer's. It'll be interesting to compare them with the QoS object you describe, and maybe get new insights. > > > > The first might be close to intractable for CARD, while I believe > > > the latter is not. > > I agree completely. > > > James Kempf wrote in response: > > > I've been under the assumption that it's the first, i.e. IP QoS. > > That would give a much different perspective on the issues, but > I hope we can eventually agree to leave RSVP and diffserv problems > out of the discussion. Yes, I agree. > Otherwise, we might have to spend as many > months as they have to get answers, and still not be done, as > Henrik pointed out. > > Regards, > Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 15:23: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 PAA01409 for ; Tue, 2 Apr 2002 15:23:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11066 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 15:23: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 PAA10398; Tue, 2 Apr 2002 15: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 PAA10371 for ; Tue, 2 Apr 2002 15:10:20 -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 PAA00862 for ; Tue, 2 Apr 2002 15:10:17 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.11.6/8.9.3) with ESMTP id g32KEWA32740; Tue, 2 Apr 2002 22:14:33 +0200 From: "Henrik Levkowetz" To: "Charlie Perkins" , "James Kempf" Cc: Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 22:10:10 +0200 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) In-Reply-To: <3CAA0B62.950347CE@iprg.nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit 2 comments inline: Henrik Charlie Perkins wrote: > Henrik Levkowetz wrote: > > > > A question for clarification: When talking about QoS here, do you > > > mean specifically QoS as in diffserv or RSVP, or do you mean a more > > > general 'quality of service, as determined by first hop available > > > bandwidth, latency, SIR etc.' ? > > I was not intending to bring RSVP or diffserv into the discussion, since > I think they are either end-to-end, or else related to infrastructure > protocol. I wouldn't call handover an infrastructure operation. > > To this end, we have made a definition for a "QoS object" which > is not oriented towards RSVP or diffserv, and is intended exactly to > describe the more general QoS reqiurement that may be specified > by a node. We did this for specifying QoS contexts, as would be > useful within a context transfer framework. I believe that the same > general data layout would be useful in suboptions to a CAR discovery > protocol, to identify the QoS requirements or preferences for target > access routers. Yes, this makes sense. I used some very rough general quality of service quantifications in draft-levkowetz-seamoby-sample-00.txt, where I described an experimental combined CAR and CT protocol we implemented at my previous employer's. It'll be interesting to compare them with the QoS object you describe, and maybe get new insights. > > > > The first might be close to intractable for CARD, while I believe > > > the latter is not. > > I agree completely. > > > James Kempf wrote in response: > > > I've been under the assumption that it's the first, i.e. IP QoS. > > That would give a much different perspective on the issues, but > I hope we can eventually agree to leave RSVP and diffserv problems > out of the discussion. Yes, I agree. > Otherwise, we might have to spend as many > months as they have to get answers, and still not be done, as > Henrik pointed out. > > Regards, > Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 16:55: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 QAA05070 for ; Tue, 2 Apr 2002 16:55: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 QAA15629; Tue, 2 Apr 2002 16:42: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 QAA15599 for ; Tue, 2 Apr 2002 16:42:15 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04654 for ; Tue, 2 Apr 2002 16:42:11 -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 g32LevA08705; Tue, 2 Apr 2002 16:40:58 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 16:40:59 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4990@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Henrik Levkowetz'" , Charlie Perkins , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 16:40:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA8F.145257A6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA8F.145257A6 Content-Type: text/plain; charset="iso-8859-1" Comments in-line: > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: April 2, 2002 15:10 > To: Charlie Perkins; James Kempf > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] Examples of CAR discovery > > > 2 comments inline: > > Henrik > > Charlie Perkins wrote: > > Henrik Levkowetz wrote: > > > > > > A question for clarification: When talking about QoS > here, do you > > > > mean specifically QoS as in diffserv or RSVP, or do you > mean a more > > > > general 'quality of service, as determined by first hop > available > > > > bandwidth, latency, SIR etc.' ? > > > > I was not intending to bring RSVP or diffserv into the > discussion, since > > I think they are either end-to-end, or else related to > infrastructure > > protocol. I wouldn't call handover an infrastructure operation. Clearly I have missed something here. Is IP not "infrastructure", or are we no playing in the L2 sandbox? > > > > To this end, we have made a definition for a "QoS object" which > > is not oriented towards RSVP or diffserv, and is intended exactly to > > describe the more general QoS reqiurement that may be specified > > by a node. We did this for specifying QoS contexts, as would be > > useful within a context transfer framework. I believe that the same > > general data layout would be useful in suboptions to a CAR discovery > > protocol, to identify the QoS requirements or preferences for target > > access routers. > > Yes, this makes sense. I used some very rough general quality of > service quantifications in > draft-levkowetz-seamoby-sample-00.txt, where > I described an experimental combined CAR and CT protocol we > implemented > at my previous employer's. It'll be interesting to compare > them with the > QoS object you describe, and maybe get new insights. > > > > > > > The first might be close to intractable for CARD, while > I believe > > > > the latter is not. > > > > I agree completely. > > > > > James Kempf wrote in response: > > > > I've been under the assumption that it's the first, i.e. IP QoS. > > > > That would give a much different perspective on the issues, but > > I hope we can eventually agree to leave RSVP and diffserv problems > > out of the discussion. I am not sure (either way). I agree that there is value in standardizing on context objects, although I'm not sure that the IETF is the place to do it. In particular, a desciption of QoS that involves SIR, bandwidth, etc. immediately presumes certain air interface technologies and ignores others others. As a counter example, the QoS at one network could easily involve other layer 2 measure/technologies then SIR (SIR applies only to interference limited networks). Also, it is not our task to address diffserv (or RSVP) problems, but do we not have to assume that the problems will be solved and that DS, at least, will be part of the context transferred? Gary > > Yes, I agree. > > > Otherwise, we might have to spend as many > > months as they have to get answers, and still not be done, as > > Henrik pointed out. > > > > Regards, > > Charlie P. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DA8F.145257A6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery

Comments in-line:

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: April 2, 2002 15:10
> To: Charlie Perkins; James Kempf
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] Examples of CAR discovery
>
>
> 2 comments inline:
>
>       Henrik
>
> Charlie Perkins wrote:
> > Henrik Levkowetz <henrik@levkowetz.com> wrote:
> >
> > > > A question for clarification: When talking about QoS
> here, do you
> > > > mean specifically QoS as in diffserv or RSVP, or do you
> mean a more
> > > > general 'quality of service, as determined by first hop
> available
> > > > bandwidth, latency, SIR etc.' ?
> >
> > I was not intending to bring RSVP or diffserv into the
> discussion, since
> > I think they are either end-to-end, or else related to
> infrastructure
> > protocol.  I wouldn't call handover an infrastructure operation.

Clearly I have missed something here. Is IP not "infrastructure", or
are we no playing in the L2 sandbox?

> >
> > To this end, we have made a definition for a "QoS object" which
> > is not oriented towards RSVP or diffserv, and is intended exactly to
> > describe the more general QoS reqiurement that may be specified
> > by a node.  We did this for specifying QoS contexts, as would be
> > useful within a context transfer framework.  I believe that the same
> > general data layout would be useful in suboptions to a CAR discovery
> > protocol, to identify the QoS requirements or preferences for target
> > access routers.
>
> Yes, this makes sense. I used some very rough general quality of
> service quantifications in
> draft-levkowetz-seamoby-sample-00.txt, where
> I described an experimental combined CAR and CT protocol we
> implemented
> at my previous employer's. It'll be interesting to compare
> them with the
> QoS object you describe, and maybe get new insights.
>
> >
> > > > The first might be close to intractable for CARD, while
> I believe
> > > > the latter is not.
> >
> > I agree completely.
> >
> > > James Kempf wrote in response:
> > > > I've been under the assumption that it's the first, i.e. IP QoS.
> >
> > That would give a much different perspective on the issues, but
> > I hope we can eventually agree to leave RSVP and diffserv problems
> > out of the discussion. 

I am not sure (either way). I agree that there is value in standardizing
on context objects, although I'm not sure that the IETF is the place to do it.
In particular, a desciption of QoS that involves SIR, bandwidth, etc. immediately
presumes certain air interface technologies and ignores others others. As a
counter example, the QoS at one network could easily involve other layer 2
measure/technologies then SIR (SIR applies only to interference limited networks).

Also, it is not our task to address diffserv (or RSVP) problems, but do we not
have to assume that the problems will be solved and that DS, at least, will be
part of the context transferred?

Gary

>
> Yes, I agree.
>
> > Otherwise, we might have to spend as many
> > months as they have to get answers, and still not be done, as
> > Henrik pointed out.
> >
> > Regards,
> > Charlie P.
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DA8F.145257A6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 16:55: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 QAA05084 for ; Tue, 2 Apr 2002 16:55:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16153 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 16: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 QAA15629; Tue, 2 Apr 2002 16:42: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 QAA15599 for ; Tue, 2 Apr 2002 16:42:15 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04654 for ; Tue, 2 Apr 2002 16:42:11 -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 g32LevA08705; Tue, 2 Apr 2002 16:40:58 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 16:40:59 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4990@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Henrik Levkowetz'" , Charlie Perkins , James Kempf Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 16:40:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA8F.145257A6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA8F.145257A6 Content-Type: text/plain; charset="iso-8859-1" Comments in-line: > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: April 2, 2002 15:10 > To: Charlie Perkins; James Kempf > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] Examples of CAR discovery > > > 2 comments inline: > > Henrik > > Charlie Perkins wrote: > > Henrik Levkowetz wrote: > > > > > > A question for clarification: When talking about QoS > here, do you > > > > mean specifically QoS as in diffserv or RSVP, or do you > mean a more > > > > general 'quality of service, as determined by first hop > available > > > > bandwidth, latency, SIR etc.' ? > > > > I was not intending to bring RSVP or diffserv into the > discussion, since > > I think they are either end-to-end, or else related to > infrastructure > > protocol. I wouldn't call handover an infrastructure operation. Clearly I have missed something here. Is IP not "infrastructure", or are we no playing in the L2 sandbox? > > > > To this end, we have made a definition for a "QoS object" which > > is not oriented towards RSVP or diffserv, and is intended exactly to > > describe the more general QoS reqiurement that may be specified > > by a node. We did this for specifying QoS contexts, as would be > > useful within a context transfer framework. I believe that the same > > general data layout would be useful in suboptions to a CAR discovery > > protocol, to identify the QoS requirements or preferences for target > > access routers. > > Yes, this makes sense. I used some very rough general quality of > service quantifications in > draft-levkowetz-seamoby-sample-00.txt, where > I described an experimental combined CAR and CT protocol we > implemented > at my previous employer's. It'll be interesting to compare > them with the > QoS object you describe, and maybe get new insights. > > > > > > > The first might be close to intractable for CARD, while > I believe > > > > the latter is not. > > > > I agree completely. > > > > > James Kempf wrote in response: > > > > I've been under the assumption that it's the first, i.e. IP QoS. > > > > That would give a much different perspective on the issues, but > > I hope we can eventually agree to leave RSVP and diffserv problems > > out of the discussion. I am not sure (either way). I agree that there is value in standardizing on context objects, although I'm not sure that the IETF is the place to do it. In particular, a desciption of QoS that involves SIR, bandwidth, etc. immediately presumes certain air interface technologies and ignores others others. As a counter example, the QoS at one network could easily involve other layer 2 measure/technologies then SIR (SIR applies only to interference limited networks). Also, it is not our task to address diffserv (or RSVP) problems, but do we not have to assume that the problems will be solved and that DS, at least, will be part of the context transferred? Gary > > Yes, I agree. > > > Otherwise, we might have to spend as many > > months as they have to get answers, and still not be done, as > > Henrik pointed out. > > > > Regards, > > Charlie P. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DA8F.145257A6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery

Comments in-line:

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: April 2, 2002 15:10
> To: Charlie Perkins; James Kempf
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] Examples of CAR discovery
>
>
> 2 comments inline:
>
>       Henrik
>
> Charlie Perkins wrote:
> > Henrik Levkowetz <henrik@levkowetz.com> wrote:
> >
> > > > A question for clarification: When talking about QoS
> here, do you
> > > > mean specifically QoS as in diffserv or RSVP, or do you
> mean a more
> > > > general 'quality of service, as determined by first hop
> available
> > > > bandwidth, latency, SIR etc.' ?
> >
> > I was not intending to bring RSVP or diffserv into the
> discussion, since
> > I think they are either end-to-end, or else related to
> infrastructure
> > protocol.  I wouldn't call handover an infrastructure operation.

Clearly I have missed something here. Is IP not "infrastructure", or
are we no playing in the L2 sandbox?

> >
> > To this end, we have made a definition for a "QoS object" which
> > is not oriented towards RSVP or diffserv, and is intended exactly to
> > describe the more general QoS reqiurement that may be specified
> > by a node.  We did this for specifying QoS contexts, as would be
> > useful within a context transfer framework.  I believe that the same
> > general data layout would be useful in suboptions to a CAR discovery
> > protocol, to identify the QoS requirements or preferences for target
> > access routers.
>
> Yes, this makes sense. I used some very rough general quality of
> service quantifications in
> draft-levkowetz-seamoby-sample-00.txt, where
> I described an experimental combined CAR and CT protocol we
> implemented
> at my previous employer's. It'll be interesting to compare
> them with the
> QoS object you describe, and maybe get new insights.
>
> >
> > > > The first might be close to intractable for CARD, while
> I believe
> > > > the latter is not.
> >
> > I agree completely.
> >
> > > James Kempf wrote in response:
> > > > I've been under the assumption that it's the first, i.e. IP QoS.
> >
> > That would give a much different perspective on the issues, but
> > I hope we can eventually agree to leave RSVP and diffserv problems
> > out of the discussion. 

I am not sure (either way). I agree that there is value in standardizing
on context objects, although I'm not sure that the IETF is the place to do it.
In particular, a desciption of QoS that involves SIR, bandwidth, etc. immediately
presumes certain air interface technologies and ignores others others. As a
counter example, the QoS at one network could easily involve other layer 2
measure/technologies then SIR (SIR applies only to interference limited networks).

Also, it is not our task to address diffserv (or RSVP) problems, but do we not
have to assume that the problems will be solved and that DS, at least, will be
part of the context transferred?

Gary

>
> Yes, I agree.
>
> > Otherwise, we might have to spend as many
> > months as they have to get answers, and still not be done, as
> > Henrik pointed out.
> >
> > Regards,
> > Charlie P.
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DA8F.145257A6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 17:33: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 RAA06140 for ; Tue, 2 Apr 2002 17:33: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 RAA18104; Tue, 2 Apr 2002 17:22: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 RAA18073 for ; Tue, 2 Apr 2002 17:22:45 -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 RAA05807 for ; Tue, 2 Apr 2002 17:22:40 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with ESMTP id g32MQwLv006124; Wed, 3 Apr 2002 00:27:02 +0200 From: "Henrik Levkowetz" To: "James Kempf" , "Charlie Perkins" Cc: Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 3 Apr 2002 00:22:38 +0200 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) In-Reply-To: <033201c1da92$5b99a1c0$7e6015ac@T23KEMPF> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, I'm not 100% sure what you mean below, but I do believe that parameters such as available bandwidth and link latency are highly relevant to especially inter-technology CAR discovery. With respect to standardizing a common representation of such parameters for both CAR and CT, I don't feel that _that_ is necessarily part of the seamoby work. Best, Henrik James Kempf wrote: > > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > > jak > > ----- Original Message ----- > From: "Charlie Perkins" > To: "James Kempf" > Cc: "Henrik Levkowetz" ; > Sent: Tuesday, April 02, 2002 11:49 AM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > Henrik Levkowetz wrote: > > > > > > A question for clarification: When talking about QoS here, do you > > > > mean specifically QoS as in diffserv or RSVP, or do you mean a > more > > > > general 'quality of service, as determined by first hop available > > > > bandwidth, latency, SIR etc.' ? > > > > I was not intending to bring RSVP or diffserv into the discussion, > since > > I think they are either end-to-end, or else related to infrastructure > > protocol. I wouldn't call handover an infrastructure operation. > > > > To this end, we have made a definition for a "QoS object" which > > is not oriented towards RSVP or diffserv, and is intended exactly to > > describe the more general QoS reqiurement that may be specified > > by a node. We did this for specifying QoS contexts, as would be > > useful within a context transfer framework. I believe that the same > > general data layout would be useful in suboptions to a CAR discovery > > protocol, to identify the QoS requirements or preferences for target > > access routers. > > > > > > The first might be close to intractable for CARD, while I believe > > > > the latter is not. > > > > I agree completely. > > > > > James Kempf wrote in response: > > > > I've been under the assumption that it's the first, i.e. IP QoS. > > > > That would give a much different perspective on the issues, but > > I hope we can eventually agree to leave RSVP and diffserv problems > > out of the discussion. Otherwise, we might have to spend as many > > months as they have to get answers, and still not be done, as > > Henrik pointed out. > > > > Regards, > > Charlie P. > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 17:33: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 RAA06151 for ; Tue, 2 Apr 2002 17:33:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19045 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 17:33: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 RAA18104; Tue, 2 Apr 2002 17:22: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 RAA18073 for ; Tue, 2 Apr 2002 17:22:45 -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 RAA05807 for ; Tue, 2 Apr 2002 17:22:40 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.12.2/8.12.2) with ESMTP id g32MQwLv006124; Wed, 3 Apr 2002 00:27:02 +0200 From: "Henrik Levkowetz" To: "James Kempf" , "Charlie Perkins" Cc: Subject: RE: [Seamoby] Examples of CAR discovery Date: Wed, 3 Apr 2002 00:22:38 +0200 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) In-Reply-To: <033201c1da92$5b99a1c0$7e6015ac@T23KEMPF> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, I'm not 100% sure what you mean below, but I do believe that parameters such as available bandwidth and link latency are highly relevant to especially inter-technology CAR discovery. With respect to standardizing a common representation of such parameters for both CAR and CT, I don't feel that _that_ is necessarily part of the seamoby work. Best, Henrik James Kempf wrote: > > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > > jak > > ----- Original Message ----- > From: "Charlie Perkins" > To: "James Kempf" > Cc: "Henrik Levkowetz" ; > Sent: Tuesday, April 02, 2002 11:49 AM > Subject: Re: [Seamoby] Examples of CAR discovery > > > > > > > > Henrik Levkowetz wrote: > > > > > > A question for clarification: When talking about QoS here, do you > > > > mean specifically QoS as in diffserv or RSVP, or do you mean a > more > > > > general 'quality of service, as determined by first hop available > > > > bandwidth, latency, SIR etc.' ? > > > > I was not intending to bring RSVP or diffserv into the discussion, > since > > I think they are either end-to-end, or else related to infrastructure > > protocol. I wouldn't call handover an infrastructure operation. > > > > To this end, we have made a definition for a "QoS object" which > > is not oriented towards RSVP or diffserv, and is intended exactly to > > describe the more general QoS reqiurement that may be specified > > by a node. We did this for specifying QoS contexts, as would be > > useful within a context transfer framework. I believe that the same > > general data layout would be useful in suboptions to a CAR discovery > > protocol, to identify the QoS requirements or preferences for target > > access routers. > > > > > > The first might be close to intractable for CARD, while I believe > > > > the latter is not. > > > > I agree completely. > > > > > James Kempf wrote in response: > > > > I've been under the assumption that it's the first, i.e. IP QoS. > > > > That would give a much different perspective on the issues, but > > I hope we can eventually agree to leave RSVP and diffserv problems > > out of the discussion. Otherwise, we might have to spend as many > > months as they have to get answers, and still not be done, as > > Henrik pointed out. > > > > Regards, > > Charlie P. > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 17:34: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 RAA06224 for ; Tue, 2 Apr 2002 17:34: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 RAA17908; Tue, 2 Apr 2002 17:19: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 RAA17843 for ; Tue, 2 Apr 2002 17:19:39 -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 RAA05667 for ; Tue, 2 Apr 2002 17:19:35 -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 OAA11794; Tue, 2 Apr 2002 14:17:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32MH9H15608; Tue, 2 Apr 2002 14:17:09 -0800 X-mProtect: <200204022217> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt5whth; Tue, 02 Apr 2002 14:17:07 PST Message-ID: <3CAA2DE5.92773697@iprg.nokia.com> Date: Tue, 02 Apr 2002 14:17:09 -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: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <9FBD322B7824D511B36900508BF93C9C01AA4990@zcard031.ca.nortel.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 Hello Gary, You wrote: > Clearly I have missed something here. Is IP not "infrastructure", or > are we no playing in the L2 sandbox? I would say that IP is definitely not "infrastructure", as it is commonly understood. Infrastructure is more towards the high-traffic backbone of the Internet, not the edge devices and access routers. On the other hand, I don't think we are at layer two, either. I think we are "at" the transport layer, just above IP. > > > That would give a much different perspective on the issues, but > > > I hope we can eventually agree to leave RSVP and diffserv problems > > > > out of the discussion. > > I am not sure (either way). I agree that there is value in > standardizing > on context objects, although I'm not sure that the IETF is the place > to do it. Where else? These context objects could be carried as data for suboptions to IETF protocols. > In particular, a desciption of QoS that involves SIR, bandwidth, etc. > immediately > presumes certain air interface technologies and ignores others others. > As a > counter example, the QoS at one network could easily involve other > layer 2 > measure/technologies then SIR (SIR applies only to interference > limited networks). Bandwidth does not presume any particular air interface technology. SIR does not either, but the relevant numbers are pretty high for most wired media. Maybe instead of SIR we would specify an acceptable error rate, but anyway this is quibbling. > Also, it is not our task to address diffserv (or RSVP) problems, but > do we not > have to assume that the problems will be solved and that DS, at least, > will be > part of the context transferred? If a mobile node specifies some DSCP as part of its context, that should be transferred as a relevant feature context. Some mobile nodes might do this, but not all of them. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 17:34: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 RAA06234 for ; Tue, 2 Apr 2002 17:34:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19142 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 17:34: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 RAA17908; Tue, 2 Apr 2002 17:19: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 RAA17843 for ; Tue, 2 Apr 2002 17:19:39 -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 RAA05667 for ; Tue, 2 Apr 2002 17:19:35 -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 OAA11794; Tue, 2 Apr 2002 14:17:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32MH9H15608; Tue, 2 Apr 2002 14:17:09 -0800 X-mProtect: <200204022217> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt5whth; Tue, 02 Apr 2002 14:17:07 PST Message-ID: <3CAA2DE5.92773697@iprg.nokia.com> Date: Tue, 02 Apr 2002 14:17:09 -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: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery References: <9FBD322B7824D511B36900508BF93C9C01AA4990@zcard031.ca.nortel.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 Hello Gary, You wrote: > Clearly I have missed something here. Is IP not "infrastructure", or > are we no playing in the L2 sandbox? I would say that IP is definitely not "infrastructure", as it is commonly understood. Infrastructure is more towards the high-traffic backbone of the Internet, not the edge devices and access routers. On the other hand, I don't think we are at layer two, either. I think we are "at" the transport layer, just above IP. > > > That would give a much different perspective on the issues, but > > > I hope we can eventually agree to leave RSVP and diffserv problems > > > > out of the discussion. > > I am not sure (either way). I agree that there is value in > standardizing > on context objects, although I'm not sure that the IETF is the place > to do it. Where else? These context objects could be carried as data for suboptions to IETF protocols. > In particular, a desciption of QoS that involves SIR, bandwidth, etc. > immediately > presumes certain air interface technologies and ignores others others. > As a > counter example, the QoS at one network could easily involve other > layer 2 > measure/technologies then SIR (SIR applies only to interference > limited networks). Bandwidth does not presume any particular air interface technology. SIR does not either, but the relevant numbers are pretty high for most wired media. Maybe instead of SIR we would specify an acceptable error rate, but anyway this is quibbling. > Also, it is not our task to address diffserv (or RSVP) problems, but > do we not > have to assume that the problems will be solved and that DS, at least, > will be > part of the context transferred? If a mobile node specifies some DSCP as part of its context, that should be transferred as a relevant feature context. Some mobile nodes might do this, but not all of them. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 17:37: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 RAA06288 for ; Tue, 2 Apr 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 RAA18032; Tue, 2 Apr 2002 17:21: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 RAA17999 for ; Tue, 2 Apr 2002 17:21:32 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05749 for ; Tue, 2 Apr 2002 17:21:28 -0500 (EST) From: Hakan.N.Persson@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Apr 2002 00:21:28 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA94.BBE17684" Subject: RE: [Seamoby] Examples of CAR discovery X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 00:21:28 +0200 Message-ID: <75D1795582274D49B4AFC02A165E879818A782@TMS041MB.tcad.telia.se> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHaavwDrwfZCxDSTkuQ/SKX1wtZxQAH3kgQ To: , , , , X-OriginalArrivalTime: 02 Apr 2002 22:21:28.0876 (UTC) FILETIME=[BC178EC0:01C1DA94] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C1DA94.BBE17684 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 Also, the L2 measures like signal to interference ratios (SIR) etc. can = be used, possibly together with some other information like required SIR = for a specific QoS requirement, to estimate how much "bandwidth" are = available to use for new users with a specific QoS requirement. If there = are more than one candidate AP/AR available then it is useful to choose = the one that meet your QoS needs also from a load situation point of = view and not only the radio situation. If not, then either the QoS will = be too poor or you may loose the connection. This not an IP level choice = but more a L2 choice even if there are more than one radio technology = involved.=20 =20 However an access router also need to have the required capacity to = admit new users with specific QoS requirements and if a certain AR does = not have the required capacity on IP level then the same problem will = occur as above if the required QoS on e.g. IP-level cannot be fulfilled. = Otherwise the assumption need to be that the AR capacity is always = assumed to be dimensioned such that it could handle all expected traffic = to/from the connected access points and the outgoing routes. =20 Regards, H=E5kan Persson =20 -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 2 april 2002 19:06 To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Actually, the usual measures for handover for wireless networks are=20 very much QoS related. In noise limited systems (e.g. AMPS), the measure = used is Signal to Noise Ratio (SNR); in interference limited systems = (e.g. CDMA)=20 the measure used is Carrier to Interference Ratio (CIR), where the = interference=20 comes from primarly other MNs. There are also a number of wireless data = systems=20 out there that use BER as a measure.=20 In all of these cases, the measure is used to determine whether there is = a "better"=20 channel for communications. This is L2 QoS.=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: April 2, 2002 11:44=20 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] Examples of CAR discovery=20 >=20 >=20 > John,=20 >=20 > > > So it sounds to me like dynamic QoS negotiation for handover=20 > > > has fallen between the cracks of the WGs.=20 > >=20 > > Do we need full-blown dynamic QoS negotiation for handover?=20 > Originally=20 > > (meaning circa last spring, after the MicroMobility work was removed = > from=20 > > SeaMoby), part of the access router section work was to be a=20 > capabilities=20 > > exchange between ARs, or so I thought. Thinking in terms of baby=20 > steps,=20 > > havning some mechanism which allows a basic mechanisms=20 > (which may end=20 > up=20 > > looking like context tranfer) would not be a bad thing.=20 > >=20 > > To express it more concretely, AR1 and AR2 exchange capability=20 > information.=20 > > This could be done using context transfer even ...=20 > >=20 >=20 > I think what is desired here is a way to take IP level QoS into=20 > consideration when selecting the next access point and access=20 > router to=20 > move to. Today only power is taken into consideration, and=20 > that at Layer=20 > 2.=20 >=20 > jak=20 >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 >=20 ------_=_NextPart_001_01C1DA94.BBE17684 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Examples of CAR discovery
Hi,  
 
Also,=20 the L2 measures like signal to interference ratios (SIR) etc. = can be=20 used, possibly together with some other information like = required SIR=20 for a specific QoS requirement, to estimate how much "bandwidth" are=20 available to use for new users with a specific QoS = requirement. If=20 there are more than one candidate AP/AR available then it is = useful to=20 choose the one that meet your QoS needs also = from=20 a load situation point of view and not only the radio situation. If = not,=20 then either the QoS will be too poor or you may loose the = connection. This=20 not an IP level choice but more a L2 choice even if there are = more=20 than one radio technology involved.
 
However an access router also need to have the required = capacity to admit=20 new users with specific QoS requirements and if a certain = AR does not=20 have the required capacity on IP level then the same problem will occur = as above=20 if the required QoS on e.g. IP-level cannot be=20 fulfilled. Otherwise the assumption need to be = that the=20 AR capacity is always assumed to be dimensioned such that it could = handle all=20 expected traffic to/from the connected access points and the outgoing=20 routes.
 
Regards,
H=E5kan=20 Persson
 
-----Original Message-----
From: Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: den 2 april 2002=20 19:06
To: 'James Kempf'; john.loughney@nokia.com;=20 hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: = [Seamoby]=20 Examples of CAR discovery

Actually, the usual measures for handover for = wireless=20 networks are
very much QoS related. In noise = limited=20 systems (e.g. AMPS), the measure
used is = Signal to=20 Noise Ratio (SNR); in interference limited systems (e.g. CDMA)=20
the measure used is Carrier to Interference Ratio = (CIR),=20 where the interference
comes from primarly = other MNs.=20 There are also a number of wireless data systems
out=20 there that use BER as a measure.

In all of these cases, the measure is used to = determine=20 whether there is a "better"
channel for=20 communications. This is L2 QoS.

Gary


> -----Original Message-----
>=20 From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: April 2, 2002 11:44
>=20 To: john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org=20
> Subject: Re: [Seamoby] Examples of CAR = discovery=20
>
> =
> John,
>
>=20 > > So it sounds to me like dynamic QoS negotiation for = handover=20
> > > has fallen between the cracks of the = WGs.
> >
> > Do we=20 need full-blown dynamic QoS negotiation for handover?
> Originally
> > (meaning = circa last=20 spring, after the MicroMobility work was removed
>=20 from
> > SeaMoby), part of the access = router=20 section work was to be a
> = capabilities=20
> > exchange between ARs, or so I = thought. =20 Thinking in terms of baby
> steps, =
> > havning some mechanism which allows a basic = mechanisms=20
> (which may end
>=20 up
> > looking like context tranfer) = would not=20 be a bad thing.
> >
>=20 > To express it more concretely, AR1 and AR2 exchange = capability=20
> information.
> = > This=20 could be done using context transfer even ...
>=20 >
>
> I = think what is=20 desired here is a way to take IP level QoS into
>=20 consideration when selecting the next access point and access =
> router to
> move to. Today = only power=20 is taken into consideration, and
> that = at=20 Layer
> 2.
> =
>          =   =20 jak
>
> =
> _______________________________________________ =
> Seamoby mailing list
>=20 Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby= =20
>

------_=_NextPart_001_01C1DA94.BBE17684-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 17:37: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 RAA06298 for ; Tue, 2 Apr 2002 17:37:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19275 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 17:37: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 RAA18032; Tue, 2 Apr 2002 17:21: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 RAA17999 for ; Tue, 2 Apr 2002 17:21:32 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05749 for ; Tue, 2 Apr 2002 17:21:28 -0500 (EST) From: Hakan.N.Persson@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Apr 2002 00:21:28 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA94.BBE17684" Subject: RE: [Seamoby] Examples of CAR discovery X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 00:21:28 +0200 Message-ID: <75D1795582274D49B4AFC02A165E879818A782@TMS041MB.tcad.telia.se> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHaavwDrwfZCxDSTkuQ/SKX1wtZxQAH3kgQ To: , , , , X-OriginalArrivalTime: 02 Apr 2002 22:21:28.0876 (UTC) FILETIME=[BC178EC0:01C1DA94] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C1DA94.BBE17684 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 Also, the L2 measures like signal to interference ratios (SIR) etc. can = be used, possibly together with some other information like required SIR = for a specific QoS requirement, to estimate how much "bandwidth" are = available to use for new users with a specific QoS requirement. If there = are more than one candidate AP/AR available then it is useful to choose = the one that meet your QoS needs also from a load situation point of = view and not only the radio situation. If not, then either the QoS will = be too poor or you may loose the connection. This not an IP level choice = but more a L2 choice even if there are more than one radio technology = involved.=20 =20 However an access router also need to have the required capacity to = admit new users with specific QoS requirements and if a certain AR does = not have the required capacity on IP level then the same problem will = occur as above if the required QoS on e.g. IP-level cannot be fulfilled. = Otherwise the assumption need to be that the AR capacity is always = assumed to be dimensioned such that it could handle all expected traffic = to/from the connected access points and the outgoing routes. =20 Regards, H=E5kan Persson =20 -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 2 april 2002 19:06 To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Actually, the usual measures for handover for wireless networks are=20 very much QoS related. In noise limited systems (e.g. AMPS), the measure = used is Signal to Noise Ratio (SNR); in interference limited systems = (e.g. CDMA)=20 the measure used is Carrier to Interference Ratio (CIR), where the = interference=20 comes from primarly other MNs. There are also a number of wireless data = systems=20 out there that use BER as a measure.=20 In all of these cases, the measure is used to determine whether there is = a "better"=20 channel for communications. This is L2 QoS.=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: April 2, 2002 11:44=20 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] Examples of CAR discovery=20 >=20 >=20 > John,=20 >=20 > > > So it sounds to me like dynamic QoS negotiation for handover=20 > > > has fallen between the cracks of the WGs.=20 > >=20 > > Do we need full-blown dynamic QoS negotiation for handover?=20 > Originally=20 > > (meaning circa last spring, after the MicroMobility work was removed = > from=20 > > SeaMoby), part of the access router section work was to be a=20 > capabilities=20 > > exchange between ARs, or so I thought. Thinking in terms of baby=20 > steps,=20 > > havning some mechanism which allows a basic mechanisms=20 > (which may end=20 > up=20 > > looking like context tranfer) would not be a bad thing.=20 > >=20 > > To express it more concretely, AR1 and AR2 exchange capability=20 > information.=20 > > This could be done using context transfer even ...=20 > >=20 >=20 > I think what is desired here is a way to take IP level QoS into=20 > consideration when selecting the next access point and access=20 > router to=20 > move to. Today only power is taken into consideration, and=20 > that at Layer=20 > 2.=20 >=20 > jak=20 >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 >=20 ------_=_NextPart_001_01C1DA94.BBE17684 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Examples of CAR discovery
Hi,  
 
Also,=20 the L2 measures like signal to interference ratios (SIR) etc. = can be=20 used, possibly together with some other information like = required SIR=20 for a specific QoS requirement, to estimate how much "bandwidth" are=20 available to use for new users with a specific QoS = requirement. If=20 there are more than one candidate AP/AR available then it is = useful to=20 choose the one that meet your QoS needs also = from=20 a load situation point of view and not only the radio situation. If = not,=20 then either the QoS will be too poor or you may loose the = connection. This=20 not an IP level choice but more a L2 choice even if there are = more=20 than one radio technology involved.
 
However an access router also need to have the required = capacity to admit=20 new users with specific QoS requirements and if a certain = AR does not=20 have the required capacity on IP level then the same problem will occur = as above=20 if the required QoS on e.g. IP-level cannot be=20 fulfilled. Otherwise the assumption need to be = that the=20 AR capacity is always assumed to be dimensioned such that it could = handle all=20 expected traffic to/from the connected access points and the outgoing=20 routes.
 
Regards,
H=E5kan=20 Persson
 
-----Original Message-----
From: Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: den 2 april 2002=20 19:06
To: 'James Kempf'; john.loughney@nokia.com;=20 hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: = [Seamoby]=20 Examples of CAR discovery

Actually, the usual measures for handover for = wireless=20 networks are
very much QoS related. In noise = limited=20 systems (e.g. AMPS), the measure
used is = Signal to=20 Noise Ratio (SNR); in interference limited systems (e.g. CDMA)=20
the measure used is Carrier to Interference Ratio = (CIR),=20 where the interference
comes from primarly = other MNs.=20 There are also a number of wireless data systems
out=20 there that use BER as a measure.

In all of these cases, the measure is used to = determine=20 whether there is a "better"
channel for=20 communications. This is L2 QoS.

Gary


> -----Original Message-----
>=20 From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: April 2, 2002 11:44
>=20 To: john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org=20
> Subject: Re: [Seamoby] Examples of CAR = discovery=20
>
> =
> John,
>
>=20 > > So it sounds to me like dynamic QoS negotiation for = handover=20
> > > has fallen between the cracks of the = WGs.
> >
> > Do we=20 need full-blown dynamic QoS negotiation for handover?
> Originally
> > (meaning = circa last=20 spring, after the MicroMobility work was removed
>=20 from
> > SeaMoby), part of the access = router=20 section work was to be a
> = capabilities=20
> > exchange between ARs, or so I = thought. =20 Thinking in terms of baby
> steps, =
> > havning some mechanism which allows a basic = mechanisms=20
> (which may end
>=20 up
> > looking like context tranfer) = would not=20 be a bad thing.
> >
>=20 > To express it more concretely, AR1 and AR2 exchange = capability=20
> information.
> = > This=20 could be done using context transfer even ...
>=20 >
>
> I = think what is=20 desired here is a way to take IP level QoS into
>=20 consideration when selecting the next access point and access =
> router to
> move to. Today = only power=20 is taken into consideration, and
> that = at=20 Layer
> 2.
> =
>          =   =20 jak
>
> =
> _______________________________________________ =
> Seamoby mailing list
>=20 Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby= =20
>

------_=_NextPart_001_01C1DA94.BBE17684-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 17:43: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 RAA06533 for ; Tue, 2 Apr 2002 17:43: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 RAA18690; Tue, 2 Apr 2002 17:30: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 RAA18654 for ; Tue, 2 Apr 2002 17:30:50 -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 RAA06082 for ; Tue, 2 Apr 2002 17:30:45 -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 OAA12753; Tue, 2 Apr 2002 14:30:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32MUHj00855; Tue, 2 Apr 2002 14:30:17 -0800 X-mProtect: <200204022230> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcc47Uk; Tue, 02 Apr 2002 14:30:15 PST Message-ID: <3CAA30FD.F5D66424@iprg.nokia.com> Date: Tue, 02 Apr 2002 14:30:21 -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: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> <3CAA0B62.950347CE@iprg.nokia.com> <033201c1da92$5b99a1c0$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 James, I'm O.K. with your suggestion, except that if we don't have any data, we can't show interoperability. We ought to pick out some reasonable contexts just to show that the seamoby protocol really works. I've never heard of any working group standardizing a framework that didn't include some guts too. Having said that, even though I can go along, I still think it might be better to do the work in seamoby. Otherwise, the process will drag on a lot longer. Plus, I reckon that a lot of people in this group will have some expertise with handovers, even if they are not highly experienced in other QoS areas that are more related to interdomain traffic engineering. Regards, Charlie P. James Kempf wrote: > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 17: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 RAA06543 for ; Tue, 2 Apr 2002 17:43:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19588 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 17:43: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 RAA18690; Tue, 2 Apr 2002 17:30: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 RAA18654 for ; Tue, 2 Apr 2002 17:30:50 -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 RAA06082 for ; Tue, 2 Apr 2002 17:30:45 -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 OAA12753; Tue, 2 Apr 2002 14:30:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g32MUHj00855; Tue, 2 Apr 2002 14:30:17 -0800 X-mProtect: <200204022230> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcc47Uk; Tue, 02 Apr 2002 14:30:15 PST Message-ID: <3CAA30FD.F5D66424@iprg.nokia.com> Date: Tue, 02 Apr 2002 14:30:21 -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: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> <3CAA0B62.950347CE@iprg.nokia.com> <033201c1da92$5b99a1c0$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 James, I'm O.K. with your suggestion, except that if we don't have any data, we can't show interoperability. We ought to pick out some reasonable contexts just to show that the seamoby protocol really works. I've never heard of any working group standardizing a framework that didn't include some guts too. Having said that, even though I can go along, I still think it might be better to do the work in seamoby. Otherwise, the process will drag on a lot longer. Plus, I reckon that a lot of people in this group will have some expertise with handovers, even if they are not highly experienced in other QoS areas that are more related to interdomain traffic engineering. Regards, Charlie P. James Kempf wrote: > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 17:44: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 RAA06561 for ; Tue, 2 Apr 2002 17:44: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 RAA19229; Tue, 2 Apr 2002 17:35: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 RAA19200 for ; Tue, 2 Apr 2002 17:35: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 RAA06271 for ; Tue, 2 Apr 2002 17:35: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 g32M64I18348; Tue, 2 Apr 2002 14:06:04 -0800 (PST) Message-ID: <033201c1da92$5b99a1c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: "Henrik Levkowetz" , References: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> <3CAA0B62.950347CE@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 14:04: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 Charlie, The work you describe below sounds potentially valuable, but I really don't think Seamoby is the right place to standardize it, since it is not specifically focused on QoS. There may be need for QoS CT, but, again, I don't think Seamoby's charter extends to standardizing particular feature contexts. My understanding of the charter is that Seamoby will be standardizing on a container for CT. From what John described about about NSIS, I think it would fit into the charter (i.e. end to edge). jak ----- Original Message ----- From: "Charlie Perkins" To: "James Kempf" Cc: "Henrik Levkowetz" ; Sent: Tuesday, April 02, 2002 11:49 AM Subject: Re: [Seamoby] Examples of CAR discovery > > > Henrik Levkowetz wrote: > > > > A question for clarification: When talking about QoS here, do you > > > mean specifically QoS as in diffserv or RSVP, or do you mean a more > > > general 'quality of service, as determined by first hop available > > > bandwidth, latency, SIR etc.' ? > > I was not intending to bring RSVP or diffserv into the discussion, since > I think they are either end-to-end, or else related to infrastructure > protocol. I wouldn't call handover an infrastructure operation. > > To this end, we have made a definition for a "QoS object" which > is not oriented towards RSVP or diffserv, and is intended exactly to > describe the more general QoS reqiurement that may be specified > by a node. We did this for specifying QoS contexts, as would be > useful within a context transfer framework. I believe that the same > general data layout would be useful in suboptions to a CAR discovery > protocol, to identify the QoS requirements or preferences for target > access routers. > > > > The first might be close to intractable for CARD, while I believe > > > the latter is not. > > I agree completely. > > > James Kempf wrote in response: > > > I've been under the assumption that it's the first, i.e. IP QoS. > > That would give a much different perspective on the issues, but > I hope we can eventually agree to leave RSVP and diffserv problems > out of the discussion. Otherwise, we might have to spend as many > months as they have to get answers, and still not be done, as > Henrik pointed out. > > Regards, > Charlie P. > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 17:44: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 RAA06571 for ; Tue, 2 Apr 2002 17:44:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19635 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 17:44: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 RAA19229; Tue, 2 Apr 2002 17:35: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 RAA19200 for ; Tue, 2 Apr 2002 17:35: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 RAA06271 for ; Tue, 2 Apr 2002 17:35: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 g32M64I18348; Tue, 2 Apr 2002 14:06:04 -0800 (PST) Message-ID: <033201c1da92$5b99a1c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: "Henrik Levkowetz" , References: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> <3CAA0B62.950347CE@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 14:04: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 Charlie, The work you describe below sounds potentially valuable, but I really don't think Seamoby is the right place to standardize it, since it is not specifically focused on QoS. There may be need for QoS CT, but, again, I don't think Seamoby's charter extends to standardizing particular feature contexts. My understanding of the charter is that Seamoby will be standardizing on a container for CT. From what John described about about NSIS, I think it would fit into the charter (i.e. end to edge). jak ----- Original Message ----- From: "Charlie Perkins" To: "James Kempf" Cc: "Henrik Levkowetz" ; Sent: Tuesday, April 02, 2002 11:49 AM Subject: Re: [Seamoby] Examples of CAR discovery > > > Henrik Levkowetz wrote: > > > > A question for clarification: When talking about QoS here, do you > > > mean specifically QoS as in diffserv or RSVP, or do you mean a more > > > general 'quality of service, as determined by first hop available > > > bandwidth, latency, SIR etc.' ? > > I was not intending to bring RSVP or diffserv into the discussion, since > I think they are either end-to-end, or else related to infrastructure > protocol. I wouldn't call handover an infrastructure operation. > > To this end, we have made a definition for a "QoS object" which > is not oriented towards RSVP or diffserv, and is intended exactly to > describe the more general QoS reqiurement that may be specified > by a node. We did this for specifying QoS contexts, as would be > useful within a context transfer framework. I believe that the same > general data layout would be useful in suboptions to a CAR discovery > protocol, to identify the QoS requirements or preferences for target > access routers. > > > > The first might be close to intractable for CARD, while I believe > > > the latter is not. > > I agree completely. > > > James Kempf wrote in response: > > > I've been under the assumption that it's the first, i.e. IP QoS. > > That would give a much different perspective on the issues, but > I hope we can eventually agree to leave RSVP and diffserv problems > out of the discussion. Otherwise, we might have to spend as many > months as they have to get answers, and still not be done, as > Henrik pointed out. > > Regards, > Charlie P. > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 17:45: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 RAA06594 for ; Tue, 2 Apr 2002 17:45: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 RAA18965; Tue, 2 Apr 2002 17:32: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 RAA18930 for ; Tue, 2 Apr 2002 17:32:20 -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 RAA06122 for ; Tue, 2 Apr 2002 17:32:16 -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 g32MVPI19356; Tue, 2 Apr 2002 14:31:25 -0800 (PST) Message-ID: <03a001c1da95$e63a3080$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , "'Satish Jamadagni'" , "Nakhjiri Madjid-MNAKHJI1" , "'Hemant Chaskar'" , References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Tue, 2 Apr 2002 14:29: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 Rajeev, Let me number these to make it easier: 1) > IP handover: a process that enables a MN to acquire network layer > _connectivity_ when it changes access routers, allowing it to send and > receive > IP packets. IP handover is a routing issue. > 2) > CT: a process that facilitates continued offering of IP features, > typically > during terminal mobility. > CT addresses performance of transport protocols assuming IP > connectivity is available. It is a transport issue. 3) > CARD: a process that facilitates resolving the prospective link > (identifier) > with its prefix and assocaited capabilities. This comes out as off-link ARP > > with extensions. 4) > TARS: a process that assists in selecting _a_ router from among multiple > candidates. > > For what it is worth.. I do feel strongly however that these be treated as > separate protocols. > I agree with this position. I do see another position, however, and that is that 3) and 4) are subsumed under 1). The reason I mention this is because in order for the routing to get fixed up, there needs to be a router. The problem with subsuming 3) and 4) under 1) is that I believe for intratechnology handovers 1) must be very fast while 3) and 4) are likely to be slower. For intertechnology handover, or what I think should more properly be called *wireless media selection* (and that includes selecting a new router with different IP characterists on the same media - please note Govind :-), the time scale is more leisurely. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 17:45: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 RAA06608 for ; Tue, 2 Apr 2002 17:45:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19686 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 17: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 RAA18965; Tue, 2 Apr 2002 17:32: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 RAA18930 for ; Tue, 2 Apr 2002 17:32:20 -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 RAA06122 for ; Tue, 2 Apr 2002 17:32:16 -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 g32MVPI19356; Tue, 2 Apr 2002 14:31:25 -0800 (PST) Message-ID: <03a001c1da95$e63a3080$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , "'Satish Jamadagni'" , "Nakhjiri Madjid-MNAKHJI1" , "'Hemant Chaskar'" , References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Tue, 2 Apr 2002 14:29: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 Rajeev, Let me number these to make it easier: 1) > IP handover: a process that enables a MN to acquire network layer > _connectivity_ when it changes access routers, allowing it to send and > receive > IP packets. IP handover is a routing issue. > 2) > CT: a process that facilitates continued offering of IP features, > typically > during terminal mobility. > CT addresses performance of transport protocols assuming IP > connectivity is available. It is a transport issue. 3) > CARD: a process that facilitates resolving the prospective link > (identifier) > with its prefix and assocaited capabilities. This comes out as off-link ARP > > with extensions. 4) > TARS: a process that assists in selecting _a_ router from among multiple > candidates. > > For what it is worth.. I do feel strongly however that these be treated as > separate protocols. > I agree with this position. I do see another position, however, and that is that 3) and 4) are subsumed under 1). The reason I mention this is because in order for the routing to get fixed up, there needs to be a router. The problem with subsuming 3) and 4) under 1) is that I believe for intratechnology handovers 1) must be very fast while 3) and 4) are likely to be slower. For intertechnology handover, or what I think should more properly be called *wireless media selection* (and that includes selecting a new router with different IP characterists on the same media - please note Govind :-), the time scale is more leisurely. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 17:49: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 RAA06646 for ; Tue, 2 Apr 2002 17:49: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 RAA19379; Tue, 2 Apr 2002 17:40: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 RAA19347 for ; Tue, 2 Apr 2002 17:40: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 RAA06400 for ; Tue, 2 Apr 2002 17:40: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 g32McpI19709; Tue, 2 Apr 2002 14:38:51 -0800 (PST) Message-ID: <03bf01c1da96$efbf8460$7e6015ac@T23KEMPF> From: "James Kempf" To: "Henrik Levkowetz" , "Charlie Perkins" Cc: References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 14:37: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 Henrik, > I'm not 100% sure what you mean below, but I do believe that > parameters such as available bandwidth and link latency are highly > relevant to especially inter-technology CAR discovery. > My comment was intended to address just the notion of a QoS object and its contents. I do not think that these are currently part of Seamoby's charter, thus, I do not think the right people would be involved in the WG to address standardizing them. With respect to available bandwidth and link latency, these sound like particular CAR capabilities. My reading of the current charter is that we will not be actually standardizing on particular capabilities, just on how to transfer them, similarly to how we will not be standardizing on particular CT feature contexts, just how to carry them for CT. Of course, in both cases, we need to specify the process by which capabilities and feature contexts are standardized (IANA, IETF standards action, special expert review, etc.) > With respect to standardizing a common representation of such > parameters for both CAR and CT, I don't feel that _that_ is > necessarily part of the seamoby work. > If by common respresentation you mean what I said above, then I agree. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 17:49: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 RAA06656 for ; Tue, 2 Apr 2002 17:49:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19818 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 17:49: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 RAA19379; Tue, 2 Apr 2002 17:40: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 RAA19347 for ; Tue, 2 Apr 2002 17:40: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 RAA06400 for ; Tue, 2 Apr 2002 17:40: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 g32McpI19709; Tue, 2 Apr 2002 14:38:51 -0800 (PST) Message-ID: <03bf01c1da96$efbf8460$7e6015ac@T23KEMPF> From: "James Kempf" To: "Henrik Levkowetz" , "Charlie Perkins" Cc: References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 14:37: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 Henrik, > I'm not 100% sure what you mean below, but I do believe that > parameters such as available bandwidth and link latency are highly > relevant to especially inter-technology CAR discovery. > My comment was intended to address just the notion of a QoS object and its contents. I do not think that these are currently part of Seamoby's charter, thus, I do not think the right people would be involved in the WG to address standardizing them. With respect to available bandwidth and link latency, these sound like particular CAR capabilities. My reading of the current charter is that we will not be actually standardizing on particular capabilities, just on how to transfer them, similarly to how we will not be standardizing on particular CT feature contexts, just how to carry them for CT. Of course, in both cases, we need to specify the process by which capabilities and feature contexts are standardized (IANA, IETF standards action, special expert review, etc.) > With respect to standardizing a common representation of such > parameters for both CAR and CT, I don't feel that _that_ is > necessarily part of the seamoby work. > If by common respresentation you mean what I said above, then I agree. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 18:02: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 SAA07122 for ; Tue, 2 Apr 2002 18: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 RAA19951; Tue, 2 Apr 2002 17:51: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 RAA19873 for ; Tue, 2 Apr 2002 17:51:12 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06733 for ; Tue, 2 Apr 2002 17:51:08 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32MnnA19493; Tue, 2 Apr 2002 17:49:49 -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 g32Mnmo04516; Tue, 2 Apr 2002 17:49:48 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:49:49 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4992@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:49:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA98.B27A4EEE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA98.B27A4EEE Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 2, 2002 17:17 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hello Gary, > > You wrote: > > > Clearly I have missed something here. Is IP not "infrastructure", or > > are we no playing in the L2 sandbox? > > I would say that IP is definitely not "infrastructure", > as it is commonly understood. Infrastructure is more > towards the high-traffic backbone of the Internet, > not the edge devices and access routers. On the > other hand, I don't think we are at layer two, either. > I think we are "at" the transport layer, just above IP. Ok. Different definition that I am aware of, where infrastructure is all the pieces connected with wires (or these days, glass). > > > > > That would give a much different perspective on the issues, but > > > > I hope we can eventually agree to leave RSVP and > diffserv problems > > > > > > out of the discussion. > > > > I am not sure (either way). I agree that there is value in > > standardizing > > on context objects, although I'm not sure that the IETF is the place > > to do it. > > Where else? These context objects could be > carried as data for suboptions to IETF protocols. Don't know. I'd love to give it a try, but the kind of objects that were being discussed seemed very link layer dependent. Maybe what is needed is a generic structure? > > > In particular, a desciption of QoS that involves SIR, > bandwidth, etc. > > immediately > > presumes certain air interface technologies and ignores > others others. > > As a > > counter example, the QoS at one network could easily involve other > > layer 2 > > measure/technologies then SIR (SIR applies only to interference > > limited networks). > > Bandwidth does not presume any particular air interface If you bandwidth as "goodput", sure. But then, you will need a number of other descriptive parameters, including acceptable charging limits, before "goodput" per se would be useful parameter. E.g. suppose I am using 100Kbps on an 802.11b channel at a maximum latency of 0.01 sec (arbitrary numbers), at 99% packet transfer success reliability, and I roam to a wide area cellular channel where, in order to reach the 99% reliability, the overhead quadruples and the latency (due to retransmissions) goes to 100s of milliseconds. Along with the overhead increase one would guess that there might be a charging rate increase. Now, I contend that only the application can really decide what parameters might really matter in this case; however, most applications don't know, and don't want to know about L2 QoS parameters. And this is not the most complex situation - e.g. consider most 3G systems that will multiplex IP frames into radio frames, resulting in packet loses occuring in bursts of two or more; some applications (such as voice) are very sensitive to back to back losses of this nature. Request no multiplexing and the radio channel overhead goes up by the amount of unused bits in each radio frame. > technology. SIR does not either, but the relevant numbers > are pretty high for most wired media. Maybe instead of SIR SIR, in my lexicon, means "Signal to Interference Ratio". Not all wireless systems are interference limited, to begin with, so SIR may not be a very useful parameter in those cases. > we would specify an acceptable error rate, but anyway this > is quibbling. Aye, but it is the quibbling that causes the problems with defining a general set of QoS parameters. I am not trying to start the quibbling, simply pointing out the issue. > > > Also, it is not our task to address diffserv (or RSVP) problems, but > > do we not > > have to assume that the problems will be solved and that > DS, at least, > > will be > > part of the context transferred? > > If a mobile node specifies some DSCP as part of its context, > that should be transferred as a relevant feature context. Some > mobile nodes might do this, but not all of them. I am with you on the DSCP. I guess we can agree to disagree on whether the mobile should know about QoS context. I contend that it is the network that is best able to contend with QoS descrepencies, as these issues can be sorted out during network configuration and the writing of the TLAs. So, to summarize, I believe that standardizing on QoS objects *may* be useful, but for different reasons. I am also skeptical about how successful we will be, for many bright people have attempt this before. Of course, if the issue is to define QoS objects only for handover between the various flavours of 3G (UMTS utran, UMTS etran, CDMA2000 1xRTTDO, CDMA2000 DV) and three flavours of 802.11 (a, b and g), then it's feasible. Cheers, Gary > > Regards, > Charlie P. > > > > ------_=_NextPart_001_01C1DA98.B27A4EEE Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery

Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 2, 2002 17:17
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR discovery
>
>
>
> Hello Gary,
>
> You wrote:
>
> > Clearly I have missed something here. Is IP not "infrastructure", or
> > are we no playing in the L2 sandbox?
>
> I would say that IP is definitely not "infrastructure",
> as it is commonly understood. Infrastructure is more
> towards the high-traffic backbone of the Internet,
> not the edge devices and access routers.  On the
> other hand, I don't think we are at layer two, either.
> I think we are "at" the transport layer, just above IP.

Ok. Different definition that I am aware of, where infrastructure is
all the pieces connected with wires (or these days, glass).

>
> > > > That would give a much different perspective on the issues, but
> > > > I hope we can eventually agree to leave RSVP and
> diffserv problems
> >
> > > > out of the discussion.
> >
> > I am not sure (either way). I agree that there is value in
> > standardizing
> > on context objects, although I'm not sure that the IETF is the place
> > to do it.
>
> Where else?  These context objects could be
> carried as data for suboptions to IETF protocols.

Don't know. I'd love to give it a try, but the kind of objects that were
being discussed seemed very link layer dependent. Maybe what is needed is
a generic structure?

>
> > In particular, a desciption of QoS that involves SIR,
> bandwidth, etc.
> > immediately
> > presumes certain air interface technologies and ignores
> others others.
> > As a
> > counter example, the QoS at one network could easily involve other
> > layer 2
> > measure/technologies then SIR (SIR applies only to interference
> > limited networks).
>
> Bandwidth does not presume any particular air interface

If you bandwidth as "goodput", sure. But then, you will need a number of
other descriptive parameters, including acceptable charging limits, before
"goodput" per se would be useful parameter. E.g. suppose I am using 100Kbps on
an 802.11b channel at a maximum latency of 0.01 sec (arbitrary numbers), at 99%
packet transfer success reliability, and I roam to a wide area cellular channel
where, in order to reach the 99% reliability, the overhead quadruples and the
latency (due to retransmissions) goes to 100s of milliseconds. Along with the
overhead increase one would guess that there might be a charging rate increase.
Now, I contend that only the application can really decide what parameters might
really matter in this case; however, most applications don't know, and don't want
to know about L2 QoS parameters. And this is not the most complex situation - e.g.
consider most 3G systems that will multiplex IP frames into radio frames, resulting
in packet loses occuring in bursts of two or more; some applications (such as voice)
are very sensitive to back to back losses of this nature. Request no multiplexing
and the radio channel overhead goes up by the amount of unused bits in each radio
frame.

> technology.  SIR does not either, but the relevant numbers
> are pretty high for most wired media.  Maybe instead of SIR

SIR, in my lexicon, means "Signal to Interference Ratio". Not all wireless
systems are interference limited, to begin with, so SIR may not be a very
useful parameter in those cases.

> we would specify an acceptable error rate, but anyway this
> is quibbling.

Aye, but it is the quibbling that causes the problems with defining a general
set of QoS parameters. I am not trying to start the quibbling, simply pointing
out the issue.

>
> > Also, it is not our task to address diffserv (or RSVP) problems, but
> > do we not
> > have to assume that the problems will be solved and that
> DS, at least,
> > will be
> > part of the context transferred?
>
> If a mobile node specifies some DSCP as part of its context,
> that should be transferred as a relevant feature context.  Some
> mobile nodes might do this, but not all of them.

I am with you on the DSCP.

I guess we can agree to disagree on whether the mobile should know about QoS context.
I contend that it is the network that is best able to contend with QoS descrepencies,
as these issues can be sorted out during network configuration and the writing of
the TLAs.

So, to summarize, I believe that standardizing on QoS objects *may* be useful, but for
different reasons. I am also skeptical about how successful we will be, for many bright people
have attempt this before.

Of course, if the issue is to define QoS objects only for handover between the various flavours of
3G (UMTS utran, UMTS etran, CDMA2000 1xRTTDO, CDMA2000 DV) and three flavours of 802.11 (a, b and g), then it's feasible.


Cheers,
Gary
>
> Regards,
> Charlie P.
>
>
>
>

------_=_NextPart_001_01C1DA98.B27A4EEE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 18:02: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 SAA07135 for ; Tue, 2 Apr 2002 18:02:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21394 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 18:02: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 RAA19951; Tue, 2 Apr 2002 17:51: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 RAA19873 for ; Tue, 2 Apr 2002 17:51:12 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06733 for ; Tue, 2 Apr 2002 17:51:08 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32MnnA19493; Tue, 2 Apr 2002 17:49:49 -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 g32Mnmo04516; Tue, 2 Apr 2002 17:49:48 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 17:49:49 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4992@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charlie Perkins'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 17:49:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA98.B27A4EEE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA98.B27A4EEE Content-Type: text/plain; charset="iso-8859-1" Charlie: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 2, 2002 17:17 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] Examples of CAR discovery > > > > Hello Gary, > > You wrote: > > > Clearly I have missed something here. Is IP not "infrastructure", or > > are we no playing in the L2 sandbox? > > I would say that IP is definitely not "infrastructure", > as it is commonly understood. Infrastructure is more > towards the high-traffic backbone of the Internet, > not the edge devices and access routers. On the > other hand, I don't think we are at layer two, either. > I think we are "at" the transport layer, just above IP. Ok. Different definition that I am aware of, where infrastructure is all the pieces connected with wires (or these days, glass). > > > > > That would give a much different perspective on the issues, but > > > > I hope we can eventually agree to leave RSVP and > diffserv problems > > > > > > out of the discussion. > > > > I am not sure (either way). I agree that there is value in > > standardizing > > on context objects, although I'm not sure that the IETF is the place > > to do it. > > Where else? These context objects could be > carried as data for suboptions to IETF protocols. Don't know. I'd love to give it a try, but the kind of objects that were being discussed seemed very link layer dependent. Maybe what is needed is a generic structure? > > > In particular, a desciption of QoS that involves SIR, > bandwidth, etc. > > immediately > > presumes certain air interface technologies and ignores > others others. > > As a > > counter example, the QoS at one network could easily involve other > > layer 2 > > measure/technologies then SIR (SIR applies only to interference > > limited networks). > > Bandwidth does not presume any particular air interface If you bandwidth as "goodput", sure. But then, you will need a number of other descriptive parameters, including acceptable charging limits, before "goodput" per se would be useful parameter. E.g. suppose I am using 100Kbps on an 802.11b channel at a maximum latency of 0.01 sec (arbitrary numbers), at 99% packet transfer success reliability, and I roam to a wide area cellular channel where, in order to reach the 99% reliability, the overhead quadruples and the latency (due to retransmissions) goes to 100s of milliseconds. Along with the overhead increase one would guess that there might be a charging rate increase. Now, I contend that only the application can really decide what parameters might really matter in this case; however, most applications don't know, and don't want to know about L2 QoS parameters. And this is not the most complex situation - e.g. consider most 3G systems that will multiplex IP frames into radio frames, resulting in packet loses occuring in bursts of two or more; some applications (such as voice) are very sensitive to back to back losses of this nature. Request no multiplexing and the radio channel overhead goes up by the amount of unused bits in each radio frame. > technology. SIR does not either, but the relevant numbers > are pretty high for most wired media. Maybe instead of SIR SIR, in my lexicon, means "Signal to Interference Ratio". Not all wireless systems are interference limited, to begin with, so SIR may not be a very useful parameter in those cases. > we would specify an acceptable error rate, but anyway this > is quibbling. Aye, but it is the quibbling that causes the problems with defining a general set of QoS parameters. I am not trying to start the quibbling, simply pointing out the issue. > > > Also, it is not our task to address diffserv (or RSVP) problems, but > > do we not > > have to assume that the problems will be solved and that > DS, at least, > > will be > > part of the context transferred? > > If a mobile node specifies some DSCP as part of its context, > that should be transferred as a relevant feature context. Some > mobile nodes might do this, but not all of them. I am with you on the DSCP. I guess we can agree to disagree on whether the mobile should know about QoS context. I contend that it is the network that is best able to contend with QoS descrepencies, as these issues can be sorted out during network configuration and the writing of the TLAs. So, to summarize, I believe that standardizing on QoS objects *may* be useful, but for different reasons. I am also skeptical about how successful we will be, for many bright people have attempt this before. Of course, if the issue is to define QoS objects only for handover between the various flavours of 3G (UMTS utran, UMTS etran, CDMA2000 1xRTTDO, CDMA2000 DV) and three flavours of 802.11 (a, b and g), then it's feasible. Cheers, Gary > > Regards, > Charlie P. > > > > ------_=_NextPart_001_01C1DA98.B27A4EEE Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery

Charlie:

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 2, 2002 17:17
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR discovery
>
>
>
> Hello Gary,
>
> You wrote:
>
> > Clearly I have missed something here. Is IP not "infrastructure", or
> > are we no playing in the L2 sandbox?
>
> I would say that IP is definitely not "infrastructure",
> as it is commonly understood. Infrastructure is more
> towards the high-traffic backbone of the Internet,
> not the edge devices and access routers.  On the
> other hand, I don't think we are at layer two, either.
> I think we are "at" the transport layer, just above IP.

Ok. Different definition that I am aware of, where infrastructure is
all the pieces connected with wires (or these days, glass).

>
> > > > That would give a much different perspective on the issues, but
> > > > I hope we can eventually agree to leave RSVP and
> diffserv problems
> >
> > > > out of the discussion.
> >
> > I am not sure (either way). I agree that there is value in
> > standardizing
> > on context objects, although I'm not sure that the IETF is the place
> > to do it.
>
> Where else?  These context objects could be
> carried as data for suboptions to IETF protocols.

Don't know. I'd love to give it a try, but the kind of objects that were
being discussed seemed very link layer dependent. Maybe what is needed is
a generic structure?

>
> > In particular, a desciption of QoS that involves SIR,
> bandwidth, etc.
> > immediately
> > presumes certain air interface technologies and ignores
> others others.
> > As a
> > counter example, the QoS at one network could easily involve other
> > layer 2
> > measure/technologies then SIR (SIR applies only to interference
> > limited networks).
>
> Bandwidth does not presume any particular air interface

If you bandwidth as "goodput", sure. But then, you will need a number of
other descriptive parameters, including acceptable charging limits, before
"goodput" per se would be useful parameter. E.g. suppose I am using 100Kbps on
an 802.11b channel at a maximum latency of 0.01 sec (arbitrary numbers), at 99%
packet transfer success reliability, and I roam to a wide area cellular channel
where, in order to reach the 99% reliability, the overhead quadruples and the
latency (due to retransmissions) goes to 100s of milliseconds. Along with the
overhead increase one would guess that there might be a charging rate increase.
Now, I contend that only the application can really decide what parameters might
really matter in this case; however, most applications don't know, and don't want
to know about L2 QoS parameters. And this is not the most complex situation - e.g.
consider most 3G systems that will multiplex IP frames into radio frames, resulting
in packet loses occuring in bursts of two or more; some applications (such as voice)
are very sensitive to back to back losses of this nature. Request no multiplexing
and the radio channel overhead goes up by the amount of unused bits in each radio
frame.

> technology.  SIR does not either, but the relevant numbers
> are pretty high for most wired media.  Maybe instead of SIR

SIR, in my lexicon, means "Signal to Interference Ratio". Not all wireless
systems are interference limited, to begin with, so SIR may not be a very
useful parameter in those cases.

> we would specify an acceptable error rate, but anyway this
> is quibbling.

Aye, but it is the quibbling that causes the problems with defining a general
set of QoS parameters. I am not trying to start the quibbling, simply pointing
out the issue.

>
> > Also, it is not our task to address diffserv (or RSVP) problems, but
> > do we not
> > have to assume that the problems will be solved and that
> DS, at least,
> > will be
> > part of the context transferred?
>
> If a mobile node specifies some DSCP as part of its context,
> that should be transferred as a relevant feature context.  Some
> mobile nodes might do this, but not all of them.

I am with you on the DSCP.

I guess we can agree to disagree on whether the mobile should know about QoS context.
I contend that it is the network that is best able to contend with QoS descrepencies,
as these issues can be sorted out during network configuration and the writing of
the TLAs.

So, to summarize, I believe that standardizing on QoS objects *may* be useful, but for
different reasons. I am also skeptical about how successful we will be, for many bright people
have attempt this before.

Of course, if the issue is to define QoS objects only for handover between the various flavours of
3G (UMTS utran, UMTS etran, CDMA2000 1xRTTDO, CDMA2000 DV) and three flavours of 802.11 (a, b and g), then it's feasible.


Cheers,
Gary
>
> Regards,
> Charlie P.
>
>
>
>

------_=_NextPart_001_01C1DA98.B27A4EEE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 18:14: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 SAA07534 for ; Tue, 2 Apr 2002 18: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 SAA20809; Tue, 2 Apr 2002 18:01: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 SAA20777 for ; Tue, 2 Apr 2002 18:01:04 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07058 for ; Tue, 2 Apr 2002 18:00:59 -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 g32N0LA23233; Tue, 2 Apr 2002 18:00:21 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 18:00:22 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4993@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hakan.N.Persson@telia.se'" , kempf@docomolabs-usa.com, john.loughney@nokia.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 18:00:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA9A.2C178162" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA9A.2C178162 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIR: For SIR to be a useful inter-networking, inter-technology, = handover parameter, we would have to standardize not only the parameter, but the method for measuring SIR, would we not? This = would also be true for BER? Latency (for an example of the latter I refer to the debates over the EF RFC in Diff Serv). =20 Gary -----Original Message----- From: Hakan.N.Persson@telia.se [mailto:Hakan.N.Persson@telia.se] Sent: April 2, 2002 17:21 To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Hi, =20 =20 Also, the L2 measures like signal to interference ratios (SIR) etc. can = be used, possibly together with some other information like required SIR = for a specific QoS requirement, to estimate how much "bandwidth" are = available to use for new users with a specific QoS requirement. If there are more = than one candidate AP/AR available then it is useful to choose the one that = meet your QoS needs also from a load situation point of view and not only = the radio situation. If not, then either the QoS will be too poor or you = may loose the connection. This not an IP level choice but more a L2 choice = even if there are more than one radio technology involved.=20 =20 However an access router also need to have the required capacity to = admit new users with specific QoS requirements and if a certain AR does not = have the required capacity on IP level then the same problem will occur as = above if the required QoS on e.g. IP-level cannot be fulfilled. Otherwise the assumption need to be that the AR capacity is always assumed to be dimensioned such that it could handle all expected traffic to/from the connected access points and the outgoing routes. =20 Regards, H=E5kan Persson =20 -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 2 april 2002 19:06 To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Actually, the usual measures for handover for wireless networks are=20 very much QoS related. In noise limited systems (e.g. AMPS), the = measure=20 used is Signal to Noise Ratio (SNR); in interference limited systems = (e.g. CDMA)=20 the measure used is Carrier to Interference Ratio (CIR), where the interference=20 comes from primarly other MNs. There are also a number of wireless data systems=20 out there that use BER as a measure.=20 In all of these cases, the measure is used to determine whether there = is a "better"=20 channel for communications. This is L2 QoS.=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com ]=20 > Sent: April 2, 2002 11:44=20 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] Examples of CAR discovery=20 >=20 >=20 > John,=20 >=20 > > > So it sounds to me like dynamic QoS negotiation for handover=20 > > > has fallen between the cracks of the WGs.=20 > >=20 > > Do we need full-blown dynamic QoS negotiation for handover?=20 > Originally=20 > > (meaning circa last spring, after the MicroMobility work was = removed=20 > from=20 > > SeaMoby), part of the access router section work was to be a=20 > capabilities=20 > > exchange between ARs, or so I thought. Thinking in terms of baby=20 > steps,=20 > > havning some mechanism which allows a basic mechanisms=20 > (which may end=20 > up=20 > > looking like context tranfer) would not be a bad thing.=20 > >=20 > > To express it more concretely, AR1 and AR2 exchange capability=20 > information.=20 > > This could be done using context transfer even ...=20 > >=20 >=20 > I think what is desired here is a way to take IP level QoS into=20 > consideration when selecting the next access point and access=20 > router to=20 > move to. Today only power is taken into consideration, and=20 > that at Layer=20 > 2.=20 >=20 > jak=20 >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby =20 >=20 ------_=_NextPart_001_01C1DA9A.2C178162 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery
SIR: For SIR to be a useful inter-networking, inter-technology, handover parameter, we would have to standardize not only
the parameter, but the method for measuring SIR, would we not? This would also be true for BER? Latency (for an example of
the latter I refer to the debates over the EF RFC in Diff Serv).
 
Gary
-----Original Message-----
From: Hakan.N.Persson@telia.se [mailto:Hakan.N.Persson@telia.se]
Sent: April 2, 2002 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR discovery

Hi,  
 
Also, the L2 measures like signal to interference ratios (SIR) etc. can be used, possibly together with some other information like required SIR for a specific QoS requirement, to estimate how much "bandwidth" are available to use for new users with a specific QoS requirement. If there are more than one candidate AP/AR available then it is useful to choose the one that meet your QoS needs also from a load situation point of view and not only the radio situation. If not, then either the QoS will be too poor or you may loose the connection. This not an IP level choice but more a L2 choice even if there are more than one radio technology involved.
 
However an access router also need to have the required capacity to admit new users with specific QoS requirements and if a certain AR does not have the required capacity on IP level then the same problem will occur as above if the required QoS on e.g. IP-level cannot be fulfilled. Otherwise the assumption need to be that the AR capacity is always assumed to be dimensioned such that it could handle all expected traffic to/from the connected access points and the outgoing routes.
 
Regards,
Håkan Persson
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR discovery

Actually, the usual measures for handover for wireless networks are
very much QoS related. In noise limited systems (e.g. AMPS), the measure
used is Signal to Noise Ratio (SNR); in interference limited systems (e.g. CDMA)
the measure used is Carrier to Interference Ratio (CIR), where the interference
comes from primarly other MNs. There are also a number of wireless data systems
out there that use BER as a measure.

In all of these cases, the measure is used to determine whether there is a "better"
channel for communications. This is L2 QoS.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 2, 2002 11:44
> To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR discovery
>
>
> John,
>
> > > So it sounds to me like dynamic QoS negotiation for handover
> > > has fallen between the cracks of the WGs.
> >
> > Do we need full-blown dynamic QoS negotiation for handover?
> Originally
> > (meaning circa last spring, after the MicroMobility work was removed
> from
> > SeaMoby), part of the access router section work was to be a
> capabilities
> > exchange between ARs, or so I thought.  Thinking in terms of baby
> steps,
> > havning some mechanism which allows a basic mechanisms
> (which may end
> up
> > looking like context tranfer) would not be a bad thing.
> >
> > To express it more concretely, AR1 and AR2 exchange capability
> information.
> > This could be done using context transfer even ...
> >
>
> I think what is desired here is a way to take IP level QoS into
> consideration when selecting the next access point and access
> router to
> move to. Today only power is taken into consideration, and
> that at Layer
> 2.
>
>             jak
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DA9A.2C178162-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 18: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 SAA07548 for ; Tue, 2 Apr 2002 18:14:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23169 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 18:14: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 SAA20809; Tue, 2 Apr 2002 18:01: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 SAA20777 for ; Tue, 2 Apr 2002 18:01:04 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07058 for ; Tue, 2 Apr 2002 18:00:59 -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 g32N0LA23233; Tue, 2 Apr 2002 18:00:21 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 18:00:22 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4993@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hakan.N.Persson@telia.se'" , kempf@docomolabs-usa.com, john.loughney@nokia.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 18:00:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA9A.2C178162" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DA9A.2C178162 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIR: For SIR to be a useful inter-networking, inter-technology, = handover parameter, we would have to standardize not only the parameter, but the method for measuring SIR, would we not? This = would also be true for BER? Latency (for an example of the latter I refer to the debates over the EF RFC in Diff Serv). =20 Gary -----Original Message----- From: Hakan.N.Persson@telia.se [mailto:Hakan.N.Persson@telia.se] Sent: April 2, 2002 17:21 To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Hi, =20 =20 Also, the L2 measures like signal to interference ratios (SIR) etc. can = be used, possibly together with some other information like required SIR = for a specific QoS requirement, to estimate how much "bandwidth" are = available to use for new users with a specific QoS requirement. If there are more = than one candidate AP/AR available then it is useful to choose the one that = meet your QoS needs also from a load situation point of view and not only = the radio situation. If not, then either the QoS will be too poor or you = may loose the connection. This not an IP level choice but more a L2 choice = even if there are more than one radio technology involved.=20 =20 However an access router also need to have the required capacity to = admit new users with specific QoS requirements and if a certain AR does not = have the required capacity on IP level then the same problem will occur as = above if the required QoS on e.g. IP-level cannot be fulfilled. Otherwise the assumption need to be that the AR capacity is always assumed to be dimensioned such that it could handle all expected traffic to/from the connected access points and the outgoing routes. =20 Regards, H=E5kan Persson =20 -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 2 april 2002 19:06 To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Actually, the usual measures for handover for wireless networks are=20 very much QoS related. In noise limited systems (e.g. AMPS), the = measure=20 used is Signal to Noise Ratio (SNR); in interference limited systems = (e.g. CDMA)=20 the measure used is Carrier to Interference Ratio (CIR), where the interference=20 comes from primarly other MNs. There are also a number of wireless data systems=20 out there that use BER as a measure.=20 In all of these cases, the measure is used to determine whether there = is a "better"=20 channel for communications. This is L2 QoS.=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com ]=20 > Sent: April 2, 2002 11:44=20 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] Examples of CAR discovery=20 >=20 >=20 > John,=20 >=20 > > > So it sounds to me like dynamic QoS negotiation for handover=20 > > > has fallen between the cracks of the WGs.=20 > >=20 > > Do we need full-blown dynamic QoS negotiation for handover?=20 > Originally=20 > > (meaning circa last spring, after the MicroMobility work was = removed=20 > from=20 > > SeaMoby), part of the access router section work was to be a=20 > capabilities=20 > > exchange between ARs, or so I thought. Thinking in terms of baby=20 > steps,=20 > > havning some mechanism which allows a basic mechanisms=20 > (which may end=20 > up=20 > > looking like context tranfer) would not be a bad thing.=20 > >=20 > > To express it more concretely, AR1 and AR2 exchange capability=20 > information.=20 > > This could be done using context transfer even ...=20 > >=20 >=20 > I think what is desired here is a way to take IP level QoS into=20 > consideration when selecting the next access point and access=20 > router to=20 > move to. Today only power is taken into consideration, and=20 > that at Layer=20 > 2.=20 >=20 > jak=20 >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby =20 >=20 ------_=_NextPart_001_01C1DA9A.2C178162 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] Examples of CAR discovery
SIR: For SIR to be a useful inter-networking, inter-technology, handover parameter, we would have to standardize not only
the parameter, but the method for measuring SIR, would we not? This would also be true for BER? Latency (for an example of
the latter I refer to the debates over the EF RFC in Diff Serv).
 
Gary
-----Original Message-----
From: Hakan.N.Persson@telia.se [mailto:Hakan.N.Persson@telia.se]
Sent: April 2, 2002 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR discovery

Hi,  
 
Also, the L2 measures like signal to interference ratios (SIR) etc. can be used, possibly together with some other information like required SIR for a specific QoS requirement, to estimate how much "bandwidth" are available to use for new users with a specific QoS requirement. If there are more than one candidate AP/AR available then it is useful to choose the one that meet your QoS needs also from a load situation point of view and not only the radio situation. If not, then either the QoS will be too poor or you may loose the connection. This not an IP level choice but more a L2 choice even if there are more than one radio technology involved.
 
However an access router also need to have the required capacity to admit new users with specific QoS requirements and if a certain AR does not have the required capacity on IP level then the same problem will occur as above if the required QoS on e.g. IP-level cannot be fulfilled. Otherwise the assumption need to be that the AR capacity is always assumed to be dimensioned such that it could handle all expected traffic to/from the connected access points and the outgoing routes.
 
Regards,
Håkan Persson
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR discovery

Actually, the usual measures for handover for wireless networks are
very much QoS related. In noise limited systems (e.g. AMPS), the measure
used is Signal to Noise Ratio (SNR); in interference limited systems (e.g. CDMA)
the measure used is Carrier to Interference Ratio (CIR), where the interference
comes from primarly other MNs. There are also a number of wireless data systems
out there that use BER as a measure.

In all of these cases, the measure is used to determine whether there is a "better"
channel for communications. This is L2 QoS.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 2, 2002 11:44
> To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Examples of CAR discovery
>
>
> John,
>
> > > So it sounds to me like dynamic QoS negotiation for handover
> > > has fallen between the cracks of the WGs.
> >
> > Do we need full-blown dynamic QoS negotiation for handover?
> Originally
> > (meaning circa last spring, after the MicroMobility work was removed
> from
> > SeaMoby), part of the access router section work was to be a
> capabilities
> > exchange between ARs, or so I thought.  Thinking in terms of baby
> steps,
> > havning some mechanism which allows a basic mechanisms
> (which may end
> up
> > looking like context tranfer) would not be a bad thing.
> >
> > To express it more concretely, AR1 and AR2 exchange capability
> information.
> > This could be done using context transfer even ...
> >
>
> I think what is desired here is a way to take IP level QoS into
> consideration when selecting the next access point and access
> router to
> move to. Today only power is taken into consideration, and
> that at Layer
> 2.
>
>             jak
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DA9A.2C178162-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 18:57: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 SAA08834 for ; Tue, 2 Apr 2002 18:57: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 SAA25057; Tue, 2 Apr 2002 18:42: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 SAA25019 for ; Tue, 2 Apr 2002 18:42: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 SAA08170 for ; Tue, 2 Apr 2002 18:42: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 g32NfJI21790; Tue, 2 Apr 2002 15:41:19 -0800 (PST) Message-ID: <03f101c1da9f$aa0a46e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> <3CAA0B62.950347CE@iprg.nokia.com> <033201c1da92$5b99a1c0$7e6015ac@T23KEMPF> <3CAA30FD.F5D66424@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 15:39: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.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'm O.K. with your suggestion, except that if we don't have any > data, we can't show interoperability. We ought to pick out some > reasonable contexts just to show that the seamoby protocol > really works. I've never heard of any working group standardizing > a framework that didn't include some guts too. > I can think of cases where containers get standardized but their contents don't. SLP is a good example. It defines the protocol and a way to define services but does not define the services themselves. LDAP is another. But I appreciate your point about actually showing interoperability, and even some performance enhancing effect (since CT in particular is supposed to have a performance enhancing effect). > Having said that, even though I can go along, I still think it might > be better to do the work in seamoby. Otherwise, the process will > drag on a lot longer. Plus, I reckon that a lot of people in this > group will have some expertise with handovers, even if they are > not highly experienced in other QoS areas that are more related > to interdomain traffic engineering. > Sure, we would have to recharter, which would require the AD's consent. For now, I frankly think we have enough to do. As I said, since paging was moved out, we seem to have just the right number of people matched with just the right number of tasks. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 18:57: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 SAA08843 for ; Tue, 2 Apr 2002 18:57:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25722 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 18:57: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 SAA25057; Tue, 2 Apr 2002 18:42: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 SAA25019 for ; Tue, 2 Apr 2002 18:42: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 SAA08170 for ; Tue, 2 Apr 2002 18:42: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 g32NfJI21790; Tue, 2 Apr 2002 15:41:19 -0800 (PST) Message-ID: <03f101c1da9f$aa0a46e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <02b801c1da77$82a8f9c0$7e6015ac@T23KEMPF> <3CAA0B62.950347CE@iprg.nokia.com> <033201c1da92$5b99a1c0$7e6015ac@T23KEMPF> <3CAA30FD.F5D66424@iprg.nokia.com> Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 2 Apr 2002 15:39: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.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'm O.K. with your suggestion, except that if we don't have any > data, we can't show interoperability. We ought to pick out some > reasonable contexts just to show that the seamoby protocol > really works. I've never heard of any working group standardizing > a framework that didn't include some guts too. > I can think of cases where containers get standardized but their contents don't. SLP is a good example. It defines the protocol and a way to define services but does not define the services themselves. LDAP is another. But I appreciate your point about actually showing interoperability, and even some performance enhancing effect (since CT in particular is supposed to have a performance enhancing effect). > Having said that, even though I can go along, I still think it might > be better to do the work in seamoby. Otherwise, the process will > drag on a lot longer. Plus, I reckon that a lot of people in this > group will have some expertise with handovers, even if they are > not highly experienced in other QoS areas that are more related > to interdomain traffic engineering. > Sure, we would have to recharter, which would require the AD's consent. For now, I frankly think we have enough to do. As I said, since paging was moved out, we seem to have just the right number of people matched with just the right number of tasks. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 19:18: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 TAA09354 for ; Tue, 2 Apr 2002 19:18: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 TAA26622; Tue, 2 Apr 2002 19:07: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 TAA26593 for ; Tue, 2 Apr 2002 19:06:58 -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 TAA08998 for ; Tue, 2 Apr 2002 19:06:58 -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 QAA18152; Tue, 2 Apr 2002 16:06:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3306Ne19305; Tue, 2 Apr 2002 16:06:23 -0800 X-mProtect: <200204030006> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYqMAsa; Tue, 02 Apr 2002 16:06:21 PST Message-ID: <3CAA477E.CC53EB6@iprg.nokia.com> Date: Tue, 02 Apr 2002 16:06:22 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> <03a001c1da95$e63a3080$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 James Kempf wrote: > Rajeev, > > Let me number these to make it easier: > > 1) > IP handover: a process that enables a MN to acquire network layer > > _connectivity_ when it changes access routers, allowing it to send and > > receive > > IP packets. IP handover is a routing issue. > > > > 2) > CT: a process that facilitates continued offering of IP features, > > typically > > during terminal mobility. > > CT addresses performance of transport protocols assuming IP > > connectivity is available. It is a transport issue. > > 3) > CARD: a process that facilitates resolving the prospective link > > (identifier) > > with its prefix and assocaited capabilities. This comes out as > off-link ARP > > > > with extensions. > > 4) > TARS: a process that assists in selecting _a_ router from among > multiple > > candidates. > > > > For what it is worth.. I do feel strongly however that these be > treated as > > separate protocols. > > > > I agree with this position. I do see another position, however, and that > is that 3) and 4) are subsumed under 1). The reason I mention this is > because in order for the routing to get fixed up, there needs to be a > router. Actually, if a MN does not know which AR it is attaching to a priori, IP handover (per def 1 above) still works! Base MIP is a good example. So, without 3) and 4), you could still have IP handovers. With 3) and 4), the experience is presumably improved however. Since handover works with or without 3) and 4), and this includes failure scenarios when 3) and 4) are in place, I wonder about the additional benefit of 1) subsuming 3) and 4).. > The problem with subsuming 3) and 4) under 1) is that I believe > for intratechnology handovers 1) must be very fast while 3) and 4) are > likely to be slower. For intertechnology handover, or what I think > So, that's the applicability statement for 3) and 4). :-) > should more properly be called *wireless media selection* (and that > includes selecting a new router with different IP characterists on the > same media - please note Govind :-), the time scale is more leisurely. > Possibly yes. In any case, if the target link resolution is not fast enough, the protocol usefulness is likely going to be questioned. [Read: static configuration, especially for intra-tech handovers might suffice :-)]. Regards, -Rajeev > > 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 Apr 2 19:18: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 TAA09366 for ; Tue, 2 Apr 2002 19:18:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27911 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 19:18: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 TAA26622; Tue, 2 Apr 2002 19:07: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 TAA26593 for ; Tue, 2 Apr 2002 19:06:58 -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 TAA08998 for ; Tue, 2 Apr 2002 19:06:58 -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 QAA18152; Tue, 2 Apr 2002 16:06:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3306Ne19305; Tue, 2 Apr 2002 16:06:23 -0800 X-mProtect: <200204030006> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYqMAsa; Tue, 02 Apr 2002 16:06:21 PST Message-ID: <3CAA477E.CC53EB6@iprg.nokia.com> Date: Tue, 02 Apr 2002 16:06:22 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , "'Satish Jamadagni'" , Nakhjiri Madjid-MNAKHJI1 , "'Hemant Chaskar'" , seamoby@ietf.org Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> <03a001c1da95$e63a3080$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 James Kempf wrote: > Rajeev, > > Let me number these to make it easier: > > 1) > IP handover: a process that enables a MN to acquire network layer > > _connectivity_ when it changes access routers, allowing it to send and > > receive > > IP packets. IP handover is a routing issue. > > > > 2) > CT: a process that facilitates continued offering of IP features, > > typically > > during terminal mobility. > > CT addresses performance of transport protocols assuming IP > > connectivity is available. It is a transport issue. > > 3) > CARD: a process that facilitates resolving the prospective link > > (identifier) > > with its prefix and assocaited capabilities. This comes out as > off-link ARP > > > > with extensions. > > 4) > TARS: a process that assists in selecting _a_ router from among > multiple > > candidates. > > > > For what it is worth.. I do feel strongly however that these be > treated as > > separate protocols. > > > > I agree with this position. I do see another position, however, and that > is that 3) and 4) are subsumed under 1). The reason I mention this is > because in order for the routing to get fixed up, there needs to be a > router. Actually, if a MN does not know which AR it is attaching to a priori, IP handover (per def 1 above) still works! Base MIP is a good example. So, without 3) and 4), you could still have IP handovers. With 3) and 4), the experience is presumably improved however. Since handover works with or without 3) and 4), and this includes failure scenarios when 3) and 4) are in place, I wonder about the additional benefit of 1) subsuming 3) and 4).. > The problem with subsuming 3) and 4) under 1) is that I believe > for intratechnology handovers 1) must be very fast while 3) and 4) are > likely to be slower. For intertechnology handover, or what I think > So, that's the applicability statement for 3) and 4). :-) > should more properly be called *wireless media selection* (and that > includes selecting a new router with different IP characterists on the > same media - please note Govind :-), the time scale is more leisurely. > Possibly yes. In any case, if the target link resolution is not fast enough, the protocol usefulness is likely going to be questioned. [Read: static configuration, especially for intra-tech handovers might suffice :-)]. Regards, -Rajeev > > 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 Apr 2 20: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 UAA10993 for ; Tue, 2 Apr 2002 20:31: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 UAA01351; Tue, 2 Apr 2002 20:13: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 UAA01316 for ; Tue, 2 Apr 2002 20:13:03 -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 UAA10637 for ; Tue, 2 Apr 2002 20:13: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 RAA21373; Tue, 2 Apr 2002 17:09:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3319Bj27387; Tue, 2 Apr 2002 17:09:11 -0800 X-mProtect: <200204030109> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4i4D2c; Tue, 02 Apr 2002 17:09:09 PST Message-ID: <3CAA563B.B394ED79@iprg.nokia.com> Date: Tue, 02 Apr 2002 17:09:15 -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: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> <03a001c1da95$e63a3080$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: > The problem with subsuming 3) and 4) under 1) is that I believe > for intratechnology handovers 1) must be very fast while 3) and 4) are > likely to be slower. For intertechnology handover, or what I think > should more properly be called *wireless media selection* (and that > includes selecting a new router with different IP characterists on the > same media - please note Govind :-), the time scale is more leisurely. Well, I don't see this. The target router could well be determined by current conditions (load, bandwidth availability, etc.) and that does not necessarily depend on the "type" of the technology. The protocol may well be used to identify a new access router on a different wireless medium that has roughly the same speed. With several variations of 802.11 and Bluetooth and UMTS and 3G coming, this is very likely. I am not very comfortable with the term "IP characteristics", since IP pretty much has the same characteristics no matter what the physical medium happens to be. We know the minimum packet size, for instance. IP itself doesn't have any delay or speed (for example) characteristics. The problem you refer to as "wireless media selection" should not be the focus of the discussion, because we don't want to select a medium. We want to select a point of attachment to the Internet. The medium is _not_ the message. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 2 20:31: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 UAA11001 for ; Tue, 2 Apr 2002 20:31:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA02518 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 20: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 UAA01351; Tue, 2 Apr 2002 20:13: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 UAA01316 for ; Tue, 2 Apr 2002 20:13:03 -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 UAA10637 for ; Tue, 2 Apr 2002 20:13: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 RAA21373; Tue, 2 Apr 2002 17:09:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3319Bj27387; Tue, 2 Apr 2002 17:09:11 -0800 X-mProtect: <200204030109> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4i4D2c; Tue, 02 Apr 2002 17:09:09 PST Message-ID: <3CAA563B.B394ED79@iprg.nokia.com> Date: Tue, 02 Apr 2002 17:09:15 -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: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> <03a001c1da95$e63a3080$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: > The problem with subsuming 3) and 4) under 1) is that I believe > for intratechnology handovers 1) must be very fast while 3) and 4) are > likely to be slower. For intertechnology handover, or what I think > should more properly be called *wireless media selection* (and that > includes selecting a new router with different IP characterists on the > same media - please note Govind :-), the time scale is more leisurely. Well, I don't see this. The target router could well be determined by current conditions (load, bandwidth availability, etc.) and that does not necessarily depend on the "type" of the technology. The protocol may well be used to identify a new access router on a different wireless medium that has roughly the same speed. With several variations of 802.11 and Bluetooth and UMTS and 3G coming, this is very likely. I am not very comfortable with the term "IP characteristics", since IP pretty much has the same characteristics no matter what the physical medium happens to be. We know the minimum packet size, for instance. IP itself doesn't have any delay or speed (for example) characteristics. The problem you refer to as "wireless media selection" should not be the focus of the discussion, because we don't want to select a medium. We want to select a point of attachment to the Internet. The medium is _not_ the message. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 2 22:07: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 WAA12966 for ; Tue, 2 Apr 2002 22:07: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 VAA06074; Tue, 2 Apr 2002 21: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 VAA06046 for ; Tue, 2 Apr 2002 21:50:44 -0500 (EST) Received: from hotmail.com (f159.law9.hotmail.com [64.4.9.159]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12797 for ; Tue, 2 Apr 2002 21:50:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Apr 2002 18:50:14 -0800 Received: from 63.214.113.193 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 03 Apr 2002 02:50:13 GMT X-Originating-IP: [63.214.113.193] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, henrik@levkowetz.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 02 Apr 2002 21:50:13 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Apr 2002 02:50:14.0014 (UTC) FILETIME=[476C59E0:01C1DABA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, Just one comment. >Henrik, > > > > I'm not 100% sure what you mean below, but I do believe that > > parameters such as available bandwidth and link latency are highly > > relevant to especially inter-technology CAR discovery. > > > >My comment was intended to address just the notion of a QoS object and >its contents. I do not think that these are currently part of Seamoby's >charter, thus, I do not think the right people would be involved in the >WG to address standardizing them. > >With respect to available bandwidth and link latency, these sound like >particular CAR capabilities. My reading of the current charter is that >we will not be actually standardizing on particular capabilities, just >on how to transfer them, similarly to how we will not be standardizing >on particular CT feature contexts, just how to carry them for CT. > >Of course, in both cases, we need to specify the process by which >capabilities and feature contexts are standardized (IANA, IETF standards >action, special expert review, etc.) [Govind] IMHO it is very important to decide the capabilities and the size of their representation. We should take a look at some "important" and "likely" capabilities. This is because, unlike CT which happens over the wired network, we may have to transmit the capabilities to the MN. A lot of discussion happened last week regarding whether the transmission of capabilities to the MN will not be a burden on the MN both w.r.t power as well as bandwidth. If we are to go with that assumption we should at least be sure that this is the case. We may also want to look at which capabilities are updated periodically and which aren't. I know it might be impossible to list all the capabilities, as this may change over time but I think it will be good if look at the minimum capabilities that will be transmitted and their formats. 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@ns.ietf.org Tue Apr 2 22:07: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 WAA12979 for ; Tue, 2 Apr 2002 22:07:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA07112 for seamoby-archive@odin.ietf.org; Tue, 2 Apr 2002 22:07: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 VAA06074; Tue, 2 Apr 2002 21: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 VAA06046 for ; Tue, 2 Apr 2002 21:50:44 -0500 (EST) Received: from hotmail.com (f159.law9.hotmail.com [64.4.9.159]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12797 for ; Tue, 2 Apr 2002 21:50:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Apr 2002 18:50:14 -0800 Received: from 63.214.113.193 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 03 Apr 2002 02:50:13 GMT X-Originating-IP: [63.214.113.193] From: "Govind Krishnamurthi" To: kempf@docomolabs-usa.com, henrik@levkowetz.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery Date: Tue, 02 Apr 2002 21:50:13 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Apr 2002 02:50:14.0014 (UTC) FILETIME=[476C59E0:01C1DABA] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, Just one comment. >Henrik, > > > > I'm not 100% sure what you mean below, but I do believe that > > parameters such as available bandwidth and link latency are highly > > relevant to especially inter-technology CAR discovery. > > > >My comment was intended to address just the notion of a QoS object and >its contents. I do not think that these are currently part of Seamoby's >charter, thus, I do not think the right people would be involved in the >WG to address standardizing them. > >With respect to available bandwidth and link latency, these sound like >particular CAR capabilities. My reading of the current charter is that >we will not be actually standardizing on particular capabilities, just >on how to transfer them, similarly to how we will not be standardizing >on particular CT feature contexts, just how to carry them for CT. > >Of course, in both cases, we need to specify the process by which >capabilities and feature contexts are standardized (IANA, IETF standards >action, special expert review, etc.) [Govind] IMHO it is very important to decide the capabilities and the size of their representation. We should take a look at some "important" and "likely" capabilities. This is because, unlike CT which happens over the wired network, we may have to transmit the capabilities to the MN. A lot of discussion happened last week regarding whether the transmission of capabilities to the MN will not be a burden on the MN both w.r.t power as well as bandwidth. If we are to go with that assumption we should at least be sure that this is the case. We may also want to look at which capabilities are updated periodically and which aren't. I know it might be impossible to list all the capabilities, as this may change over time but I think it will be good if look at the minimum capabilities that will be transmitted and their formats. 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 Apr 3 01: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 BAA17423 for ; Wed, 3 Apr 2002 01: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 BAA26273; Wed, 3 Apr 2002 01:20: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 BAA26242 for ; Wed, 3 Apr 2002 01:20:44 -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 BAA17277 for ; Wed, 3 Apr 2002 01:20:41 -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 g336Jqu27718 for ; Wed, 3 Apr 2002 09:19:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 09:20:40 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:20:39 +0300 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: Wed, 3 Apr 2002 09:20:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7F@esebe004.NOE.Nokia.com> Thread-Topic: NSIS was:Examples of CAR discovery Thread-Index: AcHaZartKqrWf/C6T8iUzE5bUtxg6QAcYOgw To: Cc: X-OriginalArrivalTime: 03 Apr 2002 06:20:40.0034 (UTC) FILETIME=[AD1E1C20:01C1DAD7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA26243 Subject: [Seamoby] RE: NSIS 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: 8bit Hi James, > > What NSIS will be working on is a generalized framework, to enable > > end to edge signaling, end to end signaling and perhaps edge to edge > > signaling. > > > > For the end-to-edge signaling, the access network (maybe even the > > access router) would/could be proxying QoS for network towards the > > end node. > > > > So it sounds to me the only issue is that NSIS would look at > prehandoff or posthandoff end to edge (host to network?) signaling > rather than at the time of handoff, is that right? I'm not sure what you mean. I will say it another way. NSIS would not like to re-negotiate QoS after each handoff. If Seamoby could do some work with CARD (pre-handoff) and CT (during & post-handoff) that would make renogotiation less needed, that would be great. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 01:35: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 BAA17440 for ; Wed, 3 Apr 2002 01:35:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27320 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 01: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 BAA26273; Wed, 3 Apr 2002 01:20: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 BAA26242 for ; Wed, 3 Apr 2002 01:20:44 -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 BAA17277 for ; Wed, 3 Apr 2002 01:20:41 -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 g336Jqu27718 for ; Wed, 3 Apr 2002 09:19:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 09:20:40 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:20:39 +0300 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: Wed, 3 Apr 2002 09:20:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7F@esebe004.NOE.Nokia.com> Thread-Topic: NSIS was:Examples of CAR discovery Thread-Index: AcHaZartKqrWf/C6T8iUzE5bUtxg6QAcYOgw To: Cc: X-OriginalArrivalTime: 03 Apr 2002 06:20:40.0034 (UTC) FILETIME=[AD1E1C20:01C1DAD7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA26243 Subject: [Seamoby] RE: NSIS 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: 8bit Hi James, > > What NSIS will be working on is a generalized framework, to enable > > end to edge signaling, end to end signaling and perhaps edge to edge > > signaling. > > > > For the end-to-edge signaling, the access network (maybe even the > > access router) would/could be proxying QoS for network towards the > > end node. > > > > So it sounds to me the only issue is that NSIS would look at > prehandoff or posthandoff end to edge (host to network?) signaling > rather than at the time of handoff, is that right? I'm not sure what you mean. I will say it another way. NSIS would not like to re-negotiate QoS after each handoff. If Seamoby could do some work with CARD (pre-handoff) and CT (during & post-handoff) that would make renogotiation less needed, that would be great. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 01: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 BAA17485 for ; Wed, 3 Apr 2002 01: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 BAA26390; Wed, 3 Apr 2002 01: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 BAA26357 for ; Wed, 3 Apr 2002 01:23:26 -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 BAA17295 for ; Wed, 3 Apr 2002 01:23:22 -0500 (EST) From: john.loughney@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 g336Nd501590 for ; Wed, 3 Apr 2002 09:23:40 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 09:23:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:23:24 +0300 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: Wed, 3 Apr 2002 09:23:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D75@esebe004.NOE.Nokia.com> Thread-Topic: NSIS was:Examples of CAR discovery Thread-Index: AcHaaHSDPKUocrz3QwWZu/w4AQomIwAb0zdw To: Cc: X-OriginalArrivalTime: 03 Apr 2002 06:23:24.0308 (UTC) FILETIME=[0F085540:01C1DAD8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA26358 Subject: [Seamoby] RE: NSIS (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: 8bit Hi James, > My concern here is that the right people may not be involved > in Seamoby to adequately address this issue. > People with QoS expertiese would not necessarily come to Seamoby. I'm not sure that such people are needed yet. What we should do is create some technologies that can be applied for QoS (and security, etc). QoS experts then should be consulted on how CARD, CT are used for QoS. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 01:37: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 BAA17502 for ; Wed, 3 Apr 2002 01:37:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27446 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 01: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 BAA26390; Wed, 3 Apr 2002 01: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 BAA26357 for ; Wed, 3 Apr 2002 01:23:26 -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 BAA17295 for ; Wed, 3 Apr 2002 01:23:22 -0500 (EST) From: john.loughney@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 g336Nd501590 for ; Wed, 3 Apr 2002 09:23:40 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 09:23:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:23:24 +0300 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: Wed, 3 Apr 2002 09:23:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D75@esebe004.NOE.Nokia.com> Thread-Topic: NSIS was:Examples of CAR discovery Thread-Index: AcHaaHSDPKUocrz3QwWZu/w4AQomIwAb0zdw To: Cc: X-OriginalArrivalTime: 03 Apr 2002 06:23:24.0308 (UTC) FILETIME=[0F085540:01C1DAD8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA26358 Subject: [Seamoby] RE: NSIS (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: 8bit Hi James, > My concern here is that the right people may not be involved > in Seamoby to adequately address this issue. > People with QoS expertiese would not necessarily come to Seamoby. I'm not sure that such people are needed yet. What we should do is create some technologies that can be applied for QoS (and security, etc). QoS experts then should be consulted on how CARD, CT are used for QoS. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 01:51: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 BAA17704 for ; Wed, 3 Apr 2002 01:51: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 BAA27112; Wed, 3 Apr 2002 01:31: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 BAA27081 for ; Wed, 3 Apr 2002 01:31: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 BAA17390 for ; Wed, 3 Apr 2002 01:31:33 -0500 (EST) From: john.loughney@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 g336Vo506715 for ; Wed, 3 Apr 2002 09:31:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 09:31:34 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:31:34 +0300 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: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Wed, 3 Apr 2002 09:31:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D80@esebe004.NOE.Nokia.com> Thread-Topic: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Thread-Index: AcHaaiH3jzHTvc5/Q82UQwT9wv8oNgAbfKDw To: , , , , , X-OriginalArrivalTime: 03 Apr 2002 06:31:34.0457 (UTC) FILETIME=[332F2290:01C1DAD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA27082 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, Maybe I'm a bit slow, but I would like to simply my answer to this question. Handoff is automating the process of re-plugging into the network, at a different access point. When plugging into the new access point, we want to minimize the disruption (use CT to transfer QoS, Security, AAA, etc. state) so that we can continue to do whatever we were doing. When we are selecting the new 'ethernet jack' to plug into, we want to make sure that if there are multple jacks, we pick the one that matches our current jack. (I'm sure we have had the situation where we fold up our laptop, go to a meeting room, plug in our ethernet cable & find we have to reset our IP configurations and even reinitize some of our applications.) Of course, in my analogy, I used a single layer 2 - ethernet. We all know (or at least suspect) that the future probably holds a number of different layer 2's & that devices may sport a wide variety of interfaces. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 02 April, 2002 20:14 > To: Gary Kenward; 'Satish Jamadagni'; Nakhjiri > Madjid-MNAKHJI1; 'Hemant > Chaskar'; seamoby@ietf.org > Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR > discovery) > > > Gary/All, > > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what > the mobile > node and its user need, > > 2) A link/routing failure that needs to be fixed up as quickly as > possible. > > 3) Both of the above. > > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. > > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. > > Comments? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 01:51: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 BAA17713 for ; Wed, 3 Apr 2002 01:51:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28066 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 01:51: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 BAA27112; Wed, 3 Apr 2002 01:31: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 BAA27081 for ; Wed, 3 Apr 2002 01:31: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 BAA17390 for ; Wed, 3 Apr 2002 01:31:33 -0500 (EST) From: john.loughney@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 g336Vo506715 for ; Wed, 3 Apr 2002 09:31:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 09:31:34 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:31:34 +0300 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: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Wed, 3 Apr 2002 09:31:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D80@esebe004.NOE.Nokia.com> Thread-Topic: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Thread-Index: AcHaaiH3jzHTvc5/Q82UQwT9wv8oNgAbfKDw To: , , , , , X-OriginalArrivalTime: 03 Apr 2002 06:31:34.0457 (UTC) FILETIME=[332F2290:01C1DAD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA27082 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, Maybe I'm a bit slow, but I would like to simply my answer to this question. Handoff is automating the process of re-plugging into the network, at a different access point. When plugging into the new access point, we want to minimize the disruption (use CT to transfer QoS, Security, AAA, etc. state) so that we can continue to do whatever we were doing. When we are selecting the new 'ethernet jack' to plug into, we want to make sure that if there are multple jacks, we pick the one that matches our current jack. (I'm sure we have had the situation where we fold up our laptop, go to a meeting room, plug in our ethernet cable & find we have to reset our IP configurations and even reinitize some of our applications.) Of course, in my analogy, I used a single layer 2 - ethernet. We all know (or at least suspect) that the future probably holds a number of different layer 2's & that devices may sport a wide variety of interfaces. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 02 April, 2002 20:14 > To: Gary Kenward; 'Satish Jamadagni'; Nakhjiri > Madjid-MNAKHJI1; 'Hemant > Chaskar'; seamoby@ietf.org > Subject: What is Handover? (was: Re: [Seamoby] Examples of CAR > discovery) > > > Gary/All, > > So I think what it comes down to is this. Is handover: > > 1) An opportunity for the mobile node to express its preferences for a > new access router with characteristics that better match what > the mobile > node and its user need, > > 2) A link/routing failure that needs to be fixed up as quickly as > possible. > > 3) Both of the above. > > Most of the discussion/disagreement/confusion (including my own) I've > seen on this list seems to revolve around this question. > > My opinion: > > For intratechnology, Door Number 2. > > For intertechnology, Door Number 1. > > Comments? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 01:53: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 BAA17762 for ; Wed, 3 Apr 2002 01:53: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 BAA27361; Wed, 3 Apr 2002 01:35: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 BAA27332 for ; Wed, 3 Apr 2002 01:35:41 -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 BAA17434 for ; Wed, 3 Apr 2002 01:35:37 -0500 (EST) From: john.loughney@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 g336Zs509309 for ; Wed, 3 Apr 2002 09:35:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 3 Apr 2002 09:35:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:35:39 +0300 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, 3 Apr 2002 09:35:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D77@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHaWgp3cSovnXMlRQKt+84Qt3DpswAf0hig To: X-OriginalArrivalTime: 03 Apr 2002 06:35:39.0021 (UTC) FILETIME=[C4F4A3D0:01C1DAD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA27333 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, Catching up on some mails: > 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. I'd disagree on 3.4 & 3.x. What I think we want is the CARD protocol to be ABLE to the able requirements, I don't think we want to mandate the behavior. My preference would be: 3.4 The CAR discovery protocol MUST be able to provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST be able to make efficient use of the network resources and SHOULD avoid the transmission of unnecessary information. I strongly think that requirements in the IETF should not get into dictating protocol behavior, but be more involved in the capabilities of protocols. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 01:53: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 BAA17771 for ; Wed, 3 Apr 2002 01:53:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28144 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 01:53: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 BAA27361; Wed, 3 Apr 2002 01:35: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 BAA27332 for ; Wed, 3 Apr 2002 01:35:41 -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 BAA17434 for ; Wed, 3 Apr 2002 01:35:37 -0500 (EST) From: john.loughney@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 g336Zs509309 for ; Wed, 3 Apr 2002 09:35:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 3 Apr 2002 09:35:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 09:35:39 +0300 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, 3 Apr 2002 09:35:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D77@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Thread-Index: AcHaWgp3cSovnXMlRQKt+84Qt3DpswAf0hig To: X-OriginalArrivalTime: 03 Apr 2002 06:35:39.0021 (UTC) FILETIME=[C4F4A3D0:01C1DAD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA27333 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, Catching up on some mails: > 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. I'd disagree on 3.4 & 3.x. What I think we want is the CARD protocol to be ABLE to the able requirements, I don't think we want to mandate the behavior. My preference would be: 3.4 The CAR discovery protocol MUST be able to provide the MN with GAAR information along with capabilities. 3.x The CAR discovery protocol MUST be able to make efficient use of the network resources and SHOULD avoid the transmission of unnecessary information. I strongly think that requirements in the IETF should not get into dictating protocol behavior, but be more involved in the capabilities of protocols. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 08: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 IAA02897 for ; Wed, 3 Apr 2002 08:42: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 IAA23251; Wed, 3 Apr 2002 08:25: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 IAA23182 for ; Wed, 3 Apr 2002 08:24:59 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02506 for ; Wed, 3 Apr 2002 08:24:55 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g33DPWL03649; Wed, 3 Apr 2002 15:25:32 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id D1B73C051; Wed, 3 Apr 2002 15:23:49 +0200 (CEST) Date: Wed, 03 Apr 2002 15:37:59 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery Message-ID: <20253112.1017848279@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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 Tuesday, April 02, 2002 11:12 AM +0300 john.loughney@nokia.com wrote: [...] > I think that NSIS and SeaMoby / Context Transfer may interwork to provide > a good solution, in my opinion. I agree that CT might help for a good solution. However, for the QoS part, it is not only about a CT from one acess to anouther, but also about the rest of the path providing guarantees involved, where (as far as I understood the CT work) context transfer itself does not help too much. > NSIS most likely will be using a 'on path' signaling model, where the > QoS signaling takes the same path as the data. I don't think we have this aggreement in the NSIS group. Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 08: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 IAA02907 for ; Wed, 3 Apr 2002 08:42:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA24352 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 08: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 IAA23251; Wed, 3 Apr 2002 08:25: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 IAA23182 for ; Wed, 3 Apr 2002 08:24:59 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02506 for ; Wed, 3 Apr 2002 08:24:55 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g33DPWL03649; Wed, 3 Apr 2002 15:25:32 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id D1B73C051; Wed, 3 Apr 2002 15:23:49 +0200 (CEST) Date: Wed, 03 Apr 2002 15:37:59 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery Message-ID: <20253112.1017848279@[192.168.102.79]> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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 Tuesday, April 02, 2002 11:12 AM +0300 john.loughney@nokia.com wrote: [...] > I think that NSIS and SeaMoby / Context Transfer may interwork to provide > a good solution, in my opinion. I agree that CT might help for a good solution. However, for the QoS part, it is not only about a CT from one acess to anouther, but also about the rest of the path providing guarantees involved, where (as far as I understood the CT work) context transfer itself does not help too much. > NSIS most likely will be using a 'on path' signaling model, where the > QoS signaling takes the same path as the data. I don't think we have this aggreement in the NSIS group. Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 10:06: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 KAA05243 for ; Wed, 3 Apr 2002 10:06: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 JAA27953; Wed, 3 Apr 2002 09: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 JAA27926 for ; Wed, 3 Apr 2002 09:37:41 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04432 for ; Wed, 3 Apr 2002 09:37:39 -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 g33Eb2i20271; Wed, 3 Apr 2002 09:37:02 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 09:37:03 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4994@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , kempf@docomolabs-usa.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 09:37:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB1D.077EA780" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB1D.077EA780 Content-Type: text/plain; charset="iso-8859-1" John, et al: As far as I am concerned, we worked hard on defining CT requirements to be "proactive": that is, happening "before" a handoff. Has CAR now supplanted this capability in everyones mind? If so, then I think the main value of CT has been lost. Here's an observation for everyone to consider: in the manner that CAR (and TARS) is being talked about, there is an implication that the mobile will have a choice of channels to handover to. These channels are to be differentiated by the services and QoS that they provide. It is hard, at this point, to see that this will be the norm for near future. Yes, if 802.11 is used for "hot spot coverage", there will very likely be overlap with cellular channels, but the need to make a choice for one over the other (if based upon QoS parameters like bandwidth, then the choice will almost always be 802.11), will be rare. On the other hand, if there is *any* opportunity to handover, then CT can be employed to improve the handover. In short, CT has a wider applicability and benefit to improving handover performance, whereas, CAR has a limited applicability, particularly in the short term. Cheers, Gary PS: I think it that everyone should be concerned that the definition of CAR is being massaged into a being a replacement for the proposal to perform CT from MN to access network - a concept that the working group did not favour, for many good, technical, reasons. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 01:21 > To: kempf@docomolabs-usa.com > Cc: seamoby@ietf.org > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Hi James, > > > What NSIS will be working on is a generalized framework, to enable > > > end to edge signaling, end to end signaling and perhaps > edge to edge > > > signaling. > > > > > > For the end-to-edge signaling, the access network (maybe even the > > > access router) would/could be proxying QoS for network > towards the > > > end node. > > > > > > > So it sounds to me the only issue is that NSIS would look at > > prehandoff or posthandoff end to edge (host to network?) signaling > > rather than at the time of handoff, is that right? > > I'm not sure what you mean. I will say it another way. NSIS would > not like to re-negotiate QoS after each handoff. If Seamoby could > do some work with CARD (pre-handoff) and CT (during & post-handoff) > that would make renogotiation less needed, that would be great. > > John > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DB1D.077EA780 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

John, et al:

As far as I am concerned, we worked hard on defining CT requirements to be "proactive":
that is, happening "before" a handoff. Has CAR now supplanted this capability in
everyones mind? If so, then I think the main value of CT has been lost.

Here's an observation for everyone to consider: in the manner that CAR (and TARS) is
being talked about, there is an implication that the mobile will have a choice of
channels to handover to. These channels are to be differentiated by the services and
QoS that they provide. It is hard, at this point, to see that this will be the norm
for near future. Yes, if 802.11 is used for "hot spot coverage", there will very likely
be overlap with cellular channels, but the need to make a choice for one over the other
(if based upon QoS parameters like bandwidth, then the choice will almost always be
802.11), will be rare.

On the other hand, if there is *any* opportunity to handover, then CT can be employed
to improve the handover.

In short, CT has a wider applicability and benefit to improving handover performance, whereas,
CAR has a limited applicability, particularly in the short term.

Cheers,
Gary

PS: I think it that everyone should be concerned that the definition of CAR is being massaged
into a being a replacement for the proposal to perform CT from MN to access network - a concept
that the working group did not favour, for many good, technical, reasons.

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 01:21
> To: kempf@docomolabs-usa.com
> Cc: seamoby@ietf.org
> Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Hi James,
> > > What NSIS will be working on is a generalized framework, to enable
> > > end to edge signaling, end to end signaling and perhaps
> edge to edge
> > > signaling.
> > >
> > > For the end-to-edge signaling, the access network (maybe even the
> > > access router) would/could be proxying QoS for network
> towards the
> > > end node.
> > >
> >
> > So it sounds to me the only issue is that NSIS would look at
> > prehandoff or posthandoff end to edge (host to network?) signaling
> > rather than at the time of handoff, is that right?
>
> I'm not sure what you mean.  I will say it another way.  NSIS would
> not like to re-negotiate QoS after each handoff.  If Seamoby could
> do some work with CARD (pre-handoff) and CT (during & post-handoff)
> that would make renogotiation less needed, that would be great.
>
> John
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DB1D.077EA780-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 10:06: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 KAA05257 for ; Wed, 3 Apr 2002 10:06:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00025 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 10:06: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 JAA27953; Wed, 3 Apr 2002 09: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 JAA27926 for ; Wed, 3 Apr 2002 09:37:41 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04432 for ; Wed, 3 Apr 2002 09:37:39 -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 g33Eb2i20271; Wed, 3 Apr 2002 09:37:02 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 09:37:03 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4994@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , kempf@docomolabs-usa.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 09:37:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB1D.077EA780" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB1D.077EA780 Content-Type: text/plain; charset="iso-8859-1" John, et al: As far as I am concerned, we worked hard on defining CT requirements to be "proactive": that is, happening "before" a handoff. Has CAR now supplanted this capability in everyones mind? If so, then I think the main value of CT has been lost. Here's an observation for everyone to consider: in the manner that CAR (and TARS) is being talked about, there is an implication that the mobile will have a choice of channels to handover to. These channels are to be differentiated by the services and QoS that they provide. It is hard, at this point, to see that this will be the norm for near future. Yes, if 802.11 is used for "hot spot coverage", there will very likely be overlap with cellular channels, but the need to make a choice for one over the other (if based upon QoS parameters like bandwidth, then the choice will almost always be 802.11), will be rare. On the other hand, if there is *any* opportunity to handover, then CT can be employed to improve the handover. In short, CT has a wider applicability and benefit to improving handover performance, whereas, CAR has a limited applicability, particularly in the short term. Cheers, Gary PS: I think it that everyone should be concerned that the definition of CAR is being massaged into a being a replacement for the proposal to perform CT from MN to access network - a concept that the working group did not favour, for many good, technical, reasons. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 01:21 > To: kempf@docomolabs-usa.com > Cc: seamoby@ietf.org > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Hi James, > > > What NSIS will be working on is a generalized framework, to enable > > > end to edge signaling, end to end signaling and perhaps > edge to edge > > > signaling. > > > > > > For the end-to-edge signaling, the access network (maybe even the > > > access router) would/could be proxying QoS for network > towards the > > > end node. > > > > > > > So it sounds to me the only issue is that NSIS would look at > > prehandoff or posthandoff end to edge (host to network?) signaling > > rather than at the time of handoff, is that right? > > I'm not sure what you mean. I will say it another way. NSIS would > not like to re-negotiate QoS after each handoff. If Seamoby could > do some work with CARD (pre-handoff) and CT (during & post-handoff) > that would make renogotiation less needed, that would be great. > > John > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DB1D.077EA780 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

John, et al:

As far as I am concerned, we worked hard on defining CT requirements to be "proactive":
that is, happening "before" a handoff. Has CAR now supplanted this capability in
everyones mind? If so, then I think the main value of CT has been lost.

Here's an observation for everyone to consider: in the manner that CAR (and TARS) is
being talked about, there is an implication that the mobile will have a choice of
channels to handover to. These channels are to be differentiated by the services and
QoS that they provide. It is hard, at this point, to see that this will be the norm
for near future. Yes, if 802.11 is used for "hot spot coverage", there will very likely
be overlap with cellular channels, but the need to make a choice for one over the other
(if based upon QoS parameters like bandwidth, then the choice will almost always be
802.11), will be rare.

On the other hand, if there is *any* opportunity to handover, then CT can be employed
to improve the handover.

In short, CT has a wider applicability and benefit to improving handover performance, whereas,
CAR has a limited applicability, particularly in the short term.

Cheers,
Gary

PS: I think it that everyone should be concerned that the definition of CAR is being massaged
into a being a replacement for the proposal to perform CT from MN to access network - a concept
that the working group did not favour, for many good, technical, reasons.

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 01:21
> To: kempf@docomolabs-usa.com
> Cc: seamoby@ietf.org
> Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Hi James,
> > > What NSIS will be working on is a generalized framework, to enable
> > > end to edge signaling, end to end signaling and perhaps
> edge to edge
> > > signaling.
> > >
> > > For the end-to-edge signaling, the access network (maybe even the
> > > access router) would/could be proxying QoS for network
> towards the
> > > end node.
> > >
> >
> > So it sounds to me the only issue is that NSIS would look at
> > prehandoff or posthandoff end to edge (host to network?) signaling
> > rather than at the time of handoff, is that right?
>
> I'm not sure what you mean.  I will say it another way.  NSIS would
> not like to re-negotiate QoS after each handoff.  If Seamoby could
> do some work with CARD (pre-handoff) and CT (during & post-handoff)
> that would make renogotiation less needed, that would be great.
>
> John
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DB1D.077EA780-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 10:17: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 KAA05619 for ; Wed, 3 Apr 2002 10:17: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 JAA28485; Wed, 3 Apr 2002 09:49: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 JAA28458 for ; Wed, 3 Apr 2002 09:49:50 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04698 for ; Wed, 3 Apr 2002 09:49:47 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33EnIi22080; Wed, 3 Apr 2002 09:49:18 -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 g33EnG500930; Wed, 3 Apr 2002 09:49:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 09:49:17 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4995@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 09:49:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB1E.BCC28FB6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB1E.BCC28FB6 Content-Type: text/plain; charset="iso-8859-1" Marcus: I agree with your point about PATH QoS entirely. This is one of the issues I have with the idea that QoS "discovery" by the MN is a problematical approach. CT, as a concept, is NOT restricted to the access edge routers. It could be used anywhere along the path. There are issues to be resolved with this model, and the real nature of CT is currently academic until (and if) we start discussing actual solutions. The alternative is to use signalling to set up a new path with the necessary resources. To do this during or after handover would clearly add to the handover delay. To complete the QoS path set up prior to the handover, along potential handover paths, could consume significant resources that would not necessarly be used. There are approaches to minimizing this resource consumption, but they require different approaches to the problem then taken in the past. There is an analogy here with RSVP. Gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: April 3, 2002 08:38 > To: john.loughney@nokia.com; kempf@docomolabs-usa.com; > charliep@iprg.nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > > --On Tuesday, April 02, 2002 11:12 AM +0300 > john.loughney@nokia.com wrote: > > [...] > > > I think that NSIS and SeaMoby / Context Transfer may > interwork to provide > > a good solution, in my opinion. > > I agree that CT might help for a good solution. However, for > the QoS part, > it is not only about a CT from one acess to anouther, but > also about the > rest of the path providing guarantees involved, where (as far as I > understood the CT work) context transfer itself does not help > too much. > > > NSIS most likely will be using a 'on path' signaling model, > where the > > QoS signaling takes the same path as the data. > > I don't think we have this aggreement in the NSIS group. > > > Marcus > > -------------------------------------- > Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DB1E.BCC28FB6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

Marcus:

  I agree with your point about PATH QoS entirely. This is one of
the issues I have with the idea that QoS "discovery" by the MN is
a problematical approach.

  CT, as a concept, is NOT restricted to the access edge routers.
It could be used anywhere along the path. There are issues to be
resolved with this model, and the real nature of CT is currently
academic until (and if) we start discussing actual solutions.

  The alternative is to use signalling to set up a new path with the
necessary resources. To do this during or after handover would clearly
add to the handover delay.

  To complete the QoS path set up prior to the handover, along potential
handover paths, could consume significant resources that would not
necessarly be used. There are approaches to minimizing this resource
consumption, but they require different approaches to the problem then
taken in the past. There is an analogy here with RSVP.

Gary


> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: April 3, 2002 08:38
> To: john.loughney@nokia.com; kempf@docomolabs-usa.com;
> charliep@iprg.nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery
>
>
>
>
> --On Tuesday, April 02, 2002 11:12 AM +0300
> john.loughney@nokia.com wrote:
>
> [...]
>
> > I think that NSIS and SeaMoby / Context Transfer may
> interwork to provide
> > a good solution, in my opinion.
>
> I agree that CT might help for a good solution. However, for
> the QoS part,
> it is not only about a CT from one acess to anouther, but
> also about the
> rest of the path providing guarantees involved, where (as far as I
> understood the CT work) context transfer itself does not help
> too much.
>
> > NSIS most likely will be using a 'on path' signaling model,
> where the
> > QoS signaling takes the same path as the data.
>
> I don't think we have this aggreement in the NSIS group.
>
>
> Marcus
>
> --------------------------------------
> Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DB1E.BCC28FB6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 10:17: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 KAA05633 for ; Wed, 3 Apr 2002 10:17:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00721 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 10:17: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 JAA28485; Wed, 3 Apr 2002 09:49: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 JAA28458 for ; Wed, 3 Apr 2002 09:49:50 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04698 for ; Wed, 3 Apr 2002 09:49:47 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33EnIi22080; Wed, 3 Apr 2002 09:49:18 -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 g33EnG500930; Wed, 3 Apr 2002 09:49:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 09:49:17 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4995@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 09:49:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB1E.BCC28FB6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB1E.BCC28FB6 Content-Type: text/plain; charset="iso-8859-1" Marcus: I agree with your point about PATH QoS entirely. This is one of the issues I have with the idea that QoS "discovery" by the MN is a problematical approach. CT, as a concept, is NOT restricted to the access edge routers. It could be used anywhere along the path. There are issues to be resolved with this model, and the real nature of CT is currently academic until (and if) we start discussing actual solutions. The alternative is to use signalling to set up a new path with the necessary resources. To do this during or after handover would clearly add to the handover delay. To complete the QoS path set up prior to the handover, along potential handover paths, could consume significant resources that would not necessarly be used. There are approaches to minimizing this resource consumption, but they require different approaches to the problem then taken in the past. There is an analogy here with RSVP. Gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: April 3, 2002 08:38 > To: john.loughney@nokia.com; kempf@docomolabs-usa.com; > charliep@iprg.nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > > --On Tuesday, April 02, 2002 11:12 AM +0300 > john.loughney@nokia.com wrote: > > [...] > > > I think that NSIS and SeaMoby / Context Transfer may > interwork to provide > > a good solution, in my opinion. > > I agree that CT might help for a good solution. However, for > the QoS part, > it is not only about a CT from one acess to anouther, but > also about the > rest of the path providing guarantees involved, where (as far as I > understood the CT work) context transfer itself does not help > too much. > > > NSIS most likely will be using a 'on path' signaling model, > where the > > QoS signaling takes the same path as the data. > > I don't think we have this aggreement in the NSIS group. > > > Marcus > > -------------------------------------- > Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DB1E.BCC28FB6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

Marcus:

  I agree with your point about PATH QoS entirely. This is one of
the issues I have with the idea that QoS "discovery" by the MN is
a problematical approach.

  CT, as a concept, is NOT restricted to the access edge routers.
It could be used anywhere along the path. There are issues to be
resolved with this model, and the real nature of CT is currently
academic until (and if) we start discussing actual solutions.

  The alternative is to use signalling to set up a new path with the
necessary resources. To do this during or after handover would clearly
add to the handover delay.

  To complete the QoS path set up prior to the handover, along potential
handover paths, could consume significant resources that would not
necessarly be used. There are approaches to minimizing this resource
consumption, but they require different approaches to the problem then
taken in the past. There is an analogy here with RSVP.

Gary


> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: April 3, 2002 08:38
> To: john.loughney@nokia.com; kempf@docomolabs-usa.com;
> charliep@iprg.nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery
>
>
>
>
> --On Tuesday, April 02, 2002 11:12 AM +0300
> john.loughney@nokia.com wrote:
>
> [...]
>
> > I think that NSIS and SeaMoby / Context Transfer may
> interwork to provide
> > a good solution, in my opinion.
>
> I agree that CT might help for a good solution. However, for
> the QoS part,
> it is not only about a CT from one acess to anouther, but
> also about the
> rest of the path providing guarantees involved, where (as far as I
> understood the CT work) context transfer itself does not help
> too much.
>
> > NSIS most likely will be using a 'on path' signaling model,
> where the
> > QoS signaling takes the same path as the data.
>
> I don't think we have this aggreement in the NSIS group.
>
>
> Marcus
>
> --------------------------------------
> Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DB1E.BCC28FB6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 10:33: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 KAA06287 for ; Wed, 3 Apr 2002 10:33: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 KAA00683; Wed, 3 Apr 2002 10:17: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 KAA00656 for ; Wed, 3 Apr 2002 10:17:10 -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 KAA05614 for ; Wed, 3 Apr 2002 10:17:07 -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 g33FGLu10649 for ; Wed, 3 Apr 2002 18:16:22 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 18:17:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 18:17:08 +0300 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] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 18:17:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA0@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: NSIS was:Examples of CAR discovery Thread-Index: AcHbHQsMQLgsR2l+SaOyrzXqw/MTOwABT+kA To: Cc: X-OriginalArrivalTime: 03 Apr 2002 15:17:09.0136 (UTC) FILETIME=[9F514900:01C1DB22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA00657 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > As far as I am concerned, we worked hard on defining CT requirements to be "proactive": > that is, happening "before" a handoff. Has CAR now supplanted this capability in > everyones mind? If so, then I think the main value of CT has been lost. CT -> Before, during, after handoff CARD -> capability of AR irrespective of handoff. The two are completely complimentary. CT will not discover the target to where the handoff will go to; CARD will not transfer any context. I don't see why we need to be mixing the two. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 10:33: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 KAA06301 for ; Wed, 3 Apr 2002 10:33:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02789 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 10: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 KAA00683; Wed, 3 Apr 2002 10:17: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 KAA00656 for ; Wed, 3 Apr 2002 10:17:10 -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 KAA05614 for ; Wed, 3 Apr 2002 10:17:07 -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 g33FGLu10649 for ; Wed, 3 Apr 2002 18:16:22 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 18:17:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 18:17:08 +0300 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] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 18:17:08 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA0@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] RE: NSIS was:Examples of CAR discovery Thread-Index: AcHbHQsMQLgsR2l+SaOyrzXqw/MTOwABT+kA To: Cc: X-OriginalArrivalTime: 03 Apr 2002 15:17:09.0136 (UTC) FILETIME=[9F514900:01C1DB22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA00657 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > As far as I am concerned, we worked hard on defining CT requirements to be "proactive": > that is, happening "before" a handoff. Has CAR now supplanted this capability in > everyones mind? If so, then I think the main value of CT has been lost. CT -> Before, during, after handoff CARD -> capability of AR irrespective of handoff. The two are completely complimentary. CT will not discover the target to where the handoff will go to; CARD will not transfer any context. I don't see why we need to be mixing the two. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 10:33: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 KAA06319 for ; Wed, 3 Apr 2002 10:33: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 KAA01358; Wed, 3 Apr 2002 10:21: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 KAA01327 for ; Wed, 3 Apr 2002 10:21:54 -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 KAA05818 for ; Wed, 3 Apr 2002 10:21:51 -0500 (EST) From: john.loughney@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 g33FM8511546 for ; Wed, 3 Apr 2002 18:22:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 18:21:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 18:21:52 +0300 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] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 18:21:52 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA1@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbHufhj2PsDjALQHGFeeP8aUiSEwAA8s+A To: Cc: X-OriginalArrivalTime: 03 Apr 2002 15:21:53.0176 (UTC) FILETIME=[489E5980:01C1DB23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA01331 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary & Marcus, > I agree with your point about PATH QoS entirely. This is one of > the issues I have with the idea that QoS "discovery" by the MN is > a problematical approach. Centralized QoS solution is not something that NSIS will do. The IESG is extremely allergic to such things - they do not scale Internet wide. It is entirely probable that NSIS will work on on-path signaling, perhaps using a proxy architecture, yet allow (optionally) a pre-configured entity as well. If NSIS does work on a proxy-based solution, CT between the proxy may very well be an attractive solution. All follow-ups should go to the NSIS list. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 10:33: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 KAA06329 for ; Wed, 3 Apr 2002 10:33:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02830 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 10:33: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 KAA01358; Wed, 3 Apr 2002 10:21: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 KAA01327 for ; Wed, 3 Apr 2002 10:21:54 -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 KAA05818 for ; Wed, 3 Apr 2002 10:21:51 -0500 (EST) From: john.loughney@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 g33FM8511546 for ; Wed, 3 Apr 2002 18:22:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 18:21:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 18:21:52 +0300 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] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 18:21:52 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA1@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbHufhj2PsDjALQHGFeeP8aUiSEwAA8s+A To: Cc: X-OriginalArrivalTime: 03 Apr 2002 15:21:53.0176 (UTC) FILETIME=[489E5980:01C1DB23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA01331 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary & Marcus, > I agree with your point about PATH QoS entirely. This is one of > the issues I have with the idea that QoS "discovery" by the MN is > a problematical approach. Centralized QoS solution is not something that NSIS will do. The IESG is extremely allergic to such things - they do not scale Internet wide. It is entirely probable that NSIS will work on on-path signaling, perhaps using a proxy architecture, yet allow (optionally) a pre-configured entity as well. If NSIS does work on a proxy-based solution, CT between the proxy may very well be an attractive solution. All follow-ups should go to the NSIS list. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 10:44: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 KAA06936 for ; Wed, 3 Apr 2002 10: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 KAA02520; Wed, 3 Apr 2002 10:31: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 KAA02482 for ; Wed, 3 Apr 2002 10:31:00 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06219 for ; Wed, 3 Apr 2002 10:30:57 -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 g33FUJi07102; Wed, 3 Apr 2002 10:30:20 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 10:30:21 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4996@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 10:30:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB24.7588A6C0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB24.7588A6C0 Content-Type: text/plain; charset="iso-8859-1" I agree John. But I wanted to make sure this was clear. I also want to be clear that CT does not require CAR (CARD/TARS). I'm not against CAR, per se, but in my view, it has more applicability to MANET type scenarios then to a well-engineered wireless data network. Let me try to explain my position by posing a semi-rhetorical question: would CAR be useful in a wired network (think plug and play)? Do we need QoS discovery (for example), when I plug my laptop into a hotel LAN? I only want to make sure that the two, CAR and CT, stay independent. Cheers Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 10:17 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Gary, > > > As far as I am concerned, we worked hard on defining CT > requirements to be "proactive": > > that is, happening "before" a handoff. Has CAR now > supplanted this capability in > > everyones mind? If so, then I think the main value of CT > has been lost. > > CT -> Before, during, after handoff > > CARD -> capability of AR irrespective of handoff. > > The two are completely complimentary. > > CT will not discover the target to where the handoff will go > to; CARD will not > transfer any context. I don't see why we need to be mixing the two. > > John > ------_=_NextPart_001_01C1DB24.7588A6C0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

I agree John. But I wanted to make sure this was clear.

I also want to be clear that CT does not require CAR (CARD/TARS).

I'm not against CAR, per se, but in my view, it has more applicability
to MANET type scenarios then to a well-engineered wireless data network.
Let me try to explain my position by posing a semi-rhetorical question:
would CAR be useful in a wired network (think plug and play)? Do we
need QoS discovery (for example), when I plug my laptop into a hotel
LAN?

I only want to make sure that the two, CAR and CT, stay independent.

Cheers
Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 10:17
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> > As far as I am concerned, we worked hard on defining CT
> requirements to be "proactive":
> > that is, happening "before" a handoff. Has CAR now
> supplanted this capability in
> > everyones mind? If so, then I think the main value of CT
> has been lost.
>
> CT -> Before, during, after handoff
>
> CARD -> capability of AR irrespective of handoff.
>
> The two are completely complimentary.
>
> CT will not discover the target to where the handoff will go
> to; CARD will not
> transfer any context.  I don't see why we need to be mixing the two.
>
> John
>

------_=_NextPart_001_01C1DB24.7588A6C0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 10:44: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 KAA06945 for ; Wed, 3 Apr 2002 10:44:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03848 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 10: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 KAA02520; Wed, 3 Apr 2002 10:31: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 KAA02482 for ; Wed, 3 Apr 2002 10:31:00 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06219 for ; Wed, 3 Apr 2002 10:30:57 -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 g33FUJi07102; Wed, 3 Apr 2002 10:30:20 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 10:30:21 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4996@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 10:30:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB24.7588A6C0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB24.7588A6C0 Content-Type: text/plain; charset="iso-8859-1" I agree John. But I wanted to make sure this was clear. I also want to be clear that CT does not require CAR (CARD/TARS). I'm not against CAR, per se, but in my view, it has more applicability to MANET type scenarios then to a well-engineered wireless data network. Let me try to explain my position by posing a semi-rhetorical question: would CAR be useful in a wired network (think plug and play)? Do we need QoS discovery (for example), when I plug my laptop into a hotel LAN? I only want to make sure that the two, CAR and CT, stay independent. Cheers Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 10:17 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Gary, > > > As far as I am concerned, we worked hard on defining CT > requirements to be "proactive": > > that is, happening "before" a handoff. Has CAR now > supplanted this capability in > > everyones mind? If so, then I think the main value of CT > has been lost. > > CT -> Before, during, after handoff > > CARD -> capability of AR irrespective of handoff. > > The two are completely complimentary. > > CT will not discover the target to where the handoff will go > to; CARD will not > transfer any context. I don't see why we need to be mixing the two. > > John > ------_=_NextPart_001_01C1DB24.7588A6C0 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

I agree John. But I wanted to make sure this was clear.

I also want to be clear that CT does not require CAR (CARD/TARS).

I'm not against CAR, per se, but in my view, it has more applicability
to MANET type scenarios then to a well-engineered wireless data network.
Let me try to explain my position by posing a semi-rhetorical question:
would CAR be useful in a wired network (think plug and play)? Do we
need QoS discovery (for example), when I plug my laptop into a hotel
LAN?

I only want to make sure that the two, CAR and CT, stay independent.

Cheers
Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 10:17
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> > As far as I am concerned, we worked hard on defining CT
> requirements to be "proactive":
> > that is, happening "before" a handoff. Has CAR now
> supplanted this capability in
> > everyones mind? If so, then I think the main value of CT
> has been lost.
>
> CT -> Before, during, after handoff
>
> CARD -> capability of AR irrespective of handoff.
>
> The two are completely complimentary.
>
> CT will not discover the target to where the handoff will go
> to; CARD will not
> transfer any context.  I don't see why we need to be mixing the two.
>
> John
>

------_=_NextPart_001_01C1DB24.7588A6C0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 10:53: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 KAA07162 for ; Wed, 3 Apr 2002 10:52: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 KAA03236; Wed, 3 Apr 2002 10:36: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 KAA03180 for ; Wed, 3 Apr 2002 10:36:43 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06464 for ; Wed, 3 Apr 2002 10:36:31 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g33FbLL05851; Wed, 3 Apr 2002 17:37:21 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B2019C051; Wed, 3 Apr 2002 17:35:47 +0200 (CEST) Date: Wed, 03 Apr 2002 17:49:57 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Gary Kenward , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Message-ID: <28171478.1017856197@[192.168.102.79]> In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4995@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C01AA4995@zcard031.ca.nortel.com > X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, --On Wednesday, April 03, 2002 9:49 AM -0500 Gary Kenward wrote: [...] > CT, as a concept, is NOT restricted to the access edge routers. > It could be used anywhere along the path. There are issues to be > resolved with this model, and the real nature of CT is currently > academic until (and if) we start discussing actual solutions. I do not completly know the CT concept, but I still assume it is about transfering context information from one box to another box (no matter where they are located. For QoS however we talk about potential context in a set of boxes along a path which needs to be changed. > The alternative is to use signalling to set up a new path with the > necessary resources. To do this during or after handover would clearly > add to the handover delay. Might nevertheless be not that a bad idea. > To complete the QoS path set up prior to the handover, along potential > handover paths, could consume significant resources that would not > necessarly be used. There are approaches to minimizing this resource > consumption, but they require different approaches to the problem then > taken in the past. There is an analogy here with RSVP. Sure. Marcus > Gary > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: April 3, 2002 08:38 >> To: john.loughney@nokia.com; kempf@docomolabs-usa.com; >> charliep@iprg.nokia.com >> Cc: seamoby@ietf.org >> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery >> >> >> >> >> --On Tuesday, April 02, 2002 11:12 AM +0300 >> john.loughney@nokia.com wrote: >> >> [...] >> >> > I think that NSIS and SeaMoby / Context Transfer may >> interwork to provide >> > a good solution, in my opinion. >> >> I agree that CT might help for a good solution. However, for >> the QoS part, >> it is not only about a CT from one acess to anouther, but >> also about the >> rest of the path providing guarantees involved, where (as far as I >> understood the CT work) context transfer itself does not help >> too much. >> >> > NSIS most likely will be using a 'on path' signaling model, >> where the >> > QoS signaling takes the same path as the data. >> >> I don't think we have this aggreement in the NSIS group. >> >> >> Marcus >> >> -------------------------------------- >> Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 10:53: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 KAA07169 for ; Wed, 3 Apr 2002 10:53:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04359 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 10:53: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 KAA03236; Wed, 3 Apr 2002 10:36: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 KAA03180 for ; Wed, 3 Apr 2002 10:36:43 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06464 for ; Wed, 3 Apr 2002 10:36:31 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g33FbLL05851; Wed, 3 Apr 2002 17:37:21 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B2019C051; Wed, 3 Apr 2002 17:35:47 +0200 (CEST) Date: Wed, 03 Apr 2002 17:49:57 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Gary Kenward , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Message-ID: <28171478.1017856197@[192.168.102.79]> In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4995@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C01AA4995@zcard031.ca.nortel.com > X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Gary, --On Wednesday, April 03, 2002 9:49 AM -0500 Gary Kenward wrote: [...] > CT, as a concept, is NOT restricted to the access edge routers. > It could be used anywhere along the path. There are issues to be > resolved with this model, and the real nature of CT is currently > academic until (and if) we start discussing actual solutions. I do not completly know the CT concept, but I still assume it is about transfering context information from one box to another box (no matter where they are located. For QoS however we talk about potential context in a set of boxes along a path which needs to be changed. > The alternative is to use signalling to set up a new path with the > necessary resources. To do this during or after handover would clearly > add to the handover delay. Might nevertheless be not that a bad idea. > To complete the QoS path set up prior to the handover, along potential > handover paths, could consume significant resources that would not > necessarly be used. There are approaches to minimizing this resource > consumption, but they require different approaches to the problem then > taken in the past. There is an analogy here with RSVP. Sure. Marcus > Gary > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: April 3, 2002 08:38 >> To: john.loughney@nokia.com; kempf@docomolabs-usa.com; >> charliep@iprg.nokia.com >> Cc: seamoby@ietf.org >> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery >> >> >> >> >> --On Tuesday, April 02, 2002 11:12 AM +0300 >> john.loughney@nokia.com wrote: >> >> [...] >> >> > I think that NSIS and SeaMoby / Context Transfer may >> interwork to provide >> > a good solution, in my opinion. >> >> I agree that CT might help for a good solution. However, for >> the QoS part, >> it is not only about a CT from one acess to anouther, but >> also about the >> rest of the path providing guarantees involved, where (as far as I >> understood the CT work) context transfer itself does not help >> too much. >> >> > NSIS most likely will be using a 'on path' signaling model, >> where the >> > QoS signaling takes the same path as the data. >> >> I don't think we have this aggreement in the NSIS group. >> >> >> Marcus >> >> -------------------------------------- >> Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> >> >> _______________________________________________ >> Seamoby mailing list >> Seamoby@ietf.org >> https://www1.ietf.org/mailman/listinfo/seamoby -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 11:33: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 LAA08313 for ; Wed, 3 Apr 2002 11:33: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 LAA06283; Wed, 3 Apr 2002 11:18: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 LAA06208 for ; Wed, 3 Apr 2002 11:18:03 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07873 for ; Wed, 3 Apr 2002 11:17:59 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33GHUi14331; Wed, 3 Apr 2002 11:17:31 -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 g33GHT508780; Wed, 3 Apr 2002 11:17:29 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 11:17:30 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4998@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:17:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB2A.A0A80AA2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB2A.A0A80AA2 Content-Type: text/plain; charset="iso-8859-1" Marcus: > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: April 3, 2002 10:50 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com; > kempf@docomolabs-usa.com; charliep@iprg.nokia.com > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > Gary, > > --On Wednesday, April 03, 2002 9:49 AM -0500 Gary Kenward > wrote: > [...] > > > CT, as a concept, is NOT restricted to the access edge routers. > > It could be used anywhere along the path. There are issues to be > > resolved with this model, and the real nature of CT is currently > > academic until (and if) we start discussing actual solutions. > > I do not completly know the CT concept, but I still assume it > is about > transfering context information from one box to another box > (no matter > where they are located. For QoS however we talk about > potential context in > a set of boxes along a path which needs to be changed. This is my view of the problem that CT can solve. I do not claim, however, that others share it. > > > The alternative is to use signalling to set up a new path with the > > necessary resources. To do this during or after handover > would clearly > > add to the handover delay. > > Might nevertheless be not that a bad idea. If you can do it within, say, one radio frame time. Keeping in mind that radio frame times are getting shorter and shorter (let's not debate numbers, the point is that there is a performance requirement that can only be indirectly addressed within the IETF). Gary > > > To complete the QoS path set up prior to the handover, > along potential > > handover paths, could consume significant resources that would not > > necessarly be used. There are approaches to minimizing this resource > > consumption, but they require different approaches to the > problem then > > taken in the past. There is an analogy here with RSVP. > > Sure. > > Marcus > > > Gary > ------_=_NextPart_001_01C1DB2A.A0A80AA2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

Marcus:

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: April 3, 2002 10:50
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com;
> kempf@docomolabs-usa.com; charliep@iprg.nokia.com
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> --On Wednesday, April 03, 2002 9:49 AM -0500 Gary Kenward
> <gkenward@nortelnetworks.com> wrote:
> [...]
>
> >   CT, as a concept, is NOT restricted to the access edge routers.
> > It could be used anywhere along the path. There are issues to be
> > resolved with this model, and the real nature of CT is currently
> > academic until (and if) we start discussing actual solutions.
>
> I do not completly know the CT concept, but I still assume it
> is about
> transfering context information from one box to another box
> (no matter
> where they are located. For QoS however we talk about
> potential context in
> a set of boxes along a path which needs to be changed.

This is my view of the problem that CT can solve. I do not claim, however, that
others share it.

>
> >   The alternative is to use signalling to set up a new path with the
> > necessary resources. To do this during or after handover
> would clearly
> > add to the handover delay.
>
> Might nevertheless be not that a bad idea.

If you can do it within, say, one radio frame time. Keeping in mind that radio frame times
are getting shorter and shorter (let's not debate numbers, the point is that there is a performance
requirement that can only be indirectly addressed within the IETF).

Gary

>
> >   To complete the QoS path set up prior to the handover,
> along potential
> > handover paths, could consume significant resources that would not
> > necessarly be used. There are approaches to minimizing this resource
> > consumption, but they require different approaches to the
> problem then
> > taken in the past. There is an analogy here with RSVP.
>
> Sure.
>
> Marcus
>
> > Gary
>

------_=_NextPart_001_01C1DB2A.A0A80AA2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 11:33: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 LAA08327 for ; Wed, 3 Apr 2002 11:33:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07469 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 11:33: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 LAA06283; Wed, 3 Apr 2002 11:18: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 LAA06208 for ; Wed, 3 Apr 2002 11:18:03 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07873 for ; Wed, 3 Apr 2002 11:17:59 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33GHUi14331; Wed, 3 Apr 2002 11:17:31 -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 g33GHT508780; Wed, 3 Apr 2002 11:17:29 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 11:17:30 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4998@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:17:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB2A.A0A80AA2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB2A.A0A80AA2 Content-Type: text/plain; charset="iso-8859-1" Marcus: > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: April 3, 2002 10:50 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com; > kempf@docomolabs-usa.com; charliep@iprg.nokia.com > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > Gary, > > --On Wednesday, April 03, 2002 9:49 AM -0500 Gary Kenward > wrote: > [...] > > > CT, as a concept, is NOT restricted to the access edge routers. > > It could be used anywhere along the path. There are issues to be > > resolved with this model, and the real nature of CT is currently > > academic until (and if) we start discussing actual solutions. > > I do not completly know the CT concept, but I still assume it > is about > transfering context information from one box to another box > (no matter > where they are located. For QoS however we talk about > potential context in > a set of boxes along a path which needs to be changed. This is my view of the problem that CT can solve. I do not claim, however, that others share it. > > > The alternative is to use signalling to set up a new path with the > > necessary resources. To do this during or after handover > would clearly > > add to the handover delay. > > Might nevertheless be not that a bad idea. If you can do it within, say, one radio frame time. Keeping in mind that radio frame times are getting shorter and shorter (let's not debate numbers, the point is that there is a performance requirement that can only be indirectly addressed within the IETF). Gary > > > To complete the QoS path set up prior to the handover, > along potential > > handover paths, could consume significant resources that would not > > necessarly be used. There are approaches to minimizing this resource > > consumption, but they require different approaches to the > problem then > > taken in the past. There is an analogy here with RSVP. > > Sure. > > Marcus > > > Gary > ------_=_NextPart_001_01C1DB2A.A0A80AA2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

Marcus:

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: April 3, 2002 10:50
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com;
> kempf@docomolabs-usa.com; charliep@iprg.nokia.com
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> --On Wednesday, April 03, 2002 9:49 AM -0500 Gary Kenward
> <gkenward@nortelnetworks.com> wrote:
> [...]
>
> >   CT, as a concept, is NOT restricted to the access edge routers.
> > It could be used anywhere along the path. There are issues to be
> > resolved with this model, and the real nature of CT is currently
> > academic until (and if) we start discussing actual solutions.
>
> I do not completly know the CT concept, but I still assume it
> is about
> transfering context information from one box to another box
> (no matter
> where they are located. For QoS however we talk about
> potential context in
> a set of boxes along a path which needs to be changed.

This is my view of the problem that CT can solve. I do not claim, however, that
others share it.

>
> >   The alternative is to use signalling to set up a new path with the
> > necessary resources. To do this during or after handover
> would clearly
> > add to the handover delay.
>
> Might nevertheless be not that a bad idea.

If you can do it within, say, one radio frame time. Keeping in mind that radio frame times
are getting shorter and shorter (let's not debate numbers, the point is that there is a performance
requirement that can only be indirectly addressed within the IETF).

Gary

>
> >   To complete the QoS path set up prior to the handover,
> along potential
> > handover paths, could consume significant resources that would not
> > necessarly be used. There are approaches to minimizing this resource
> > consumption, but they require different approaches to the
> problem then
> > taken in the past. There is an analogy here with RSVP.
>
> Sure.
>
> Marcus
>
> > Gary
>

------_=_NextPart_001_01C1DB2A.A0A80AA2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 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 LAA08500 for ; Wed, 3 Apr 2002 11:36: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 LAA06418; Wed, 3 Apr 2002 11:20: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 LAA06383 for ; Wed, 3 Apr 2002 11:20:06 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07950 for ; Wed, 3 Apr 2002 11:20:03 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33GJYi14659; Wed, 3 Apr 2002 11:19:34 -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 g33GJX508948; Wed, 3 Apr 2002 11:19:33 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 11:19:34 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4999@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:19:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB2B.16AC71A2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB2B.16AC71A2 Content-Type: text/plain; charset="iso-8859-1" John: I tried to find the email that discussed "centralized QoS", or "proxies". Can you elaborate where these threads originated? Gary PS: Since this is about CT, I am following it up on the Seamoby list. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 10:22 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > Gary & Marcus, > > > I agree with your point about PATH QoS entirely. This is one of > > the issues I have with the idea that QoS "discovery" by the MN is > > a problematical approach. > > Centralized QoS solution is not something that NSIS will do. The > IESG is extremely allergic to such things - they do not scale > Internet wide. > > It is entirely probable that NSIS will work on on-path signaling, > perhaps using a proxy architecture, yet allow (optionally) a > pre-configured entity as well. > > If NSIS does work on a proxy-based solution, CT between the proxy > may very well be an attractive solution. > > All follow-ups should go to the NSIS list. > > John > ------_=_NextPart_001_01C1DB2B.16AC71A2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

John:

 I tried to find the email that discussed "centralized QoS", or
"proxies". Can you elaborate where these threads originated?

Gary

PS: Since this is about CT, I am following it up on the Seamoby list.

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 10:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Gary & Marcus,
>
> >  I agree with your point about PATH QoS entirely. This is one of
> > the issues I have with the idea that QoS "discovery" by the MN is
> > a problematical approach.
>
> Centralized QoS solution is not something that NSIS will do.  The
> IESG is extremely allergic to such things - they do not scale
> Internet wide. 
>
> It is entirely probable that NSIS will work on on-path signaling,
> perhaps using a proxy architecture, yet allow (optionally) a
> pre-configured entity as well.
>
> If NSIS does work on a proxy-based solution, CT between the proxy
> may very well be an attractive solution.
>
> All follow-ups should go to the NSIS list.
>
> John
>

------_=_NextPart_001_01C1DB2B.16AC71A2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 11:36: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 LAA08511 for ; Wed, 3 Apr 2002 11:36:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07813 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 11:36: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 LAA06418; Wed, 3 Apr 2002 11:20: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 LAA06383 for ; Wed, 3 Apr 2002 11:20:06 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07950 for ; Wed, 3 Apr 2002 11:20:03 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33GJYi14659; Wed, 3 Apr 2002 11:19:34 -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 g33GJX508948; Wed, 3 Apr 2002 11:19:33 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 11:19:34 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4999@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:19:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB2B.16AC71A2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB2B.16AC71A2 Content-Type: text/plain; charset="iso-8859-1" John: I tried to find the email that discussed "centralized QoS", or "proxies". Can you elaborate where these threads originated? Gary PS: Since this is about CT, I am following it up on the Seamoby list. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 10:22 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > Gary & Marcus, > > > I agree with your point about PATH QoS entirely. This is one of > > the issues I have with the idea that QoS "discovery" by the MN is > > a problematical approach. > > Centralized QoS solution is not something that NSIS will do. The > IESG is extremely allergic to such things - they do not scale > Internet wide. > > It is entirely probable that NSIS will work on on-path signaling, > perhaps using a proxy architecture, yet allow (optionally) a > pre-configured entity as well. > > If NSIS does work on a proxy-based solution, CT between the proxy > may very well be an attractive solution. > > All follow-ups should go to the NSIS list. > > John > ------_=_NextPart_001_01C1DB2B.16AC71A2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

John:

 I tried to find the email that discussed "centralized QoS", or
"proxies". Can you elaborate where these threads originated?

Gary

PS: Since this is about CT, I am following it up on the Seamoby list.

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 10:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Gary & Marcus,
>
> >  I agree with your point about PATH QoS entirely. This is one of
> > the issues I have with the idea that QoS "discovery" by the MN is
> > a problematical approach.
>
> Centralized QoS solution is not something that NSIS will do.  The
> IESG is extremely allergic to such things - they do not scale
> Internet wide. 
>
> It is entirely probable that NSIS will work on on-path signaling,
> perhaps using a proxy architecture, yet allow (optionally) a
> pre-configured entity as well.
>
> If NSIS does work on a proxy-based solution, CT between the proxy
> may very well be an attractive solution.
>
> All follow-ups should go to the NSIS list.
>
> John
>

------_=_NextPart_001_01C1DB2B.16AC71A2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 11:48: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 LAA08794 for ; Wed, 3 Apr 2002 11:48: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 LAA07603; Wed, 3 Apr 2002 11:34: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 LAA07572 for ; Wed, 3 Apr 2002 11:34:29 -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 LAA08361 for ; Wed, 3 Apr 2002 11:34:26 -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 IAA26437; Wed, 3 Apr 2002 08:33:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33GXvk00897; Wed, 3 Apr 2002 08:33:57 -0800 X-mProtect: <200204031633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduSPTrO; Wed, 03 Apr 2002 08:33:55 PST Message-ID: <3CAB2EF4.37B2C5C4@iprg.nokia.com> Date: Wed, 03 Apr 2002 08:33:56 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery References: <9FBD322B7824D511B36900508BF93C9C01AA4994@zcard031.ca.nortel.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 Hello Gary, I definitely do NOT see CAR discovery replacing context transfer. The latter can go on without the former, entirely. Indeed, it would also be possible to discover candidate access routers, and then to decide not to move anyway for whatever reason. Thus, the former could go on without the latter also. In my mind, the connection is that CAR discovery *might* depend on the contexts that are to be transferred (if any). Regards, Charlie P. > Gary Kenward wrote: > > John, et al: > > As far as I am concerned, we worked hard on defining CT requirements to be > "proactive": > that is, happening "before" a handoff. Has CAR now supplanted this capability > in > everyones mind? If so, then I think the main value of CT has been lost. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 11:48: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 LAA08805 for ; Wed, 3 Apr 2002 11:48:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08551 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 11: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 LAA07603; Wed, 3 Apr 2002 11:34: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 LAA07572 for ; Wed, 3 Apr 2002 11:34:29 -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 LAA08361 for ; Wed, 3 Apr 2002 11:34:26 -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 IAA26437; Wed, 3 Apr 2002 08:33:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33GXvk00897; Wed, 3 Apr 2002 08:33:57 -0800 X-mProtect: <200204031633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduSPTrO; Wed, 03 Apr 2002 08:33:55 PST Message-ID: <3CAB2EF4.37B2C5C4@iprg.nokia.com> Date: Wed, 03 Apr 2002 08:33:56 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery References: <9FBD322B7824D511B36900508BF93C9C01AA4994@zcard031.ca.nortel.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 Hello Gary, I definitely do NOT see CAR discovery replacing context transfer. The latter can go on without the former, entirely. Indeed, it would also be possible to discover candidate access routers, and then to decide not to move anyway for whatever reason. Thus, the former could go on without the latter also. In my mind, the connection is that CAR discovery *might* depend on the contexts that are to be transferred (if any). Regards, Charlie P. > Gary Kenward wrote: > > John, et al: > > As far as I am concerned, we worked hard on defining CT requirements to be > "proactive": > that is, happening "before" a handoff. Has CAR now supplanted this capability > in > everyones mind? If so, then I think the main value of CT has been lost. > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 12:12: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 MAA09445 for ; Wed, 3 Apr 2002 12:12: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 LAA08997; Wed, 3 Apr 2002 11:55: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 LAA08952 for ; Wed, 3 Apr 2002 11:54:56 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08949 for ; Wed, 3 Apr 2002 11:54:52 -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 g33GsQ613695; Wed, 3 Apr 2002 10:54:26 -0600 (CST) Message-ID: <3CAB33C1.70700@alcatel.com> Date: Wed, 03 Apr 2002 10:54:25 -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 CC: seamoby@ietf.org, stefano.faccin@nokia.com References: <3CA39DBD.6040300@alcatel.com> <3CAA097D.4000300@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] New mailing list for ip-paging work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Hopefully this is going to be the last announcement mail, sorry if you receive multiple copies: The mailing list for ip-paging work has moved to: ip-paging@tpd.usa.alcatel.com We subscribed everybody on the previous list to the new list. This new list is a majordomo administered list so you can get there (new members) by sending an email to majordomo@tpd.usa.alcatel.com with your request, i.e subsribe ip-paging your email If you have questions let us know. Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 12:12: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 MAA09455 for ; Wed, 3 Apr 2002 12:12:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11652 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 12: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 LAA08997; Wed, 3 Apr 2002 11:55: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 LAA08952 for ; Wed, 3 Apr 2002 11:54:56 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08949 for ; Wed, 3 Apr 2002 11:54:52 -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 g33GsQ613695; Wed, 3 Apr 2002 10:54:26 -0600 (CST) Message-ID: <3CAB33C1.70700@alcatel.com> Date: Wed, 03 Apr 2002 10:54:25 -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 CC: seamoby@ietf.org, stefano.faccin@nokia.com References: <3CA39DBD.6040300@alcatel.com> <3CAA097D.4000300@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] New mailing list for ip-paging work Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Hopefully this is going to be the last announcement mail, sorry if you receive multiple copies: The mailing list for ip-paging work has moved to: ip-paging@tpd.usa.alcatel.com We subscribed everybody on the previous list to the new list. This new list is a majordomo administered list so you can get there (new members) by sending an email to majordomo@tpd.usa.alcatel.com with your request, i.e subsribe ip-paging your email If you have questions let us know. Behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 12: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 MAA10002 for ; Wed, 3 Apr 2002 12:30: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 MAA11786; Wed, 3 Apr 2002 12:13: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 MAA11758 for ; Wed, 3 Apr 2002 12:13:37 -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 MAA09518 for ; Wed, 3 Apr 2002 12:13:33 -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 g33HCXu13189 for ; Wed, 3 Apr 2002 20:12:48 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 20:13:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 20:13:21 +0300 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] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 20:13:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA2@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbK3KB62lnKbd0RqiRJLyT+cLUOwABvl4A To: Cc: X-OriginalArrivalTime: 03 Apr 2002 17:13:21.0644 (UTC) FILETIME=[DB4192C0:01C1DB32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11759 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > I tried to find the email that discussed "centralized QoS", or > "proxies". Can you elaborate where these threads originated? > Gary > PS: Since this is about CT, I am following it up on the Seamoby list. My comment was about NSIS, not about CT so I don't think this conversation is really of relevance to SeaMoby. If the signaling path is not along the data path, then NSIS signaling probably would not need CT. If you see how CT could be used, please let us know, especially on the NSIS list. John PS - reminds me of an old Rodney Dangerfield routine 'So, I was at a SeaMoby meeting when an NSIS discussion broke out.' _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 12: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 MAA10013 for ; Wed, 3 Apr 2002 12:30:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12698 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 12:30: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 MAA11786; Wed, 3 Apr 2002 12:13: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 MAA11758 for ; Wed, 3 Apr 2002 12:13:37 -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 MAA09518 for ; Wed, 3 Apr 2002 12:13:33 -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 g33HCXu13189 for ; Wed, 3 Apr 2002 20:12:48 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 20:13:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 20:13:21 +0300 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] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 20:13:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA2@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbK3KB62lnKbd0RqiRJLyT+cLUOwABvl4A To: Cc: X-OriginalArrivalTime: 03 Apr 2002 17:13:21.0644 (UTC) FILETIME=[DB4192C0:01C1DB32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11759 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > I tried to find the email that discussed "centralized QoS", or > "proxies". Can you elaborate where these threads originated? > Gary > PS: Since this is about CT, I am following it up on the Seamoby list. My comment was about NSIS, not about CT so I don't think this conversation is really of relevance to SeaMoby. If the signaling path is not along the data path, then NSIS signaling probably would not need CT. If you see how CT could be used, please let us know, especially on the NSIS list. John PS - reminds me of an old Rodney Dangerfield routine 'So, I was at a SeaMoby meeting when an NSIS discussion broke out.' _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 12:41: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 MAA10274 for ; Wed, 3 Apr 2002 12:41: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 MAA12307; Wed, 3 Apr 2002 12:24: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 MAA12279 for ; Wed, 3 Apr 2002 12:24:53 -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 MAA09796 for ; Wed, 3 Apr 2002 12:24:48 -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 g33HPmJ05607 for ; Wed, 3 Apr 2002 20:25:48 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 20:24:51 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 20:24:51 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 11:24:49 -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, 3 Apr 2002 12:24:48 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHaoAmVMwpY19abTMuz9pckCP25rAAkIV2Q To: , Cc: X-OriginalArrivalTime: 03 Apr 2002 17:24:49.0810 (UTC) FILETIME=[756F5F20:01C1DB34] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA12281 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, see comment inline... -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, April 02, 2002 6:40 PM To: Perkins Charles (IPRG) Cc: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery > I'm O.K. with your suggestion, except that if we don't have any > data, we can't show interoperability. We ought to pick out some > reasonable contexts just to show that the seamoby protocol > really works. I've never heard of any working group standardizing > a framework that didn't include some guts too. > I can think of cases where containers get standardized but their contents don't. SLP is a good example. It defines the protocol and a way to define services but does not define the services themselves. LDAP is another. [DOT] It is not only about the 'containers' to get standardized. Designing a carrier protocol without considering the information to be carried might quickly serve as a bad example of engineering. In other words, making a decision about sending information from and to different entities without considering WHAT (semantics) and HOW MUCH (semantics plus syntax) is shuffled around might lead very soon after the actual standardization of CAR discovery to the proof of its uselessness rather than its usefulness, if the way the protocol is designed restricts the amount of information that could be carried. [DOT] In particular due to the involvement of mobile devices, this amount of information is a crucial factor in designing the protocol. Hence, a proper consideration of this information (what is this information and how is this information represented) should be a must for us to study before we make decisions on the design of the final solution. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 12:41: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 MAA10285 for ; Wed, 3 Apr 2002 12:41:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13940 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 12:41: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 MAA12307; Wed, 3 Apr 2002 12:24: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 MAA12279 for ; Wed, 3 Apr 2002 12:24:53 -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 MAA09796 for ; Wed, 3 Apr 2002 12:24:48 -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 g33HPmJ05607 for ; Wed, 3 Apr 2002 20:25:48 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 20:24:51 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 20:24:51 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 11:24:49 -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, 3 Apr 2002 12:24:48 -0500 Message-ID: Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHaoAmVMwpY19abTMuz9pckCP25rAAkIV2Q To: , Cc: X-OriginalArrivalTime: 03 Apr 2002 17:24:49.0810 (UTC) FILETIME=[756F5F20:01C1DB34] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA12281 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, see comment inline... -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, April 02, 2002 6:40 PM To: Perkins Charles (IPRG) Cc: seamoby@ietf.org Subject: Re: [Seamoby] Examples of CAR discovery > I'm O.K. with your suggestion, except that if we don't have any > data, we can't show interoperability. We ought to pick out some > reasonable contexts just to show that the seamoby protocol > really works. I've never heard of any working group standardizing > a framework that didn't include some guts too. > I can think of cases where containers get standardized but their contents don't. SLP is a good example. It defines the protocol and a way to define services but does not define the services themselves. LDAP is another. [DOT] It is not only about the 'containers' to get standardized. Designing a carrier protocol without considering the information to be carried might quickly serve as a bad example of engineering. In other words, making a decision about sending information from and to different entities without considering WHAT (semantics) and HOW MUCH (semantics plus syntax) is shuffled around might lead very soon after the actual standardization of CAR discovery to the proof of its uselessness rather than its usefulness, if the way the protocol is designed restricts the amount of information that could be carried. [DOT] In particular due to the involvement of mobile devices, this amount of information is a crucial factor in designing the protocol. Hence, a proper consideration of this information (what is this information and how is this information represented) should be a must for us to study before we make decisions on the design of the final solution. Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 13:02: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 NAA10922 for ; Wed, 3 Apr 2002 13:02: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 MAA14049; Wed, 3 Apr 2002 12:42: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 MAA14022 for ; Wed, 3 Apr 2002 12:42:27 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10320 for ; Wed, 3 Apr 2002 12:42:25 -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 g33Hfai01908; Wed, 3 Apr 2002 12:41:36 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:41:37 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA499F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:41:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB36.4234D962" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB36.4234D962 Content-Type: text/plain; charset="iso-8859-1" John: Clearly there is an overlap as all three solutions, CT, CAR and NSIS are dealing with QoS. I was content to let this thread drop until I came across the following requirement in re-reading draft-ietf-nsis-req-00.txt: "5.1.2 Resource availability information on request In some scenarios, e.g., the mobile terminal scenario, it is required to query, whether resources are available, without performing a reservation on the resource. One solution might be a feedback mechanism based on which a QoS inferred handover can take place." There seems to be some overlap in functionality here. Alternative solutions are usually great choices to have, but clearly the conversation on the respective roles of NSIS and CAR must continue. Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 12:13 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > Hi Gary, > > > I tried to find the email that discussed "centralized QoS", or > > "proxies". Can you elaborate where these threads originated? > > Gary > > PS: Since this is about CT, I am following it up on the > Seamoby list. > > My comment was about NSIS, not about CT so I don't think this > conversation is really of relevance to SeaMoby. If the signaling > path is not along the data path, then NSIS signaling > probably would not need CT. If you see how CT could be used, please > let us know, especially on the NSIS list. > > John > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was > at a SeaMoby meeting when an NSIS discussion broke out.' > ------_=_NextPart_001_01C1DB36.4234D962 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

John:

  Clearly there is an overlap as all three solutions, CT, CAR and
NSIS are dealing with QoS.

  I was content to let this thread drop until I came across the following
requirement in re-reading draft-ietf-nsis-req-00.txt:

"5.1.2 Resource availability information on request

   In some scenarios, e.g., the mobile terminal scenario, it is
   required to query, whether resources are available, without
   performing a reservation on the resource. One solution might be a
   feedback mechanism based on which a QoS inferred handover can take
   place."

There seems to be some overlap in functionality here. Alternative solutions
are usually great choices to have, but clearly the conversation on the respective
roles of NSIS and CAR must continue.

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 12:13
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Hi Gary,
>
> > I tried to find the email that discussed "centralized QoS", or
> > "proxies". Can you elaborate where these threads originated?
> > Gary
> > PS: Since this is about CT, I am following it up on the
> Seamoby list.
>
> My comment was about NSIS, not about CT so I don't think this
> conversation is really of relevance to SeaMoby.  If the signaling
> path is not along the data path, then NSIS signaling
> probably would not need CT.  If you see how CT could be used, please
> let us know, especially on the NSIS list.
>
> John
>
> PS - reminds me of an old Rodney Dangerfield routine 'So, I was
> at a SeaMoby meeting when an NSIS discussion broke out.'
>

------_=_NextPart_001_01C1DB36.4234D962-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 13:02: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 NAA10932 for ; Wed, 3 Apr 2002 13:02:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15602 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 13:02: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 MAA14049; Wed, 3 Apr 2002 12:42: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 MAA14022 for ; Wed, 3 Apr 2002 12:42:27 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10320 for ; Wed, 3 Apr 2002 12:42:25 -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 g33Hfai01908; Wed, 3 Apr 2002 12:41:36 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:41:37 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA499F@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:41:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB36.4234D962" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB36.4234D962 Content-Type: text/plain; charset="iso-8859-1" John: Clearly there is an overlap as all three solutions, CT, CAR and NSIS are dealing with QoS. I was content to let this thread drop until I came across the following requirement in re-reading draft-ietf-nsis-req-00.txt: "5.1.2 Resource availability information on request In some scenarios, e.g., the mobile terminal scenario, it is required to query, whether resources are available, without performing a reservation on the resource. One solution might be a feedback mechanism based on which a QoS inferred handover can take place." There seems to be some overlap in functionality here. Alternative solutions are usually great choices to have, but clearly the conversation on the respective roles of NSIS and CAR must continue. Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 3, 2002 12:13 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > Hi Gary, > > > I tried to find the email that discussed "centralized QoS", or > > "proxies". Can you elaborate where these threads originated? > > Gary > > PS: Since this is about CT, I am following it up on the > Seamoby list. > > My comment was about NSIS, not about CT so I don't think this > conversation is really of relevance to SeaMoby. If the signaling > path is not along the data path, then NSIS signaling > probably would not need CT. If you see how CT could be used, please > let us know, especially on the NSIS list. > > John > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was > at a SeaMoby meeting when an NSIS discussion broke out.' > ------_=_NextPart_001_01C1DB36.4234D962 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

John:

  Clearly there is an overlap as all three solutions, CT, CAR and
NSIS are dealing with QoS.

  I was content to let this thread drop until I came across the following
requirement in re-reading draft-ietf-nsis-req-00.txt:

"5.1.2 Resource availability information on request

   In some scenarios, e.g., the mobile terminal scenario, it is
   required to query, whether resources are available, without
   performing a reservation on the resource. One solution might be a
   feedback mechanism based on which a QoS inferred handover can take
   place."

There seems to be some overlap in functionality here. Alternative solutions
are usually great choices to have, but clearly the conversation on the respective
roles of NSIS and CAR must continue.

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 3, 2002 12:13
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Hi Gary,
>
> > I tried to find the email that discussed "centralized QoS", or
> > "proxies". Can you elaborate where these threads originated?
> > Gary
> > PS: Since this is about CT, I am following it up on the
> Seamoby list.
>
> My comment was about NSIS, not about CT so I don't think this
> conversation is really of relevance to SeaMoby.  If the signaling
> path is not along the data path, then NSIS signaling
> probably would not need CT.  If you see how CT could be used, please
> let us know, especially on the NSIS list.
>
> John
>
> PS - reminds me of an old Rodney Dangerfield routine 'So, I was
> at a SeaMoby meeting when an NSIS discussion broke out.'
>

------_=_NextPart_001_01C1DB36.4234D962-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 13:05: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 NAA10996 for ; Wed, 3 Apr 2002 13:05: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 MAA14331; Wed, 3 Apr 2002 12:47: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 MAA14302 for ; Wed, 3 Apr 2002 12:47:43 -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 MAA10507 for ; Wed, 3 Apr 2002 12:47:40 -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 JAA00310; Wed, 3 Apr 2002 09:47:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33HlCq17433; Wed, 3 Apr 2002 09:47:12 -0800 X-mProtect: <200204031747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvjIPic; Wed, 03 Apr 2002 09:47:10 PST Message-ID: <3CAB401D.D95B0029@iprg.nokia.com> Date: Wed, 03 Apr 2002 09:47:09 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> <20253112.1017848279@[192.168.102.79]> 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 Marcus, Marcus Brunner wrote: > I agree that CT might help for a good solution. However, for the QoS part, > it is not only about a CT from one acess to anouther, but also about the > rest of the path providing guarantees involved, where (as far as I > understood the CT work) context transfer itself does not help too much. My first model of the access networks is that they are not congested, and can move packets back and forth between access routers without problems. This isn't always true, of course, but it is good enough to get us started. Under this model, then we can get good mileage out of using QoS as just another context to be transferred, as long as the new access router has enough spare capacity over the air to satisfy the QoS needs of the mobile node. If the access networks themselves are constrained, then the CAR discovery operation would have to be augmented by operations to insure availability of capacity between the old and new access routers, but I don't see that we have to design for that case right now. Moreover, I think that whatever design we come up with, will be easily extendible whenever it needs to be extended to cover the more constrained access networks. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 13: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 NAA11005 for ; Wed, 3 Apr 2002 13:05:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15880 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 13: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 MAA14331; Wed, 3 Apr 2002 12:47: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 MAA14302 for ; Wed, 3 Apr 2002 12:47:43 -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 MAA10507 for ; Wed, 3 Apr 2002 12:47:40 -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 JAA00310; Wed, 3 Apr 2002 09:47:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33HlCq17433; Wed, 3 Apr 2002 09:47:12 -0800 X-mProtect: <200204031747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvjIPic; Wed, 03 Apr 2002 09:47:10 PST Message-ID: <3CAB401D.D95B0029@iprg.nokia.com> Date: Wed, 03 Apr 2002 09:47:09 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> <20253112.1017848279@[192.168.102.79]> 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 Marcus, Marcus Brunner wrote: > I agree that CT might help for a good solution. However, for the QoS part, > it is not only about a CT from one acess to anouther, but also about the > rest of the path providing guarantees involved, where (as far as I > understood the CT work) context transfer itself does not help too much. My first model of the access networks is that they are not congested, and can move packets back and forth between access routers without problems. This isn't always true, of course, but it is good enough to get us started. Under this model, then we can get good mileage out of using QoS as just another context to be transferred, as long as the new access router has enough spare capacity over the air to satisfy the QoS needs of the mobile node. If the access networks themselves are constrained, then the CAR discovery operation would have to be augmented by operations to insure availability of capacity between the old and new access routers, but I don't see that we have to design for that case right now. Moreover, I think that whatever design we come up with, will be easily extendible whenever it needs to be extended to cover the more constrained access networks. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 13:07: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 NAA11119 for ; Wed, 3 Apr 2002 13:07: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 MAA14691; Wed, 3 Apr 2002 12:53: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 MAA14659 for ; Wed, 3 Apr 2002 12:53:13 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10680 for ; Wed, 3 Apr 2002 12:53:11 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33Hqfi03368; Wed, 3 Apr 2002 12:52:41 -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 g33Hqe515353; Wed, 3 Apr 2002 12:52:40 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:52:41 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , brunner@ccrle.nec.de Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:52:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB37.ED37C486" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB37.ED37C486 Content-Type: text/plain; charset="iso-8859-1" Charlie: Since we are talking about QoS mechanisms such as DS and IS, queue congestion isn't the only issue. There needs to be filtering/policing resources available (and assigned), and bandwidth allocated for specific services (such as, for example, EF). Or have I misinterpreted what you mean by "congestion"? Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 3, 2002 12:47 > To: brunner@ccrle.nec.de > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > Hello Marcus, > > Marcus Brunner wrote: > > > I agree that CT might help for a good solution. However, > for the QoS part, > > it is not only about a CT from one acess to anouther, but > also about the > > rest of the path providing guarantees involved, where (as far as I > > understood the CT work) context transfer itself does not > help too much. > > My first model of the access networks is that they are not > congested, and can move packets back and forth between access > routers without problems. This isn't always true, of course, > but it is good enough to get us started. Under this model, > then we can get good mileage out of using QoS as just another > context to be transferred, as long as the new access router > has enough spare capacity over the air to satisfy the QoS > needs of the mobile node. > > If the access networks themselves are constrained, then the > CAR discovery operation would have to be augmented by operations > to insure availability of capacity between the old and new > access routers, but I don't see that we have to design for that > case right now. Moreover, I think that whatever design we come > up with, will be easily extendible whenever it needs to be extended > to cover the more constrained access networks. > > Regards, > Charlie P. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DB37.ED37C486 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] NSIS was:Examples of CAR discovery

Charlie:

   Since we are talking about QoS = mechanisms such as DS and IS, queue congestion
isn't the only issue. There needs to be = filtering/policing resources available
(and assigned), and bandwidth allocated for specific = services (such as, for example, EF).

   Or have I misinterpreted what you mean = by "congestion"?

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 3, 2002 12:47
> To: brunner@ccrle.nec.de
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR = discovery
>
>
>
> Hello Marcus,
>
> Marcus Brunner wrote:
>
> > I agree that CT might help for a good = solution. However,
> for the QoS part,
> > it is not only about a CT from one acess = to anouther, but
> also about the
> > rest of the path providing guarantees = involved, where (as far as I
> > understood the CT work) context transfer = itself does not
> help too much.
>
> My first model of the access networks is that = they are not
> congested, and can move packets back and forth = between access
> routers without problems.  This isn't = always true, of course,
> but it is good enough to get us started.  = Under this model,
> then we can get good mileage out of using QoS = as just another
> context to be transferred, as long as the new = access router
> has enough spare capacity over the air to = satisfy the QoS
> needs of the mobile node.
>
> If the access networks themselves are = constrained, then the
> CAR discovery operation would have to be = augmented by operations
> to insure availability of capacity between the = old and new
> access routers, but I don't see that we have to = design for that
> case right now.  Moreover, I think that = whatever design we come
> up with, will be easily extendible whenever it = needs to be extended
> to cover the more constrained access = networks.
>
> Regards,
> Charlie P.
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DB37.ED37C486-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 13:07: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 NAA11129 for ; Wed, 3 Apr 2002 13:07:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16010 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 13:07: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 MAA14691; Wed, 3 Apr 2002 12:53: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 MAA14659 for ; Wed, 3 Apr 2002 12:53:13 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10680 for ; Wed, 3 Apr 2002 12:53:11 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33Hqfi03368; Wed, 3 Apr 2002 12:52:41 -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 g33Hqe515353; Wed, 3 Apr 2002 12:52:40 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 12:52:41 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , brunner@ccrle.nec.de Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:52:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB37.ED37C486" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB37.ED37C486 Content-Type: text/plain; charset="iso-8859-1" Charlie: Since we are talking about QoS mechanisms such as DS and IS, queue congestion isn't the only issue. There needs to be filtering/policing resources available (and assigned), and bandwidth allocated for specific services (such as, for example, EF). Or have I misinterpreted what you mean by "congestion"? Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 3, 2002 12:47 > To: brunner@ccrle.nec.de > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > Hello Marcus, > > Marcus Brunner wrote: > > > I agree that CT might help for a good solution. However, > for the QoS part, > > it is not only about a CT from one acess to anouther, but > also about the > > rest of the path providing guarantees involved, where (as far as I > > understood the CT work) context transfer itself does not > help too much. > > My first model of the access networks is that they are not > congested, and can move packets back and forth between access > routers without problems. This isn't always true, of course, > but it is good enough to get us started. Under this model, > then we can get good mileage out of using QoS as just another > context to be transferred, as long as the new access router > has enough spare capacity over the air to satisfy the QoS > needs of the mobile node. > > If the access networks themselves are constrained, then the > CAR discovery operation would have to be augmented by operations > to insure availability of capacity between the old and new > access routers, but I don't see that we have to design for that > case right now. Moreover, I think that whatever design we come > up with, will be easily extendible whenever it needs to be extended > to cover the more constrained access networks. > > Regards, > Charlie P. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DB37.ED37C486 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] NSIS was:Examples of CAR discovery

Charlie:

   Since we are talking about QoS = mechanisms such as DS and IS, queue congestion
isn't the only issue. There needs to be = filtering/policing resources available
(and assigned), and bandwidth allocated for specific = services (such as, for example, EF).

   Or have I misinterpreted what you mean = by "congestion"?

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 3, 2002 12:47
> To: brunner@ccrle.nec.de
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR = discovery
>
>
>
> Hello Marcus,
>
> Marcus Brunner wrote:
>
> > I agree that CT might help for a good = solution. However,
> for the QoS part,
> > it is not only about a CT from one acess = to anouther, but
> also about the
> > rest of the path providing guarantees = involved, where (as far as I
> > understood the CT work) context transfer = itself does not
> help too much.
>
> My first model of the access networks is that = they are not
> congested, and can move packets back and forth = between access
> routers without problems.  This isn't = always true, of course,
> but it is good enough to get us started.  = Under this model,
> then we can get good mileage out of using QoS = as just another
> context to be transferred, as long as the new = access router
> has enough spare capacity over the air to = satisfy the QoS
> needs of the mobile node.
>
> If the access networks themselves are = constrained, then the
> CAR discovery operation would have to be = augmented by operations
> to insure availability of capacity between the = old and new
> access routers, but I don't see that we have to = design for that
> case right now.  Moreover, I think that = whatever design we come
> up with, will be easily extendible whenever it = needs to be extended
> to cover the more constrained access = networks.
>
> Regards,
> Charlie P.
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DB37.ED37C486-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 14:05: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 OAA12405 for ; Wed, 3 Apr 2002 14:05: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 NAA18005; Wed, 3 Apr 2002 13:50: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 NAA17968 for ; Wed, 3 Apr 2002 13: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 NAA11974 for ; Wed, 3 Apr 2002 13: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 g33InOI18835; Wed, 3 Apr 2002 10:49:24 -0800 (PST) Message-ID: <005a01c1db40$0c5b1450$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> <03a001c1da95$e63a3080$7e6015ac@T23KEMPF> <3CAA563B.B394ED79@iprg.nokia.com> Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Wed, 3 Apr 2002 10:47: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 Hi Charlie, > Well, I don't see this. The target router could well be determined > by current conditions (load, bandwidth availability, etc.) and that > does not necessarily depend on the "type" of the technology. > The protocol may well be used to identify a new access router > on a different wireless medium that has roughly the same speed. > With several variations of 802.11 and Bluetooth and UMTS and > 3G coming, this is very likely. I am not very comfortable with the > term "IP characteristics", since IP pretty much has the same > characteristics no matter what the physical medium happens to > be. We know the minimum packet size, for instance. IP itself > doesn't have any delay or speed (for example) characteristics. > So it sounds to me like you see the selection basically done on link characteristics, and not something based on IP service, is that correct? > The problem you refer to as "wireless media selection" should > not be the focus of the discussion, because we don't want to select > a medium. We want to select a point of attachment to the Internet. > The medium is _not_ the message. > :-) The problem I'm trying to solve here is I have a laptop with 802.11 and GPRS and I am wandering through Ginza. The 802.11 service is not continuous, periodically it drops out. I'm watching streaming video and it's real jerky on GPRS. I'd like to know when I enter a hot spot, so I can switch to the smoother 802.11 service. The reason I'm interested in this problem (speaking here as a WG member and not the co-chair) is because, within about a year, I expect that DoCoMo could offer this capability to its customers if we had some way to interoperably do it, i.e. this is not a theoretical exercise. I believe it should be possible to accommodate this application of CAR discovery with others, but since I can see a real need for this, I would certainly like CAR discovery to solve it. I don't particularly care whether the 802.11 service is advertised as "broadband" or "WLAN" to the customer (I don't know what the Japanese term is for this kind of service due to my limited knowledge of Japanese), but, the IP stack on the laptop has got to know what interface to bring up and configure, so it has to know some kind of agreed upon name for wireless medium in order to find the interface card. Which is why I suggested "wireless medium selection". Most of the other applications of CAR discovery I've heard don't seem like they have the same time pressure for solution that this one does, but I'm certainly open to being convinced otherwise. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 14:05: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 OAA12420 for ; Wed, 3 Apr 2002 14:05:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19391 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 14:05: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 NAA18005; Wed, 3 Apr 2002 13:50: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 NAA17968 for ; Wed, 3 Apr 2002 13: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 NAA11974 for ; Wed, 3 Apr 2002 13: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 g33InOI18835; Wed, 3 Apr 2002 10:49:24 -0800 (PST) Message-ID: <005a01c1db40$0c5b1450$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4985@zcard031.ca.nortel.com> <014201c1da69$c12f2c40$7e6015ac@T23KEMPF> <3CAA0BF4.60149725@iprg.nokia.com> <03a001c1da95$e63a3080$7e6015ac@T23KEMPF> <3CAA563B.B394ED79@iprg.nokia.com> Subject: Re: What is Handover? (was: Re: [Seamoby] Examples of CAR discovery) Date: Wed, 3 Apr 2002 10:47: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 Hi Charlie, > Well, I don't see this. The target router could well be determined > by current conditions (load, bandwidth availability, etc.) and that > does not necessarily depend on the "type" of the technology. > The protocol may well be used to identify a new access router > on a different wireless medium that has roughly the same speed. > With several variations of 802.11 and Bluetooth and UMTS and > 3G coming, this is very likely. I am not very comfortable with the > term "IP characteristics", since IP pretty much has the same > characteristics no matter what the physical medium happens to > be. We know the minimum packet size, for instance. IP itself > doesn't have any delay or speed (for example) characteristics. > So it sounds to me like you see the selection basically done on link characteristics, and not something based on IP service, is that correct? > The problem you refer to as "wireless media selection" should > not be the focus of the discussion, because we don't want to select > a medium. We want to select a point of attachment to the Internet. > The medium is _not_ the message. > :-) The problem I'm trying to solve here is I have a laptop with 802.11 and GPRS and I am wandering through Ginza. The 802.11 service is not continuous, periodically it drops out. I'm watching streaming video and it's real jerky on GPRS. I'd like to know when I enter a hot spot, so I can switch to the smoother 802.11 service. The reason I'm interested in this problem (speaking here as a WG member and not the co-chair) is because, within about a year, I expect that DoCoMo could offer this capability to its customers if we had some way to interoperably do it, i.e. this is not a theoretical exercise. I believe it should be possible to accommodate this application of CAR discovery with others, but since I can see a real need for this, I would certainly like CAR discovery to solve it. I don't particularly care whether the 802.11 service is advertised as "broadband" or "WLAN" to the customer (I don't know what the Japanese term is for this kind of service due to my limited knowledge of Japanese), but, the IP stack on the laptop has got to know what interface to bring up and configure, so it has to know some kind of agreed upon name for wireless medium in order to find the interface card. Which is why I suggested "wireless medium selection". Most of the other applications of CAR discovery I've heard don't seem like they have the same time pressure for solution that this one does, but I'm certainly open to being convinced otherwise. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 14:16: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 OAA12700 for ; Wed, 3 Apr 2002 14:16: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 OAA18933; Wed, 3 Apr 2002 14:01: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 OAA18892 for ; Wed, 3 Apr 2002 14:01: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 OAA12306 for ; Wed, 3 Apr 2002 14:01: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 g33J0rI19215; Wed, 3 Apr 2002 11:00:53 -0800 (PST) Message-ID: <00ba01c1db41$a74b9470$7e6015ac@T23KEMPF> From: "James Kempf" To: Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7F@esebe004.NOE.Nokia.com> Date: Wed, 3 Apr 2002 10:59: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 Subject: [Seamoby] Re: NSIS 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 John, Seamoby is only currently chartered to do containers for CT and CAR. We are not chartered to actually specify feature contexts or descriptions of capabilities. At least, that is my reading of the current charter. jak ----- Original Message ----- From: To: Cc: Sent: Tuesday, April 02, 2002 10:20 PM Subject: RE: NSIS was:Examples of CAR discovery > Hi James, > > > What NSIS will be working on is a generalized framework, to enable > > > end to edge signaling, end to end signaling and perhaps edge to edge > > > signaling. > > > > > > For the end-to-edge signaling, the access network (maybe even the > > > access router) would/could be proxying QoS for network towards the > > > end node. > > > > > > > So it sounds to me the only issue is that NSIS would look at > > prehandoff or posthandoff end to edge (host to network?) signaling > > rather than at the time of handoff, is that right? > > I'm not sure what you mean. I will say it another way. NSIS would > not like to re-negotiate QoS after each handoff. If Seamoby could > do some work with CARD (pre-handoff) and CT (during & post-handoff) > that would make renogotiation less needed, that would be great. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 14: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 OAA12712 for ; Wed, 3 Apr 2002 14:16:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20120 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 14:16: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 OAA18933; Wed, 3 Apr 2002 14:01: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 OAA18892 for ; Wed, 3 Apr 2002 14:01: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 OAA12306 for ; Wed, 3 Apr 2002 14:01: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 g33J0rI19215; Wed, 3 Apr 2002 11:00:53 -0800 (PST) Message-ID: <00ba01c1db41$a74b9470$7e6015ac@T23KEMPF> From: "James Kempf" To: Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7F@esebe004.NOE.Nokia.com> Date: Wed, 3 Apr 2002 10:59: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 Subject: [Seamoby] Re: NSIS 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 John, Seamoby is only currently chartered to do containers for CT and CAR. We are not chartered to actually specify feature contexts or descriptions of capabilities. At least, that is my reading of the current charter. jak ----- Original Message ----- From: To: Cc: Sent: Tuesday, April 02, 2002 10:20 PM Subject: RE: NSIS was:Examples of CAR discovery > Hi James, > > > What NSIS will be working on is a generalized framework, to enable > > > end to edge signaling, end to end signaling and perhaps edge to edge > > > signaling. > > > > > > For the end-to-edge signaling, the access network (maybe even the > > > access router) would/could be proxying QoS for network towards the > > > end node. > > > > > > > So it sounds to me the only issue is that NSIS would look at > > prehandoff or posthandoff end to edge (host to network?) signaling > > rather than at the time of handoff, is that right? > > I'm not sure what you mean. I will say it another way. NSIS would > not like to re-negotiate QoS after each handoff. If Seamoby could > do some work with CARD (pre-handoff) and CT (during & post-handoff) > that would make renogotiation less needed, that would be great. > > John > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 14:20: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 OAA12914 for ; Wed, 3 Apr 2002 14:20: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 OAA19253; Wed, 3 Apr 2002 14:03: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 OAA19223 for ; Wed, 3 Apr 2002 14:03: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 OAA12344 for ; Wed, 3 Apr 2002 14:03: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 g33J2gI19277; Wed, 3 Apr 2002 11:02:43 -0800 (PST) Message-ID: <00d201c1db41$e8d5d6d0$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D77@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 3 Apr 2002 11:01: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 John, I've got no problem with your wording. I see no consequential difference between the two. jak ----- Original Message ----- From: To: Sent: Tuesday, April 02, 2002 10:35 PM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > Hi all, > > Catching up on some mails: > > > > 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. > > I'd disagree on 3.4 & 3.x. What I think we want is the CARD protocol > to be ABLE to the able requirements, I don't think we want to mandate > the behavior. My preference would be: > > 3.4 The CAR discovery protocol MUST be able to provide the MN with GAAR > information along with capabilities. > > 3.x The CAR discovery protocol MUST be able to make efficient use of the > network resources and SHOULD avoid the transmission of unnecessary > information. > > I strongly think that requirements in the IETF should not get into dictating > protocol behavior, but be more involved in the capabilities of protocols. > > 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@ns.ietf.org Wed Apr 3 14:20: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 OAA12927 for ; Wed, 3 Apr 2002 14:20:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20257 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 14: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 OAA19253; Wed, 3 Apr 2002 14:03: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 OAA19223 for ; Wed, 3 Apr 2002 14:03: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 OAA12344 for ; Wed, 3 Apr 2002 14:03: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 g33J2gI19277; Wed, 3 Apr 2002 11:02:43 -0800 (PST) Message-ID: <00d201c1db41$e8d5d6d0$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64D77@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of Date: Wed, 3 Apr 2002 11:01: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 John, I've got no problem with your wording. I see no consequential difference between the two. jak ----- Original Message ----- From: To: Sent: Tuesday, April 02, 2002 10:35 PM Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of > Hi all, > > Catching up on some mails: > > > > 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. > > I'd disagree on 3.4 & 3.x. What I think we want is the CARD protocol > to be ABLE to the able requirements, I don't think we want to mandate > the behavior. My preference would be: > > 3.4 The CAR discovery protocol MUST be able to provide the MN with GAAR > information along with capabilities. > > 3.x The CAR discovery protocol MUST be able to make efficient use of the > network resources and SHOULD avoid the transmission of unnecessary > information. > > I strongly think that requirements in the IETF should not get into dictating > protocol behavior, but be more involved in the capabilities of protocols. > > 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 Wed Apr 3 14:31: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 OAA13370 for ; Wed, 3 Apr 2002 14: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 OAA19984; Wed, 3 Apr 2002 14:15: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 OAA19953 for ; Wed, 3 Apr 2002 14:15:22 -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 OAA12664 for ; Wed, 3 Apr 2002 14:15:18 -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 LAA06507; Wed, 3 Apr 2002 11:14:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33JEoj05879; Wed, 3 Apr 2002 11:14:50 -0800 X-mProtect: <200204031914> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOYGwRp; Wed, 03 Apr 2002 11:14:48 PST Message-ID: <3CAB54A8.C779DA91@iprg.nokia.com> Date: Wed, 03 Apr 2002 11:14:48 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery References: <9FBD322B7824D511B36900508BF93C9C01AA49A0@zcard031.ca.nortel.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 Hello Gary, This is all fine with me. Presumably, the design of the access router that is involved with CAR discovery will take into account anything more that is needed for EF and so on, although I thought EF itself was more properly a queue managment feature than a bandwidth-reservation feature. Anyway, by the time we get down to brass tacks to design the actual QoS descriptor, I reckon we'll find answers for these problems. As far as policing goes, I thought that was mainly an issue at the edge anyway. If the handover is between domains, this will be an issue, but I reckon it's solvable. From the standpoint of the mobile node, the _mechanisms_ by which QoS is determined to be available for the mobile node at the candidate access router can be outside the scope of the CAR discovery protocol itself. Various access networks might use completely different methods to make this determination. However, from the standpoint of the access routers themselves, specific choices have to be made. I'd be just as happy to leave out EF for now myself, since that is a per-hop thing and two access routers could both be neighboring the same mobile node, and yet have multiple hops between themselves otherwise. Regards, Charlie P. Regards, Charlie P. > Gary Kenward wrote: > > Charlie: > > Since we are talking about QoS mechanisms such as DS and IS, queue > congestion > isn't the only issue. There needs to be filtering/policing resources available > > (and assigned), and bandwidth allocated for specific services (such as, for > example, EF). > > Or have I misinterpreted what you mean by "congestion"? > > Gary > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: April 3, 2002 12:47 > > To: brunner@ccrle.nec.de > > Cc: seamoby@ietf.org > > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > > > Hello Marcus, > > > > Marcus Brunner wrote: > > > > > I agree that CT might help for a good solution. However, > > for the QoS part, > > > it is not only about a CT from one acess to anouther, but > > also about the > > > rest of the path providing guarantees involved, where (as far as I > > > understood the CT work) context transfer itself does not > > help too much. > > > > My first model of the access networks is that they are not > > congested, and can move packets back and forth between access > > routers without problems. This isn't always true, of course, > > but it is good enough to get us started. Under this model, > > then we can get good mileage out of using QoS as just another > > context to be transferred, as long as the new access router > > has enough spare capacity over the air to satisfy the QoS > > needs of the mobile node. > > > > If the access networks themselves are constrained, then the > > CAR discovery operation would have to be augmented by operations > > to insure availability of capacity between the old and new > > access routers, but I don't see that we have to design for that > > case right now. Moreover, I think that whatever design we come > > up with, will be easily extendible whenever it needs to be extended > > to cover the more constrained access networks. > > > > 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@ns.ietf.org Wed Apr 3 14:31: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 OAA13380 for ; Wed, 3 Apr 2002 14:31:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21030 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 14:31: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 OAA19984; Wed, 3 Apr 2002 14:15: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 OAA19953 for ; Wed, 3 Apr 2002 14:15:22 -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 OAA12664 for ; Wed, 3 Apr 2002 14:15:18 -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 LAA06507; Wed, 3 Apr 2002 11:14:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g33JEoj05879; Wed, 3 Apr 2002 11:14:50 -0800 X-mProtect: <200204031914> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOYGwRp; Wed, 03 Apr 2002 11:14:48 PST Message-ID: <3CAB54A8.C779DA91@iprg.nokia.com> Date: Wed, 03 Apr 2002 11:14:48 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery References: <9FBD322B7824D511B36900508BF93C9C01AA49A0@zcard031.ca.nortel.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 Hello Gary, This is all fine with me. Presumably, the design of the access router that is involved with CAR discovery will take into account anything more that is needed for EF and so on, although I thought EF itself was more properly a queue managment feature than a bandwidth-reservation feature. Anyway, by the time we get down to brass tacks to design the actual QoS descriptor, I reckon we'll find answers for these problems. As far as policing goes, I thought that was mainly an issue at the edge anyway. If the handover is between domains, this will be an issue, but I reckon it's solvable. From the standpoint of the mobile node, the _mechanisms_ by which QoS is determined to be available for the mobile node at the candidate access router can be outside the scope of the CAR discovery protocol itself. Various access networks might use completely different methods to make this determination. However, from the standpoint of the access routers themselves, specific choices have to be made. I'd be just as happy to leave out EF for now myself, since that is a per-hop thing and two access routers could both be neighboring the same mobile node, and yet have multiple hops between themselves otherwise. Regards, Charlie P. Regards, Charlie P. > Gary Kenward wrote: > > Charlie: > > Since we are talking about QoS mechanisms such as DS and IS, queue > congestion > isn't the only issue. There needs to be filtering/policing resources available > > (and assigned), and bandwidth allocated for specific services (such as, for > example, EF). > > Or have I misinterpreted what you mean by "congestion"? > > Gary > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: April 3, 2002 12:47 > > To: brunner@ccrle.nec.de > > Cc: seamoby@ietf.org > > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > > > Hello Marcus, > > > > Marcus Brunner wrote: > > > > > I agree that CT might help for a good solution. However, > > for the QoS part, > > > it is not only about a CT from one acess to anouther, but > > also about the > > > rest of the path providing guarantees involved, where (as far as I > > > understood the CT work) context transfer itself does not > > help too much. > > > > My first model of the access networks is that they are not > > congested, and can move packets back and forth between access > > routers without problems. This isn't always true, of course, > > but it is good enough to get us started. Under this model, > > then we can get good mileage out of using QoS as just another > > context to be transferred, as long as the new access router > > has enough spare capacity over the air to satisfy the QoS > > needs of the mobile node. > > > > If the access networks themselves are constrained, then the > > CAR discovery operation would have to be augmented by operations > > to insure availability of capacity between the old and new > > access routers, but I don't see that we have to design for that > > case right now. Moreover, I think that whatever design we come > > up with, will be easily extendible whenever it needs to be extended > > to cover the more constrained access networks. > > > > 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 Wed Apr 3 14:31: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 OAA13368 for ; Wed, 3 Apr 2002 14:31: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 OAA20116; Wed, 3 Apr 2002 14:16: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 OAA20049 for ; Wed, 3 Apr 2002 14:16: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 OAA12698 for ; Wed, 3 Apr 2002 14:16: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 g33JFoI19731; Wed, 3 Apr 2002 11:15:50 -0800 (PST) Message-ID: <014301c1db43$be00a690$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4994@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:14: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 Gary, I disagree about your assessment of the near term prospects for CAR, see my earlier note to Charlie. But I agree that CT has wider applicability, because it may be used in cases where the next access router is deterministically selected by the Layer 2 protocol due to timing considerations. I also see the two as separate and, to a certain extent complimentary in function. But the process question of "how do we standardize the contents?" is a similar one, though the answer may differ for the two. jak ----- Original Message ----- From: "Gary Kenward" To: ; Cc: Sent: Wednesday, April 03, 2002 6:37 AM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > John, et al: > > As far as I am concerned, we worked hard on defining CT requirements to be > "proactive": > that is, happening "before" a handoff. Has CAR now supplanted this > capability in > everyones mind? If so, then I think the main value of CT has been lost. > > Here's an observation for everyone to consider: in the manner that CAR (and > TARS) is > being talked about, there is an implication that the mobile will have a > choice of > channels to handover to. These channels are to be differentiated by the > services and > QoS that they provide. It is hard, at this point, to see that this will be > the norm > for near future. Yes, if 802.11 is used for "hot spot coverage", there will > very likely > be overlap with cellular channels, but the need to make a choice for one > over the other > (if based upon QoS parameters like bandwidth, then the choice will almost > always be > 802.11), will be rare. > > On the other hand, if there is *any* opportunity to handover, then CT can be > employed > to improve the handover. > > In short, CT has a wider applicability and benefit to improving handover > performance, whereas, > CAR has a limited applicability, particularly in the short term. > > Cheers, > Gary > > PS: I think it that everyone should be concerned that the definition of CAR > is being massaged > into a being a replacement for the proposal to perform CT from MN to access > network - a concept > that the working group did not favour, for many good, technical, reasons. > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: April 3, 2002 01:21 > > To: kempf@docomolabs-usa.com > > Cc: seamoby@ietf.org > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > Hi James, > > > > What NSIS will be working on is a generalized framework, to enable > > > > end to edge signaling, end to end signaling and perhaps > > edge to edge > > > > signaling. > > > > > > > > For the end-to-edge signaling, the access network (maybe even the > > > > access router) would/could be proxying QoS for network > > towards the > > > > end node. > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > prehandoff or posthandoff end to edge (host to network?) signaling > > > rather than at the time of handoff, is that right? > > > > I'm not sure what you mean. I will say it another way. NSIS would > > not like to re-negotiate QoS after each handoff. If Seamoby could > > do some work with CARD (pre-handoff) and CT (during & post-handoff) > > that would make renogotiation less needed, that would be great. > > > > 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@ns.ietf.org Wed Apr 3 14:31: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 OAA13414 for ; Wed, 3 Apr 2002 14:31:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21052 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 14: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 OAA20116; Wed, 3 Apr 2002 14:16: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 OAA20049 for ; Wed, 3 Apr 2002 14:16: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 OAA12698 for ; Wed, 3 Apr 2002 14:16: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 g33JFoI19731; Wed, 3 Apr 2002 11:15:50 -0800 (PST) Message-ID: <014301c1db43$be00a690$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA4994@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:14: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 Gary, I disagree about your assessment of the near term prospects for CAR, see my earlier note to Charlie. But I agree that CT has wider applicability, because it may be used in cases where the next access router is deterministically selected by the Layer 2 protocol due to timing considerations. I also see the two as separate and, to a certain extent complimentary in function. But the process question of "how do we standardize the contents?" is a similar one, though the answer may differ for the two. jak ----- Original Message ----- From: "Gary Kenward" To: ; Cc: Sent: Wednesday, April 03, 2002 6:37 AM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > John, et al: > > As far as I am concerned, we worked hard on defining CT requirements to be > "proactive": > that is, happening "before" a handoff. Has CAR now supplanted this > capability in > everyones mind? If so, then I think the main value of CT has been lost. > > Here's an observation for everyone to consider: in the manner that CAR (and > TARS) is > being talked about, there is an implication that the mobile will have a > choice of > channels to handover to. These channels are to be differentiated by the > services and > QoS that they provide. It is hard, at this point, to see that this will be > the norm > for near future. Yes, if 802.11 is used for "hot spot coverage", there will > very likely > be overlap with cellular channels, but the need to make a choice for one > over the other > (if based upon QoS parameters like bandwidth, then the choice will almost > always be > 802.11), will be rare. > > On the other hand, if there is *any* opportunity to handover, then CT can be > employed > to improve the handover. > > In short, CT has a wider applicability and benefit to improving handover > performance, whereas, > CAR has a limited applicability, particularly in the short term. > > Cheers, > Gary > > PS: I think it that everyone should be concerned that the definition of CAR > is being massaged > into a being a replacement for the proposal to perform CT from MN to access > network - a concept > that the working group did not favour, for many good, technical, reasons. > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: April 3, 2002 01:21 > > To: kempf@docomolabs-usa.com > > Cc: seamoby@ietf.org > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > Hi James, > > > > What NSIS will be working on is a generalized framework, to enable > > > > end to edge signaling, end to end signaling and perhaps > > edge to edge > > > > signaling. > > > > > > > > For the end-to-edge signaling, the access network (maybe even the > > > > access router) would/could be proxying QoS for network > > towards the > > > > end node. > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > prehandoff or posthandoff end to edge (host to network?) signaling > > > rather than at the time of handoff, is that right? > > > > I'm not sure what you mean. I will say it another way. NSIS would > > not like to re-negotiate QoS after each handoff. If Seamoby could > > do some work with CARD (pre-handoff) and CT (during & post-handoff) > > that would make renogotiation less needed, that would be great. > > > > 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 Wed Apr 3 14: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 OAA13606 for ; Wed, 3 Apr 2002 14: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 OAA20525; Wed, 3 Apr 2002 14:26: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 OAA20494 for ; Wed, 3 Apr 2002 14:26: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 OAA13101 for ; Wed, 3 Apr 2002 14:26: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 g33JPLI20079; Wed, 3 Apr 2002 11:25:21 -0800 (PST) Message-ID: <018601c1db45$126c5340$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 3 Apr 2002 11:23: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 Dirk, > [DOT] It is not only about the 'containers' to get standardized. Designing > a carrier protocol without considering the information to be carried might quickly serve as a > bad example of engineering. In other words, making a decision about sending > information from and to different entities without considering WHAT (semantics) > and HOW MUCH (semantics plus syntax) is shuffled around might lead very soon > after the actual standardization of CAR discovery to the proof of its uselessness > rather than its usefulness, if the way the protocol is designed restricts the amount > of information that could be carried. > > [DOT] In particular due to the involvement of mobile devices, this amount of information > is a crucial factor in designing the protocol. Hence, a proper consideration > of this information (what is this information and how is this information represented) > should be a must for us to study before we make decisions on the design of the > final solution. > I didn't say we shouldn't consider the contents, I just said that the charter currently doesn't cover standardizing them. Of course, we do need to consider the contents when doing the design. We did that with SLP and I'm sure they did it with LDAP. We do, however, need to say something in the RFCs on CT and CAR about how we propose to standardize the contents if Seamoby won't do it. Or, if Semaboy will, then we need to talk to Allison about rechartering. But we are a long ways away from that right now, IMHO. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 14: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 OAA13617 for ; Wed, 3 Apr 2002 14:38:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21416 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 14:38: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 OAA20525; Wed, 3 Apr 2002 14:26: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 OAA20494 for ; Wed, 3 Apr 2002 14:26: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 OAA13101 for ; Wed, 3 Apr 2002 14:26: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 g33JPLI20079; Wed, 3 Apr 2002 11:25:21 -0800 (PST) Message-ID: <018601c1db45$126c5340$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: Subject: Re: [Seamoby] Examples of CAR discovery Date: Wed, 3 Apr 2002 11:23: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 Dirk, > [DOT] It is not only about the 'containers' to get standardized. Designing > a carrier protocol without considering the information to be carried might quickly serve as a > bad example of engineering. In other words, making a decision about sending > information from and to different entities without considering WHAT (semantics) > and HOW MUCH (semantics plus syntax) is shuffled around might lead very soon > after the actual standardization of CAR discovery to the proof of its uselessness > rather than its usefulness, if the way the protocol is designed restricts the amount > of information that could be carried. > > [DOT] In particular due to the involvement of mobile devices, this amount of information > is a crucial factor in designing the protocol. Hence, a proper consideration > of this information (what is this information and how is this information represented) > should be a must for us to study before we make decisions on the design of the > final solution. > I didn't say we shouldn't consider the contents, I just said that the charter currently doesn't cover standardizing them. Of course, we do need to consider the contents when doing the design. We did that with SLP and I'm sure they did it with LDAP. We do, however, need to say something in the RFCs on CT and CAR about how we propose to standardize the contents if Seamoby won't do it. Or, if Semaboy will, then we need to talk to Allison about rechartering. But we are a long ways away from that right now, IMHO. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 15:00: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 PAA14119 for ; Wed, 3 Apr 2002 15:00: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 OAA21914; Wed, 3 Apr 2002 14:45: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 OAA21886 for ; Wed, 3 Apr 2002 14:45:51 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13827 for ; Wed, 3 Apr 2002 14:45:47 -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 g33Jf0S23401; Wed, 3 Apr 2002 14:41:01 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 14:41:02 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , "'James Kempf'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 14:40:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB47.79FF73F0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB47.79FF73F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Charlie: EF was just an example, and to clarify, it is a queue management feature, but in order to fulfill the EF PHB criteria, certain bandwidth constraints have to be met (e.g. if you cram 400 people into first class on a 747, it will be hard to provide first class service;=20 likewise, it would be hard for a flight crew to provide first class service to everyone on a 747). I guess my point of view is that the real tough problems that need to be solved for all of this to work are out of scope. Which makes it seem somewhat like the old clich=E9 for building cities in the sky:=20 "first, assume that we have developed anti-gravity . . . ". On the other hand, I would not want to get in the way of creating enablers for this functions to be solved. Like I said, I'm not against CAR, I just want to make sure that we (Seamoby) have clearly identified the alternative approach. Just asking, Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 3, 2002 14:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery >=20 >=20 >=20 > Hello Gary, >=20 > This is all fine with me. Presumably, the design of the > access router that is involved with CAR discovery will take > into account anything more that is needed for EF and so on, > although I thought EF itself was more properly a queue > managment feature than a bandwidth-reservation feature. > Anyway, by the time we get down to brass tacks to design > the actual QoS descriptor, I reckon we'll find answers for > these problems. As far as policing goes, I thought that > was mainly an issue at the edge anyway. If the handover is > between domains, this will be an issue, but I reckon it's > solvable. >=20 > From the standpoint of the mobile node, the _mechanisms_ by > which QoS is determined to be available for the mobile node > at the candidate access router can be outside the scope of > the CAR discovery protocol itself. Various access networks > might use completely different methods to make this determination. > However, from the standpoint of the access routers themselves, > specific choices have to be made. >=20 > I'd be just as happy to leave out EF for now myself, since > that is a per-hop thing and two access routers could both be > neighboring the same mobile node, and yet have multiple > hops between themselves otherwise. >=20 > Regards, > Charlie P. >=20 >=20 > Regards, > Charlie P. >=20 >=20 > > Gary Kenward wrote: > >=20 > > Charlie: > >=20 > > Since we are talking about QoS mechanisms such as DS and=20 > IS, queue > > congestion > > isn't the only issue. There needs to be filtering/policing=20 > resources available > >=20 > > (and assigned), and bandwidth allocated for specific=20 > services (such as, for > > example, EF). > >=20 > > Or have I misinterpreted what you mean by "congestion"? > >=20 > > Gary > >=20 > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: April 3, 2002 12:47 > > > To: brunner@ccrle.nec.de > > > Cc: seamoby@ietf.org > > > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > > > > > > > Hello Marcus, > > > > > > Marcus Brunner wrote: > > > > > > > I agree that CT might help for a good solution. However, > > > for the QoS part, > > > > it is not only about a CT from one acess to anouther, but > > > also about the > > > > rest of the path providing guarantees involved, where=20 > (as far as I > > > > understood the CT work) context transfer itself does not > > > help too much. > > > > > > My first model of the access networks is that they are not > > > congested, and can move packets back and forth between access > > > routers without problems. This isn't always true, of course, > > > but it is good enough to get us started. Under this model, > > > then we can get good mileage out of using QoS as just another > > > context to be transferred, as long as the new access router > > > has enough spare capacity over the air to satisfy the QoS > > > needs of the mobile node. > > > > > > If the access networks themselves are constrained, then the > > > CAR discovery operation would have to be augmented by operations > > > to insure availability of capacity between the old and new > > > access routers, but I don't see that we have to design for that > > > case right now. Moreover, I think that whatever design we come > > > up with, will be easily extendible whenever it needs to=20 > be extended > > > to cover the more constrained access networks. > > > > > > Regards, > > > Charlie P. > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >=20 ------_=_NextPart_001_01C1DB47.79FF73F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] NSIS was:Examples of CAR discovery

Charlie:

  EF was just an example, and to clarify, it is = a queue management
feature, but in order to fulfill the EF PHB = criteria, certain
bandwidth constraints have to be met (e.g. if you = cram 400 people into
first class on a 747, it will be hard to provide = first class service;
likewise, it would be hard for a flight crew to = provide first class
service to everyone on a 747).

  I guess my point of view is that the real = tough problems that need
to be solved for all of this to work are out of = scope. Which makes it
seem somewhat like the old clich=E9 for building = cities in the sky:
"first, assume that we have developed = anti-gravity . . . ".

  On the other hand, I would not want to get in = the way of creating
enablers for this functions to be solved. Like I = said, I'm not against
CAR, I just want to make sure that we (Seamoby) have = clearly identified
the alternative approach.

Just asking,
Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 3, 2002 14:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR = discovery
>
>
>
> Hello Gary,
>
> This is all fine with me.  Presumably, the = design of the
> access router that is involved with CAR = discovery will take
> into account anything more that is needed for = EF and so on,
> although I thought EF itself was more properly = a queue
> managment feature than a bandwidth-reservation = feature.
> Anyway, by the time we get down to brass tacks = to design
> the actual QoS descriptor, I reckon we'll find = answers for
> these problems.  As far as policing goes, = I thought that
> was mainly an issue at the edge anyway.  = If the handover is
> between domains, this will be an issue, but I = reckon it's
> solvable.
>
> From the standpoint of the mobile node, the = _mechanisms_ by
> which QoS is determined to be available for the = mobile node
> at the candidate access router can be outside = the scope of
> the CAR discovery protocol itself.  = Various access networks
> might use completely different methods to make = this determination.
> However, from the standpoint of the access = routers themselves,
> specific choices have to be made.
>
> I'd be just as happy to leave out EF for now = myself, since
> that is a per-hop thing and two access routers = could both be
> neighboring the same mobile node, and yet have = multiple
> hops between themselves otherwise.
>
> Regards,
> Charlie P.
>
>
> Regards,
> Charlie P.
>
>
> > Gary Kenward wrote:
> >
> > Charlie:
> >
> >    Since we are talking = about QoS mechanisms such as DS and
> IS, queue
> > congestion
> > isn't the only issue. There needs to be = filtering/policing
> resources available
> >
> > (and assigned), and bandwidth allocated = for specific
> services (such as, for
> > example, EF).
> >
> >    Or have I misinterpreted = what you mean by "congestion"?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> > > Sent: April 3, 2002 12:47
> > > To: brunner@ccrle.nec.de
> > > Cc: seamoby@ietf.org
> > > Subject: Re: [Seamoby] NSIS = was:Examples of CAR discovery
> > >
> > >
> > >
> > > Hello Marcus,
> > >
> > > Marcus Brunner wrote:
> > >
> > > > I agree that CT might help for a = good solution. However,
> > > for the QoS part,
> > > > it is not only about a CT from = one acess to anouther, but
> > > also about the
> > > > rest of the path providing = guarantees involved, where
> (as far as I
> > > > understood the CT work) context = transfer itself does not
> > > help too much.
> > >
> > > My first model of the access networks = is that they are not
> > > congested, and can move packets back = and forth between access
> > > routers without problems.  This = isn't always true, of course,
> > > but it is good enough to get us = started.  Under this model,
> > > then we can get good mileage out of = using QoS as just another
> > > context to be transferred, as long as = the new access router
> > > has enough spare capacity over the = air to satisfy the QoS
> > > needs of the mobile node.
> > >
> > > If the access networks themselves are = constrained, then the
> > > CAR discovery operation would have to = be augmented by operations
> > > to insure availability of capacity = between the old and new
> > > access routers, but I don't see that = we have to design for that
> > > case right now.  Moreover, I = think that whatever design we come
> > > up with, will be easily extendible = whenever it needs to
> be extended
> > > to cover the more constrained access = networks.
> > >
> > > Regards,
> > > Charlie P.
> > >
> > > = _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
>

------_=_NextPart_001_01C1DB47.79FF73F0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 15:00: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 PAA14146 for ; Wed, 3 Apr 2002 15:00:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22599 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 15:00: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 OAA21914; Wed, 3 Apr 2002 14:45: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 OAA21886 for ; Wed, 3 Apr 2002 14:45:51 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13827 for ; Wed, 3 Apr 2002 14:45:47 -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 g33Jf0S23401; Wed, 3 Apr 2002 14:41:01 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 14:41:02 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , "'James Kempf'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 14:40:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB47.79FF73F0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB47.79FF73F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Charlie: EF was just an example, and to clarify, it is a queue management feature, but in order to fulfill the EF PHB criteria, certain bandwidth constraints have to be met (e.g. if you cram 400 people into first class on a 747, it will be hard to provide first class service;=20 likewise, it would be hard for a flight crew to provide first class service to everyone on a 747). I guess my point of view is that the real tough problems that need to be solved for all of this to work are out of scope. Which makes it seem somewhat like the old clich=E9 for building cities in the sky:=20 "first, assume that we have developed anti-gravity . . . ". On the other hand, I would not want to get in the way of creating enablers for this functions to be solved. Like I said, I'm not against CAR, I just want to make sure that we (Seamoby) have clearly identified the alternative approach. Just asking, Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 3, 2002 14:15 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery >=20 >=20 >=20 > Hello Gary, >=20 > This is all fine with me. Presumably, the design of the > access router that is involved with CAR discovery will take > into account anything more that is needed for EF and so on, > although I thought EF itself was more properly a queue > managment feature than a bandwidth-reservation feature. > Anyway, by the time we get down to brass tacks to design > the actual QoS descriptor, I reckon we'll find answers for > these problems. As far as policing goes, I thought that > was mainly an issue at the edge anyway. If the handover is > between domains, this will be an issue, but I reckon it's > solvable. >=20 > From the standpoint of the mobile node, the _mechanisms_ by > which QoS is determined to be available for the mobile node > at the candidate access router can be outside the scope of > the CAR discovery protocol itself. Various access networks > might use completely different methods to make this determination. > However, from the standpoint of the access routers themselves, > specific choices have to be made. >=20 > I'd be just as happy to leave out EF for now myself, since > that is a per-hop thing and two access routers could both be > neighboring the same mobile node, and yet have multiple > hops between themselves otherwise. >=20 > Regards, > Charlie P. >=20 >=20 > Regards, > Charlie P. >=20 >=20 > > Gary Kenward wrote: > >=20 > > Charlie: > >=20 > > Since we are talking about QoS mechanisms such as DS and=20 > IS, queue > > congestion > > isn't the only issue. There needs to be filtering/policing=20 > resources available > >=20 > > (and assigned), and bandwidth allocated for specific=20 > services (such as, for > > example, EF). > >=20 > > Or have I misinterpreted what you mean by "congestion"? > >=20 > > Gary > >=20 > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: April 3, 2002 12:47 > > > To: brunner@ccrle.nec.de > > > Cc: seamoby@ietf.org > > > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > > > > > > > Hello Marcus, > > > > > > Marcus Brunner wrote: > > > > > > > I agree that CT might help for a good solution. However, > > > for the QoS part, > > > > it is not only about a CT from one acess to anouther, but > > > also about the > > > > rest of the path providing guarantees involved, where=20 > (as far as I > > > > understood the CT work) context transfer itself does not > > > help too much. > > > > > > My first model of the access networks is that they are not > > > congested, and can move packets back and forth between access > > > routers without problems. This isn't always true, of course, > > > but it is good enough to get us started. Under this model, > > > then we can get good mileage out of using QoS as just another > > > context to be transferred, as long as the new access router > > > has enough spare capacity over the air to satisfy the QoS > > > needs of the mobile node. > > > > > > If the access networks themselves are constrained, then the > > > CAR discovery operation would have to be augmented by operations > > > to insure availability of capacity between the old and new > > > access routers, but I don't see that we have to design for that > > > case right now. Moreover, I think that whatever design we come > > > up with, will be easily extendible whenever it needs to=20 > be extended > > > to cover the more constrained access networks. > > > > > > Regards, > > > Charlie P. > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > >=20 ------_=_NextPart_001_01C1DB47.79FF73F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] NSIS was:Examples of CAR discovery

Charlie:

  EF was just an example, and to clarify, it is = a queue management
feature, but in order to fulfill the EF PHB = criteria, certain
bandwidth constraints have to be met (e.g. if you = cram 400 people into
first class on a 747, it will be hard to provide = first class service;
likewise, it would be hard for a flight crew to = provide first class
service to everyone on a 747).

  I guess my point of view is that the real = tough problems that need
to be solved for all of this to work are out of = scope. Which makes it
seem somewhat like the old clich=E9 for building = cities in the sky:
"first, assume that we have developed = anti-gravity . . . ".

  On the other hand, I would not want to get in = the way of creating
enablers for this functions to be solved. Like I = said, I'm not against
CAR, I just want to make sure that we (Seamoby) have = clearly identified
the alternative approach.

Just asking,
Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 3, 2002 14:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR = discovery
>
>
>
> Hello Gary,
>
> This is all fine with me.  Presumably, the = design of the
> access router that is involved with CAR = discovery will take
> into account anything more that is needed for = EF and so on,
> although I thought EF itself was more properly = a queue
> managment feature than a bandwidth-reservation = feature.
> Anyway, by the time we get down to brass tacks = to design
> the actual QoS descriptor, I reckon we'll find = answers for
> these problems.  As far as policing goes, = I thought that
> was mainly an issue at the edge anyway.  = If the handover is
> between domains, this will be an issue, but I = reckon it's
> solvable.
>
> From the standpoint of the mobile node, the = _mechanisms_ by
> which QoS is determined to be available for the = mobile node
> at the candidate access router can be outside = the scope of
> the CAR discovery protocol itself.  = Various access networks
> might use completely different methods to make = this determination.
> However, from the standpoint of the access = routers themselves,
> specific choices have to be made.
>
> I'd be just as happy to leave out EF for now = myself, since
> that is a per-hop thing and two access routers = could both be
> neighboring the same mobile node, and yet have = multiple
> hops between themselves otherwise.
>
> Regards,
> Charlie P.
>
>
> Regards,
> Charlie P.
>
>
> > Gary Kenward wrote:
> >
> > Charlie:
> >
> >    Since we are talking = about QoS mechanisms such as DS and
> IS, queue
> > congestion
> > isn't the only issue. There needs to be = filtering/policing
> resources available
> >
> > (and assigned), and bandwidth allocated = for specific
> services (such as, for
> > example, EF).
> >
> >    Or have I misinterpreted = what you mean by "congestion"?
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> > > Sent: April 3, 2002 12:47
> > > To: brunner@ccrle.nec.de
> > > Cc: seamoby@ietf.org
> > > Subject: Re: [Seamoby] NSIS = was:Examples of CAR discovery
> > >
> > >
> > >
> > > Hello Marcus,
> > >
> > > Marcus Brunner wrote:
> > >
> > > > I agree that CT might help for a = good solution. However,
> > > for the QoS part,
> > > > it is not only about a CT from = one acess to anouther, but
> > > also about the
> > > > rest of the path providing = guarantees involved, where
> (as far as I
> > > > understood the CT work) context = transfer itself does not
> > > help too much.
> > >
> > > My first model of the access networks = is that they are not
> > > congested, and can move packets back = and forth between access
> > > routers without problems.  This = isn't always true, of course,
> > > but it is good enough to get us = started.  Under this model,
> > > then we can get good mileage out of = using QoS as just another
> > > context to be transferred, as long as = the new access router
> > > has enough spare capacity over the = air to satisfy the QoS
> > > needs of the mobile node.
> > >
> > > If the access networks themselves are = constrained, then the
> > > CAR discovery operation would have to = be augmented by operations
> > > to insure availability of capacity = between the old and new
> > > access routers, but I don't see that = we have to design for that
> > > case right now.  Moreover, I = think that whatever design we come
> > > up with, will be easily extendible = whenever it needs to
> be extended
> > > to cover the more constrained access = networks.
> > >
> > > Regards,
> > > Charlie P.
> > >
> > > = _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
>

------_=_NextPart_001_01C1DB47.79FF73F0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 15:02: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 PAA14201 for ; Wed, 3 Apr 2002 15: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 OAA21712; Wed, 3 Apr 2002 14: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 OAA21682 for ; Wed, 3 Apr 2002 14:43: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 OAA13758 for ; Wed, 3 Apr 2002 14:43:29 -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 g33Jg1I20754; Wed, 3 Apr 2002 11:42:01 -0800 (PST) Message-ID: <01b401c1db47$666a2d80$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA499F@zcard031.ca.nortel.com> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:40:24 -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 Gary, I don't see any overlap if the time constants are different. That is, the QoS query might occur just prior to handover, while CAR might happen sometime alot more distant from handover. jak ----- Original Message ----- From: "Gary Kenward" To: Cc: Sent: Wednesday, April 03, 2002 9:41 AM Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > John: > > Clearly there is an overlap as all three solutions, CT, CAR and > NSIS are dealing with QoS. > > I was content to let this thread drop until I came across the following > requirement in re-reading draft-ietf-nsis-req-00.txt: > > "5.1.2 Resource availability information on request > > In some scenarios, e.g., the mobile terminal scenario, it is > required to query, whether resources are available, without > performing a reservation on the resource. One solution might be a > feedback mechanism based on which a QoS inferred handover can take > place." > > There seems to be some overlap in functionality here. Alternative solutions > are usually great choices to have, but clearly the conversation on the > respective > roles of NSIS and CAR must continue. > > Gary > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: April 3, 2002 12:13 > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: seamoby@ietf.org > > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > Hi Gary, > > > > > I tried to find the email that discussed "centralized QoS", or > > > "proxies". Can you elaborate where these threads originated? > > > Gary > > > PS: Since this is about CT, I am following it up on the > > Seamoby list. > > > > My comment was about NSIS, not about CT so I don't think this > > conversation is really of relevance to SeaMoby. If the signaling > > path is not along the data path, then NSIS signaling > > probably would not need CT. If you see how CT could be used, please > > let us know, especially on the NSIS list. > > > > John > > > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was > > at a SeaMoby meeting when an NSIS discussion broke out.' > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 15:02: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 PAA14216 for ; Wed, 3 Apr 2002 15:02:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22982 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 15: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 OAA21712; Wed, 3 Apr 2002 14: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 OAA21682 for ; Wed, 3 Apr 2002 14:43: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 OAA13758 for ; Wed, 3 Apr 2002 14:43:29 -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 g33Jg1I20754; Wed, 3 Apr 2002 11:42:01 -0800 (PST) Message-ID: <01b401c1db47$666a2d80$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA499F@zcard031.ca.nortel.com> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 11:40:24 -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 Gary, I don't see any overlap if the time constants are different. That is, the QoS query might occur just prior to handover, while CAR might happen sometime alot more distant from handover. jak ----- Original Message ----- From: "Gary Kenward" To: Cc: Sent: Wednesday, April 03, 2002 9:41 AM Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > John: > > Clearly there is an overlap as all three solutions, CT, CAR and > NSIS are dealing with QoS. > > I was content to let this thread drop until I came across the following > requirement in re-reading draft-ietf-nsis-req-00.txt: > > "5.1.2 Resource availability information on request > > In some scenarios, e.g., the mobile terminal scenario, it is > required to query, whether resources are available, without > performing a reservation on the resource. One solution might be a > feedback mechanism based on which a QoS inferred handover can take > place." > > There seems to be some overlap in functionality here. Alternative solutions > are usually great choices to have, but clearly the conversation on the > respective > roles of NSIS and CAR must continue. > > Gary > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: April 3, 2002 12:13 > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: seamoby@ietf.org > > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > Hi Gary, > > > > > I tried to find the email that discussed "centralized QoS", or > > > "proxies". Can you elaborate where these threads originated? > > > Gary > > > PS: Since this is about CT, I am following it up on the > > Seamoby list. > > > > My comment was about NSIS, not about CT so I don't think this > > conversation is really of relevance to SeaMoby. If the signaling > > path is not along the data path, then NSIS signaling > > probably would not need CT. If you see how CT could be used, please > > let us know, especially on the NSIS list. > > > > John > > > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was > > at a SeaMoby meeting when an NSIS discussion broke out.' > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 15:16: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 PAA14468 for ; Wed, 3 Apr 2002 15:16: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 OAA22338; Wed, 3 Apr 2002 14:55: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 OAA22306 for ; Wed, 3 Apr 2002 14:55:23 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13976 for ; Wed, 3 Apr 2002 14:55:19 -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 g33JsbS24375; Wed, 3 Apr 2002 14:54:37 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 14:54:38 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 14:54:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB48.767D1D26" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB48.767D1D26 Content-Type: text/plain; charset="iso-8859-1" The real overlap I was concerned with was between CT and NSIS. What is the role of NSIS with regards to handover? If NSIS is invoked to establish/negotiate QoS for a handover, what happens to the context being transferred? How are the two synchronized, or are they? Are the two compatible or mutually exclusive? I have no difficulty with offering alternate solutions for the same problem, but we should be clear that they are either alternatives or complements, and if they are the latter, how they interplay, and how the work on a stand alone basis, should we not? Anyways, I think that this is a rather minor issue at this point in time. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 14:40 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > Gary, > > I don't see any overlap if the time constants are different. That is, > the QoS query might occur just prior to handover, while CAR > might happen > sometime alot more distant from handover. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: > Cc: > Sent: Wednesday, April 03, 2002 9:41 AM > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > > John: > > > > Clearly there is an overlap as all three solutions, CT, CAR and > > NSIS are dealing with QoS. > > > > I was content to let this thread drop until I came across the > following > > requirement in re-reading draft-ietf-nsis-req-00.txt: > > > > "5.1.2 Resource availability information on request > > > > In some scenarios, e.g., the mobile terminal scenario, it is > > required to query, whether resources are available, without > > performing a reservation on the resource. One solution might be a > > feedback mechanism based on which a QoS inferred > handover can take > > place." > > > > There seems to be some overlap in functionality here. Alternative > solutions > > are usually great choices to have, but clearly the > conversation on the > > respective > > roles of NSIS and CAR must continue. > > > > Gary > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: April 3, 2002 12:13 > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: seamoby@ietf.org > > > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > > > > Hi Gary, > > > > > > > I tried to find the email that discussed "centralized QoS", or > > > > "proxies". Can you elaborate where these threads originated? > > > > Gary > > > > PS: Since this is about CT, I am following it up on the > > > Seamoby list. > > > > > > My comment was about NSIS, not about CT so I don't think this > > > conversation is really of relevance to SeaMoby. If the signaling > > > path is not along the data path, then NSIS signaling > > > probably would not need CT. If you see how CT could be > used, please > > > let us know, especially on the NSIS list. > > > > > > John > > > > > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was > > > at a SeaMoby meeting when an NSIS discussion broke out.' > > > > > > > ------_=_NextPart_001_01C1DB48.767D1D26 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

The real overlap I was concerned with was between CT and NSIS.
What is the role of NSIS with regards to handover? If NSIS is
invoked to establish/negotiate QoS for a handover, what happens
to the context being transferred? How are the two synchronized,
or are they? Are the two compatible or mutually exclusive?

I have no difficulty with offering alternate solutions for the
same problem, but we should be clear that they are either
alternatives or complements, and if they are the latter, how they
interplay, and how the work on a stand alone basis, should we not?

Anyways, I think that this is a rather minor issue at this point
in time.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 14:40
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> I don't see any overlap if the time constants are different. That is,
> the QoS query might occur just prior to handover, while CAR
> might happen
> sometime alot more distant from handover.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: <john.loughney@nokia.com>
> Cc: <seamoby@ietf.org>
> Sent: Wednesday, April 03, 2002 9:41 AM
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> > John:
> >
> >   Clearly there is an overlap as all three solutions, CT, CAR and
> > NSIS are dealing with QoS.
> >
> >   I was content to let this thread drop until I came across the
> following
> > requirement in re-reading draft-ietf-nsis-req-00.txt:
> >
> > "5.1.2 Resource availability information on request
> >
> >    In some scenarios, e.g., the mobile terminal scenario, it is
> >    required to query, whether resources are available, without
> >    performing a reservation on the resource. One solution might be a
> >    feedback mechanism based on which a QoS inferred
> handover can take
> >    place."
> >
> > There seems to be some overlap in functionality here. Alternative
> solutions
> > are usually great choices to have, but clearly the
> conversation on the
> > respective
> > roles of NSIS and CAR must continue.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > Sent: April 3, 2002 12:13
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: seamoby@ietf.org
> > > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
> > >
> > >
> > > Hi Gary,
> > >
> > > > I tried to find the email that discussed "centralized QoS", or
> > > > "proxies". Can you elaborate where these threads originated?
> > > > Gary
> > > > PS: Since this is about CT, I am following it up on the
> > > Seamoby list.
> > >
> > > My comment was about NSIS, not about CT so I don't think this
> > > conversation is really of relevance to SeaMoby.  If the signaling
> > > path is not along the data path, then NSIS signaling
> > > probably would not need CT.  If you see how CT could be
> used, please
> > > let us know, especially on the NSIS list.
> > >
> > > John
> > >
> > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was
> > > at a SeaMoby meeting when an NSIS discussion broke out.'
> > >
> >
>
>

------_=_NextPart_001_01C1DB48.767D1D26-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 15:16: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 PAA14482 for ; Wed, 3 Apr 2002 15:16:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23663 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 15:16: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 OAA22338; Wed, 3 Apr 2002 14:55: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 OAA22306 for ; Wed, 3 Apr 2002 14:55:23 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13976 for ; Wed, 3 Apr 2002 14:55:19 -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 g33JsbS24375; Wed, 3 Apr 2002 14:54:37 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 14:54:38 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 14:54:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB48.767D1D26" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB48.767D1D26 Content-Type: text/plain; charset="iso-8859-1" The real overlap I was concerned with was between CT and NSIS. What is the role of NSIS with regards to handover? If NSIS is invoked to establish/negotiate QoS for a handover, what happens to the context being transferred? How are the two synchronized, or are they? Are the two compatible or mutually exclusive? I have no difficulty with offering alternate solutions for the same problem, but we should be clear that they are either alternatives or complements, and if they are the latter, how they interplay, and how the work on a stand alone basis, should we not? Anyways, I think that this is a rather minor issue at this point in time. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 14:40 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery > > > Gary, > > I don't see any overlap if the time constants are different. That is, > the QoS query might occur just prior to handover, while CAR > might happen > sometime alot more distant from handover. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: > Cc: > Sent: Wednesday, April 03, 2002 9:41 AM > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > > John: > > > > Clearly there is an overlap as all three solutions, CT, CAR and > > NSIS are dealing with QoS. > > > > I was content to let this thread drop until I came across the > following > > requirement in re-reading draft-ietf-nsis-req-00.txt: > > > > "5.1.2 Resource availability information on request > > > > In some scenarios, e.g., the mobile terminal scenario, it is > > required to query, whether resources are available, without > > performing a reservation on the resource. One solution might be a > > feedback mechanism based on which a QoS inferred > handover can take > > place." > > > > There seems to be some overlap in functionality here. Alternative > solutions > > are usually great choices to have, but clearly the > conversation on the > > respective > > roles of NSIS and CAR must continue. > > > > Gary > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: April 3, 2002 12:13 > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: seamoby@ietf.org > > > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > > > > > > > > > Hi Gary, > > > > > > > I tried to find the email that discussed "centralized QoS", or > > > > "proxies". Can you elaborate where these threads originated? > > > > Gary > > > > PS: Since this is about CT, I am following it up on the > > > Seamoby list. > > > > > > My comment was about NSIS, not about CT so I don't think this > > > conversation is really of relevance to SeaMoby. If the signaling > > > path is not along the data path, then NSIS signaling > > > probably would not need CT. If you see how CT could be > used, please > > > let us know, especially on the NSIS list. > > > > > > John > > > > > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was > > > at a SeaMoby meeting when an NSIS discussion broke out.' > > > > > > > ------_=_NextPart_001_01C1DB48.767D1D26 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] NSIS was:Examples of CAR discovery

The real overlap I was concerned with was between CT and NSIS.
What is the role of NSIS with regards to handover? If NSIS is
invoked to establish/negotiate QoS for a handover, what happens
to the context being transferred? How are the two synchronized,
or are they? Are the two compatible or mutually exclusive?

I have no difficulty with offering alternate solutions for the
same problem, but we should be clear that they are either
alternatives or complements, and if they are the latter, how they
interplay, and how the work on a stand alone basis, should we not?

Anyways, I think that this is a rather minor issue at this point
in time.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 14:40
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> I don't see any overlap if the time constants are different. That is,
> the QoS query might occur just prior to handover, while CAR
> might happen
> sometime alot more distant from handover.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: <john.loughney@nokia.com>
> Cc: <seamoby@ietf.org>
> Sent: Wednesday, April 03, 2002 9:41 AM
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
>
>
> > John:
> >
> >   Clearly there is an overlap as all three solutions, CT, CAR and
> > NSIS are dealing with QoS.
> >
> >   I was content to let this thread drop until I came across the
> following
> > requirement in re-reading draft-ietf-nsis-req-00.txt:
> >
> > "5.1.2 Resource availability information on request
> >
> >    In some scenarios, e.g., the mobile terminal scenario, it is
> >    required to query, whether resources are available, without
> >    performing a reservation on the resource. One solution might be a
> >    feedback mechanism based on which a QoS inferred
> handover can take
> >    place."
> >
> > There seems to be some overlap in functionality here. Alternative
> solutions
> > are usually great choices to have, but clearly the
> conversation on the
> > respective
> > roles of NSIS and CAR must continue.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > Sent: April 3, 2002 12:13
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: seamoby@ietf.org
> > > Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
> > >
> > >
> > > Hi Gary,
> > >
> > > > I tried to find the email that discussed "centralized QoS", or
> > > > "proxies". Can you elaborate where these threads originated?
> > > > Gary
> > > > PS: Since this is about CT, I am following it up on the
> > > Seamoby list.
> > >
> > > My comment was about NSIS, not about CT so I don't think this
> > > conversation is really of relevance to SeaMoby.  If the signaling
> > > path is not along the data path, then NSIS signaling
> > > probably would not need CT.  If you see how CT could be
> used, please
> > > let us know, especially on the NSIS list.
> > >
> > > John
> > >
> > > PS - reminds me of an old Rodney Dangerfield routine 'So, I was
> > > at a SeaMoby meeting when an NSIS discussion broke out.'
> > >
> >
>
>

------_=_NextPart_001_01C1DB48.767D1D26-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 15:17: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 PAA14499 for ; Wed, 3 Apr 2002 15:17: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 OAA22046; Wed, 3 Apr 2002 14:47: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 OAA21965 for ; Wed, 3 Apr 2002 14:47:42 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13860 for ; Wed, 3 Apr 2002 14:47:38 -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 g33JkwS23808; Wed, 3 Apr 2002 14:46:59 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 14:47:00 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 14:46:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB48.4EBB0654" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB48.4EBB0654 Content-Type: text/plain; charset="iso-8859-1" James: Ok. You probably know something about the solution that I don't see. But, in your email describing a scenario with QoS handover between GPRS and 802.11: if CT/QoS signalling were available today, why would Docomo need CAR to enable GPRS/802.11 handovers? Could they not engineer both wireless subnets with sufficient static mapping of QoS capabilities between the two? Within a year time frame, which solution is most likely to be available? Just asking, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 14:14 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Gary, > > I disagree about your assessment of the near term prospects > for CAR, see > my earlier note to Charlie. > > But I agree that CT has wider applicability, because it may be used in > cases where the next access router is > deterministically selected by the Layer 2 protocol due to timing > considerations. > > I also see the two as separate and, to a certain extent > complimentary in > function. But the process question of "how do we standardize the > contents?" is a similar one, though the answer may differ for the two. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: ; > Cc: > Sent: Wednesday, April 03, 2002 6:37 AM > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > John, et al: > > > > As far as I am concerned, we worked hard on defining CT requirements > to be > > "proactive": > > that is, happening "before" a handoff. Has CAR now supplanted this > > capability in > > everyones mind? If so, then I think the main value of CT has been > lost. > > > > Here's an observation for everyone to consider: in the > manner that CAR > (and > > TARS) is > > being talked about, there is an implication that the mobile > will have > a > > choice of > > channels to handover to. These channels are to be differentiated by > the > > services and > > QoS that they provide. It is hard, at this point, to see that this > will be > > the norm > > for near future. Yes, if 802.11 is used for "hot spot > coverage", there > will > > very likely > > be overlap with cellular channels, but the need to make a choice for > one > > over the other > > (if based upon QoS parameters like bandwidth, then the choice will > almost > > always be > > 802.11), will be rare. > > > > On the other hand, if there is *any* opportunity to > handover, then CT > can be > > employed > > to improve the handover. > > > > In short, CT has a wider applicability and benefit to improving > handover > > performance, whereas, > > CAR has a limited applicability, particularly in the short term. > > > > Cheers, > > Gary > > > > PS: I think it that everyone should be concerned that the definition > of CAR > > is being massaged > > into a being a replacement for the proposal to perform CT from MN to > access > > network - a concept > > that the working group did not favour, for many good, technical, > reasons. > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: April 3, 2002 01:21 > > > To: kempf@docomolabs-usa.com > > > Cc: seamoby@ietf.org > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > Hi James, > > > > > What NSIS will be working on is a generalized framework, to > enable > > > > > end to edge signaling, end to end signaling and perhaps > > > edge to edge > > > > > signaling. > > > > > > > > > > For the end-to-edge signaling, the access network (maybe even > the > > > > > access router) would/could be proxying QoS for network > > > towards the > > > > > end node. > > > > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > > prehandoff or posthandoff end to edge (host to > network?) signaling > > > > rather than at the time of handoff, is that right? > > > > > > I'm not sure what you mean. I will say it another way. > NSIS would > > > not like to re-negotiate QoS after each handoff. If Seamoby could > > > do some work with CARD (pre-handoff) and CT (during & > post-handoff) > > > that would make renogotiation less needed, that would be great. > > > > > > John > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > ------_=_NextPart_001_01C1DB48.4EBB0654 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

James:

 Ok. You probably know something about the solution that I don't see.

 But, in your email describing a scenario with QoS handover between GPRS
and 802.11: if CT/QoS signalling were available today, why would Docomo
need CAR to enable GPRS/802.11 handovers? Could they not engineer both
wireless subnets with sufficient static mapping of QoS capabilities between
the two? Within a year time frame, which solution is most likely to be
available?

Just asking,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 14:14
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> I disagree about your assessment of the near term prospects
> for CAR, see
> my earlier note to Charlie.
>
> But I agree that CT has wider applicability, because it may be used in
> cases where the next access router is
> deterministically selected by the Layer 2 protocol due to timing
> considerations.
>
> I also see the two as separate and, to a certain extent
> complimentary in
> function. But the process question of "how do we standardize the
> contents?" is a similar one, though the answer may differ for the two.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: <john.loughney@nokia.com>; <kempf@docomolabs-usa.com>
> Cc: <seamoby@ietf.org>
> Sent: Wednesday, April 03, 2002 6:37 AM
> Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > John, et al:
> >
> > As far as I am concerned, we worked hard on defining CT requirements
> to be
> > "proactive":
> > that is, happening "before" a handoff. Has CAR now supplanted this
> > capability in
> > everyones mind? If so, then I think the main value of CT has been
> lost.
> >
> > Here's an observation for everyone to consider: in the
> manner that CAR
> (and
> > TARS) is
> > being talked about, there is an implication that the mobile
> will have
> a
> > choice of
> > channels to handover to. These channels are to be differentiated by
> the
> > services and
> > QoS that they provide. It is hard, at this point, to see that this
> will be
> > the norm
> > for near future. Yes, if 802.11 is used for "hot spot
> coverage", there
> will
> > very likely
> > be overlap with cellular channels, but the need to make a choice for
> one
> > over the other
> > (if based upon QoS parameters like bandwidth, then the choice will
> almost
> > always be
> > 802.11), will be rare.
> >
> > On the other hand, if there is *any* opportunity to
> handover, then CT
> can be
> > employed
> > to improve the handover.
> >
> > In short, CT has a wider applicability and benefit to improving
> handover
> > performance, whereas,
> > CAR has a limited applicability, particularly in the short term.
> >
> > Cheers,
> > Gary
> >
> > PS: I think it that everyone should be concerned that the definition
> of CAR
> > is being massaged
> > into a being a replacement for the proposal to perform CT from MN to
> access
> > network - a concept
> > that the working group did not favour, for many good, technical,
> reasons.
> >
> > > -----Original Message-----
> > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > Sent: April 3, 2002 01:21
> > > To: kempf@docomolabs-usa.com
> > > Cc: seamoby@ietf.org
> > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > >
> > >
> > > Hi James,
> > > > > What NSIS will be working on is a generalized framework, to
> enable
> > > > > end to edge signaling, end to end signaling and perhaps
> > > edge to edge
> > > > > signaling.
> > > > >
> > > > > For the end-to-edge signaling, the access network (maybe even
> the
> > > > > access router) would/could be proxying QoS for network
> > > towards the
> > > > > end node.
> > > > >
> > > >
> > > > So it sounds to me the only issue is that NSIS would look at
> > > > prehandoff or posthandoff end to edge (host to
> network?) signaling
> > > > rather than at the time of handoff, is that right?
> > >
> > > I'm not sure what you mean.  I will say it another way. 
> NSIS would
> > > not like to re-negotiate QoS after each handoff.  If Seamoby could
> > > do some work with CARD (pre-handoff) and CT (during &
> post-handoff)
> > > that would make renogotiation less needed, that would be great.
> > >
> > > John
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
>
>

------_=_NextPart_001_01C1DB48.4EBB0654-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 3 15:17: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 PAA14513 for ; Wed, 3 Apr 2002 15:17:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23704 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 15:17: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 OAA22046; Wed, 3 Apr 2002 14:47: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 OAA21965 for ; Wed, 3 Apr 2002 14:47:42 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13860 for ; Wed, 3 Apr 2002 14:47:38 -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 g33JkwS23808; Wed, 3 Apr 2002 14:46:59 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 14:47:00 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 14:46:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB48.4EBB0654" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB48.4EBB0654 Content-Type: text/plain; charset="iso-8859-1" James: Ok. You probably know something about the solution that I don't see. But, in your email describing a scenario with QoS handover between GPRS and 802.11: if CT/QoS signalling were available today, why would Docomo need CAR to enable GPRS/802.11 handovers? Could they not engineer both wireless subnets with sufficient static mapping of QoS capabilities between the two? Within a year time frame, which solution is most likely to be available? Just asking, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 14:14 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Gary, > > I disagree about your assessment of the near term prospects > for CAR, see > my earlier note to Charlie. > > But I agree that CT has wider applicability, because it may be used in > cases where the next access router is > deterministically selected by the Layer 2 protocol due to timing > considerations. > > I also see the two as separate and, to a certain extent > complimentary in > function. But the process question of "how do we standardize the > contents?" is a similar one, though the answer may differ for the two. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: ; > Cc: > Sent: Wednesday, April 03, 2002 6:37 AM > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > John, et al: > > > > As far as I am concerned, we worked hard on defining CT requirements > to be > > "proactive": > > that is, happening "before" a handoff. Has CAR now supplanted this > > capability in > > everyones mind? If so, then I think the main value of CT has been > lost. > > > > Here's an observation for everyone to consider: in the > manner that CAR > (and > > TARS) is > > being talked about, there is an implication that the mobile > will have > a > > choice of > > channels to handover to. These channels are to be differentiated by > the > > services and > > QoS that they provide. It is hard, at this point, to see that this > will be > > the norm > > for near future. Yes, if 802.11 is used for "hot spot > coverage", there > will > > very likely > > be overlap with cellular channels, but the need to make a choice for > one > > over the other > > (if based upon QoS parameters like bandwidth, then the choice will > almost > > always be > > 802.11), will be rare. > > > > On the other hand, if there is *any* opportunity to > handover, then CT > can be > > employed > > to improve the handover. > > > > In short, CT has a wider applicability and benefit to improving > handover > > performance, whereas, > > CAR has a limited applicability, particularly in the short term. > > > > Cheers, > > Gary > > > > PS: I think it that everyone should be concerned that the definition > of CAR > > is being massaged > > into a being a replacement for the proposal to perform CT from MN to > access > > network - a concept > > that the working group did not favour, for many good, technical, > reasons. > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: April 3, 2002 01:21 > > > To: kempf@docomolabs-usa.com > > > Cc: seamoby@ietf.org > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > Hi James, > > > > > What NSIS will be working on is a generalized framework, to > enable > > > > > end to edge signaling, end to end signaling and perhaps > > > edge to edge > > > > > signaling. > > > > > > > > > > For the end-to-edge signaling, the access network (maybe even > the > > > > > access router) would/could be proxying QoS for network > > > towards the > > > > > end node. > > > > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > > prehandoff or posthandoff end to edge (host to > network?) signaling > > > > rather than at the time of handoff, is that right? > > > > > > I'm not sure what you mean. I will say it another way. > NSIS would > > > not like to re-negotiate QoS after each handoff. If Seamoby could > > > do some work with CARD (pre-handoff) and CT (during & > post-handoff) > > > that would make renogotiation less needed, that would be great. > > > > > > John > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > ------_=_NextPart_001_01C1DB48.4EBB0654 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

James:

 Ok. You probably know something about the solution that I don't see.

 But, in your email describing a scenario with QoS handover between GPRS
and 802.11: if CT/QoS signalling were available today, why would Docomo
need CAR to enable GPRS/802.11 handovers? Could they not engineer both
wireless subnets with sufficient static mapping of QoS capabilities between
the two? Within a year time frame, which solution is most likely to be
available?

Just asking,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 14:14
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> I disagree about your assessment of the near term prospects
> for CAR, see
> my earlier note to Charlie.
>
> But I agree that CT has wider applicability, because it may be used in
> cases where the next access router is
> deterministically selected by the Layer 2 protocol due to timing
> considerations.
>
> I also see the two as separate and, to a certain extent
> complimentary in
> function. But the process question of "how do we standardize the
> contents?" is a similar one, though the answer may differ for the two.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: <john.loughney@nokia.com>; <kempf@docomolabs-usa.com>
> Cc: <seamoby@ietf.org>
> Sent: Wednesday, April 03, 2002 6:37 AM
> Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > John, et al:
> >
> > As far as I am concerned, we worked hard on defining CT requirements
> to be
> > "proactive":
> > that is, happening "before" a handoff. Has CAR now supplanted this
> > capability in
> > everyones mind? If so, then I think the main value of CT has been
> lost.
> >
> > Here's an observation for everyone to consider: in the
> manner that CAR
> (and
> > TARS) is
> > being talked about, there is an implication that the mobile
> will have
> a
> > choice of
> > channels to handover to. These channels are to be differentiated by
> the
> > services and
> > QoS that they provide. It is hard, at this point, to see that this
> will be
> > the norm
> > for near future. Yes, if 802.11 is used for "hot spot
> coverage", there
> will
> > very likely
> > be overlap with cellular channels, but the need to make a choice for
> one
> > over the other
> > (if based upon QoS parameters like bandwidth, then the choice will
> almost
> > always be
> > 802.11), will be rare.
> >
> > On the other hand, if there is *any* opportunity to
> handover, then CT
> can be
> > employed
> > to improve the handover.
> >
> > In short, CT has a wider applicability and benefit to improving
> handover
> > performance, whereas,
> > CAR has a limited applicability, particularly in the short term.
> >
> > Cheers,
> > Gary
> >
> > PS: I think it that everyone should be concerned that the definition
> of CAR
> > is being massaged
> > into a being a replacement for the proposal to perform CT from MN to
> access
> > network - a concept
> > that the working group did not favour, for many good, technical,
> reasons.
> >
> > > -----Original Message-----
> > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > Sent: April 3, 2002 01:21
> > > To: kempf@docomolabs-usa.com
> > > Cc: seamoby@ietf.org
> > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > >
> > >
> > > Hi James,
> > > > > What NSIS will be working on is a generalized framework, to
> enable
> > > > > end to edge signaling, end to end signaling and perhaps
> > > edge to edge
> > > > > signaling.
> > > > >
> > > > > For the end-to-edge signaling, the access network (maybe even
> the
> > > > > access router) would/could be proxying QoS for network
> > > towards the
> > > > > end node.
> > > > >
> > > >
> > > > So it sounds to me the only issue is that NSIS would look at
> > > > prehandoff or posthandoff end to edge (host to
> network?) signaling
> > > > rather than at the time of handoff, is that right?
> > >
> > > I'm not sure what you mean.  I will say it another way. 
> NSIS would
> > > not like to re-negotiate QoS after each handoff.  If Seamoby could
> > > do some work with CARD (pre-handoff) and CT (during &
> post-handoff)
> > > that would make renogotiation less needed, that would be great.
> > >
> > > John
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
>
>

------_=_NextPart_001_01C1DB48.4EBB0654-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 15:23: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 PAA14639 for ; Wed, 3 Apr 2002 15:23: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 PAA23254; Wed, 3 Apr 2002 15:05: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 PAA23225 for ; Wed, 3 Apr 2002 15:05: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 PAA14260 for ; Wed, 3 Apr 2002 15:05: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 g33K3sI21631; Wed, 3 Apr 2002 12:03:54 -0800 (PST) Message-ID: <022401c1db4a$74cba310$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA49A5@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:02: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 Gary, I did not say that there would be QoS handover. What I see is CAR providing the user on the mobile with information about what's available, and the user makes the selection. When they buy the service, they're told that they can get "broadband" or "narrowband" and how the laptop tells them when broadband is available. A much more tractable problem I think. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Cc: Sent: Wednesday, April 03, 2002 11:46 AM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > James: > > Ok. You probably know something about the solution that I don't see. > > But, in your email describing a scenario with QoS handover between GPRS > and 802.11: if CT/QoS signalling were available today, why would Docomo > need CAR to enable GPRS/802.11 handovers? Could they not engineer both > wireless subnets with sufficient static mapping of QoS capabilities between > the two? Within a year time frame, which solution is most likely to be > available? > > Just asking, > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 3, 2002 14:14 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > > Cc: seamoby@ietf.org > > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > Gary, > > > > I disagree about your assessment of the near term prospects > > for CAR, see > > my earlier note to Charlie. > > > > But I agree that CT has wider applicability, because it may be used in > > cases where the next access router is > > deterministically selected by the Layer 2 protocol due to timing > > considerations. > > > > I also see the two as separate and, to a certain extent > > complimentary in > > function. But the process question of "how do we standardize the > > contents?" is a similar one, though the answer may differ for the two. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: ; > > Cc: > > Sent: Wednesday, April 03, 2002 6:37 AM > > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > John, et al: > > > > > > As far as I am concerned, we worked hard on defining CT requirements > > to be > > > "proactive": > > > that is, happening "before" a handoff. Has CAR now supplanted this > > > capability in > > > everyones mind? If so, then I think the main value of CT has been > > lost. > > > > > > Here's an observation for everyone to consider: in the > > manner that CAR > > (and > > > TARS) is > > > being talked about, there is an implication that the mobile > > will have > > a > > > choice of > > > channels to handover to. These channels are to be differentiated by > > the > > > services and > > > QoS that they provide. It is hard, at this point, to see that this > > will be > > > the norm > > > for near future. Yes, if 802.11 is used for "hot spot > > coverage", there > > will > > > very likely > > > be overlap with cellular channels, but the need to make a choice for > > one > > > over the other > > > (if based upon QoS parameters like bandwidth, then the choice will > > almost > > > always be > > > 802.11), will be rare. > > > > > > On the other hand, if there is *any* opportunity to > > handover, then CT > > can be > > > employed > > > to improve the handover. > > > > > > In short, CT has a wider applicability and benefit to improving > > handover > > > performance, whereas, > > > CAR has a limited applicability, particularly in the short term. > > > > > > Cheers, > > > Gary > > > > > > PS: I think it that everyone should be concerned that the definition > > of CAR > > > is being massaged > > > into a being a replacement for the proposal to perform CT from MN to > > access > > > network - a concept > > > that the working group did not favour, for many good, technical, > > reasons. > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: April 3, 2002 01:21 > > > > To: kempf@docomolabs-usa.com > > > > Cc: seamoby@ietf.org > > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > > > > Hi James, > > > > > > What NSIS will be working on is a generalized framework, to > > enable > > > > > > end to edge signaling, end to end signaling and perhaps > > > > edge to edge > > > > > > signaling. > > > > > > > > > > > > For the end-to-edge signaling, the access network (maybe even > > the > > > > > > access router) would/could be proxying QoS for network > > > > towards the > > > > > > end node. > > > > > > > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > > > prehandoff or posthandoff end to edge (host to > > network?) signaling > > > > > rather than at the time of handoff, is that right? > > > > > > > > I'm not sure what you mean. I will say it another way. > > NSIS would > > > > not like to re-negotiate QoS after each handoff. If Seamoby could > > > > do some work with CARD (pre-handoff) and CT (during & > > post-handoff) > > > > that would make renogotiation less needed, that would be great. > > > > > > > > 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@ns.ietf.org Wed Apr 3 15:23: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 PAA14649 for ; Wed, 3 Apr 2002 15:23:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23982 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 15:23: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 PAA23254; Wed, 3 Apr 2002 15:05: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 PAA23225 for ; Wed, 3 Apr 2002 15:05: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 PAA14260 for ; Wed, 3 Apr 2002 15:05: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 g33K3sI21631; Wed, 3 Apr 2002 12:03:54 -0800 (PST) Message-ID: <022401c1db4a$74cba310$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA49A5@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:02: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 Gary, I did not say that there would be QoS handover. What I see is CAR providing the user on the mobile with information about what's available, and the user makes the selection. When they buy the service, they're told that they can get "broadband" or "narrowband" and how the laptop tells them when broadband is available. A much more tractable problem I think. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; Cc: Sent: Wednesday, April 03, 2002 11:46 AM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > James: > > Ok. You probably know something about the solution that I don't see. > > But, in your email describing a scenario with QoS handover between GPRS > and 802.11: if CT/QoS signalling were available today, why would Docomo > need CAR to enable GPRS/802.11 handovers? Could they not engineer both > wireless subnets with sufficient static mapping of QoS capabilities between > the two? Within a year time frame, which solution is most likely to be > available? > > Just asking, > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 3, 2002 14:14 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > > Cc: seamoby@ietf.org > > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > Gary, > > > > I disagree about your assessment of the near term prospects > > for CAR, see > > my earlier note to Charlie. > > > > But I agree that CT has wider applicability, because it may be used in > > cases where the next access router is > > deterministically selected by the Layer 2 protocol due to timing > > considerations. > > > > I also see the two as separate and, to a certain extent > > complimentary in > > function. But the process question of "how do we standardize the > > contents?" is a similar one, though the answer may differ for the two. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: ; > > Cc: > > Sent: Wednesday, April 03, 2002 6:37 AM > > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > John, et al: > > > > > > As far as I am concerned, we worked hard on defining CT requirements > > to be > > > "proactive": > > > that is, happening "before" a handoff. Has CAR now supplanted this > > > capability in > > > everyones mind? If so, then I think the main value of CT has been > > lost. > > > > > > Here's an observation for everyone to consider: in the > > manner that CAR > > (and > > > TARS) is > > > being talked about, there is an implication that the mobile > > will have > > a > > > choice of > > > channels to handover to. These channels are to be differentiated by > > the > > > services and > > > QoS that they provide. It is hard, at this point, to see that this > > will be > > > the norm > > > for near future. Yes, if 802.11 is used for "hot spot > > coverage", there > > will > > > very likely > > > be overlap with cellular channels, but the need to make a choice for > > one > > > over the other > > > (if based upon QoS parameters like bandwidth, then the choice will > > almost > > > always be > > > 802.11), will be rare. > > > > > > On the other hand, if there is *any* opportunity to > > handover, then CT > > can be > > > employed > > > to improve the handover. > > > > > > In short, CT has a wider applicability and benefit to improving > > handover > > > performance, whereas, > > > CAR has a limited applicability, particularly in the short term. > > > > > > Cheers, > > > Gary > > > > > > PS: I think it that everyone should be concerned that the definition > > of CAR > > > is being massaged > > > into a being a replacement for the proposal to perform CT from MN to > > access > > > network - a concept > > > that the working group did not favour, for many good, technical, > > reasons. > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: April 3, 2002 01:21 > > > > To: kempf@docomolabs-usa.com > > > > Cc: seamoby@ietf.org > > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > > > > Hi James, > > > > > > What NSIS will be working on is a generalized framework, to > > enable > > > > > > end to edge signaling, end to end signaling and perhaps > > > > edge to edge > > > > > > signaling. > > > > > > > > > > > > For the end-to-edge signaling, the access network (maybe even > > the > > > > > > access router) would/could be proxying QoS for network > > > > towards the > > > > > > end node. > > > > > > > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > > > prehandoff or posthandoff end to edge (host to > > network?) signaling > > > > > rather than at the time of handoff, is that right? > > > > > > > > I'm not sure what you mean. I will say it another way. > > NSIS would > > > > not like to re-negotiate QoS after each handoff. If Seamoby could > > > > do some work with CARD (pre-handoff) and CT (during & > > post-handoff) > > > > that would make renogotiation less needed, that would be great. > > > > > > > > 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 Wed Apr 3 15:50: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 PAA15361 for ; Wed, 3 Apr 2002 15:50: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 PAA24519; Wed, 3 Apr 2002 15:30: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 PAA24435 for ; Wed, 3 Apr 2002 15:30:04 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14807 for ; Wed, 3 Apr 2002 15:30:00 -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 g33KTKS26882; Wed, 3 Apr 2002 15:29:21 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 15:29:22 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A8@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 15:29:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB4E.3AB34044" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB4E.3AB34044 Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 15:02 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Gary, > > I did not say that there would be QoS handover. What I see is CAR "QoS handover": a handover in which their is a quality of service attribute associated with the session either before or after or before and after handover. As opposed to a "best effort" handover in which the forwarding treatment of the IP packets before, during and after handover are "best effort". No specific mechanisms implied. > providing the user on the mobile with information about what's > available, and the user makes the selection. When they buy > the service, > they're told that they can get "broadband" or "narrowband" > and how the > laptop tells them when broadband is available. A much more tractable > problem I think. ? Are we talking about handover here or initial access? I fully agree with the idea that if I turn on my laptop/pda, and there are multiple wireless services available, it would be nice to be able to have a choice of which one I used (I would also like to know cost, reliability, coverage - i.e. will I loss the service in one step). Do I need to do this with a dynamic protocol? Well, if I assume that there are many operators, and through some unknown (and complicated subscription process), I will have an active subscription for wireless access with all of them, and if I assume that every operator has a different QoS offering, yes a dynamic protocol is needed. Do I need to know bandwidth, latency, error rates, etc., etc. Well, *I* might be able to make a choice given these parameters, but the majority of Internet users are not engineers (frankly, I think I would get tired of making this decision). How does one translate "bandwidth", "latency" etc. into "narrowband", "broadband", etc. Implied here is a standardized translation of QoS capabilities to Classes of Service which catching marketing labels like Gold, Silver, and Bronze. They have to be standard if the user is going to be able to compare two QoS offerings. But why would I need a discovery protocol if I was subscribed to Docomo access services and choosing between Docomo 802.11 access and Docomo GPRS access? And why would I need it to handoff between Docomo 802.11 access and Docomo GPRS access? (I appologize for over-use of the Docomo name. It is just a convenient proper noun for "THE operator".) What am I missing here? Gary > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > > Cc: > Sent: Wednesday, April 03, 2002 11:46 AM > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > James: > > > > Ok. You probably know something about the solution that I > don't see. > > > > But, in your email describing a scenario with QoS handover between > GPRS > > and 802.11: if CT/QoS signalling were available today, why would > Docomo > > need CAR to enable GPRS/802.11 handovers? Could they not > engineer both > > wireless subnets with sufficient static mapping of QoS capabilities > between > > the two? Within a year time frame, which solution is most > likely to be > > available? > > > > Just asking, > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 3, 2002 14:14 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > > > Cc: seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > Gary, > > > > > > I disagree about your assessment of the near term prospects > > > for CAR, see > > > my earlier note to Charlie. > > > > > > But I agree that CT has wider applicability, because it > may be used > in > > > cases where the next access router is > > > deterministically selected by the Layer 2 protocol due to timing > > > considerations. > > > > > > I also see the two as separate and, to a certain extent > > > complimentary in > > > function. But the process question of "how do we standardize the > > > contents?" is a similar one, though the answer may differ for the > two. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; > > > Cc: > > > Sent: Wednesday, April 03, 2002 6:37 AM > > > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > > John, et al: > > > > > > > > As far as I am concerned, we worked hard on defining CT > requirements > > > to be > > > > "proactive": > > > > that is, happening "before" a handoff. Has CAR now > supplanted this > > > > capability in > > > > everyones mind? If so, then I think the main value of > CT has been > > > lost. > > > > > > > > Here's an observation for everyone to consider: in the > > > manner that CAR > > > (and > > > > TARS) is > > > > being talked about, there is an implication that the mobile > > > will have > > > a > > > > choice of > > > > channels to handover to. These channels are to be differentiated > by > > > the > > > > services and > > > > QoS that they provide. It is hard, at this point, to > see that this > > > will be > > > > the norm > > > > for near future. Yes, if 802.11 is used for "hot spot > > > coverage", there > > > will > > > > very likely > > > > be overlap with cellular channels, but the need to make a choice > for > > > one > > > > over the other > > > > (if based upon QoS parameters like bandwidth, then the > choice will > > > almost > > > > always be > > > > 802.11), will be rare. > > > > > > > > On the other hand, if there is *any* opportunity to > > > handover, then CT > > > can be > > > > employed > > > > to improve the handover. > > > > > > > > In short, CT has a wider applicability and benefit to improving > > > handover > > > > performance, whereas, > > > > CAR has a limited applicability, particularly in the short term. > > > > > > > > Cheers, > > > > Gary > > > > > > > > PS: I think it that everyone should be concerned that the > definition > > > of CAR > > > > is being massaged > > > > into a being a replacement for the proposal to perform > CT from MN > to > > > access > > > > network - a concept > > > > that the working group did not favour, for many good, technical, > > > reasons. > > > > > > > > > -----Original Message----- > > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > > Sent: April 3, 2002 01:21 > > > > > To: kempf@docomolabs-usa.com > > > > > Cc: seamoby@ietf.org > > > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > > > > > > > Hi James, > > > > > > > What NSIS will be working on is a generalized > framework, to > > > enable > > > > > > > end to edge signaling, end to end signaling and perhaps > > > > > edge to edge > > > > > > > signaling. > > > > > > > > > > > > > > For the end-to-edge signaling, the access network (maybe > even > > > the > > > > > > > access router) would/could be proxying QoS for network > > > > > towards the > > > > > > > end node. > > > > > > > > > > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > > > > prehandoff or posthandoff end to edge (host to > > > network?) signaling > > > > > > rather than at the time of handoff, is that right? > > > > > > > > > > I'm not sure what you mean. I will say it another way. > > > NSIS would > > > > > not like to re-negotiate QoS after each handoff. If Seamoby > could > > > > > do some work with CARD (pre-handoff) and CT (during & > > > post-handoff) > > > > > that would make renogotiation less needed, that would > be great. > > > > > > > > > > John > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1DB4E.3AB34044 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 15:02
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> I did not say that there would be QoS handover. What I see is CAR

  "QoS handover": a handover in which their is a quality of service
attribute associated with the session either before or after or before
and after handover. As opposed to a "best effort" handover in which
the forwarding treatment of the IP packets before, during and after handover
are "best effort".

  No specific mechanisms implied.

> providing the user on the mobile with information about what's
> available, and the user makes the selection. When they buy
> the service,
> they're told that they can get "broadband"  or "narrowband"
> and how the
> laptop tells them when broadband is available. A much more tractable
> problem I think.


  ? Are we talking about handover here or initial access? I fully agree
with the idea that if I turn on my laptop/pda, and there are multiple
wireless services available, it would be nice to be able to have a choice
of which one I used (I would also like to know cost, reliability, coverage
- i.e. will I loss the service in one step).

Do I need to do this with a dynamic protocol? Well, if I assume that
there are many operators, and through some unknown (and complicated
subscription process), I will have an active subscription for wireless
access with all of them, and if I assume that every operator has a different
QoS offering, yes a dynamic protocol is needed.

Do I need to know bandwidth, latency, error rates, etc., etc. Well, *I* might
be able to make a choice given these parameters, but the majority of Internet
users are not engineers (frankly, I think I would get tired of making this
decision). How does one translate "bandwidth", "latency" etc. into "narrowband",
"broadband", etc. Implied here is a standardized translation of QoS capabilities
to Classes of Service which catching marketing labels like Gold, Silver, and Bronze.
They have to be standard if the user is going to be able to compare two QoS offerings.

But why would I need a discovery protocol if I was subscribed to Docomo access
services and choosing between Docomo 802.11 access and Docomo GPRS access? And why
would I need it to handoff between Docomo 802.11 access and Docomo GPRS access?

(I appologize for over-use of the Docomo name. It is just a convenient proper
noun for "THE operator".)

What am I missing here?

Gary

>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>;
> <john.loughney@nokia.com>
> Cc: <seamoby@ietf.org>
> Sent: Wednesday, April 03, 2002 11:46 AM
> Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > James:
> >
> >  Ok. You probably know something about the solution that I
> don't see.
> >
> >  But, in your email describing a scenario with QoS handover between
> GPRS
> > and 802.11: if CT/QoS signalling were available today, why would
> Docomo
> > need CAR to enable GPRS/802.11 handovers? Could they not
> engineer both
> > wireless subnets with sufficient static mapping of QoS capabilities
> between
> > the two? Within a year time frame, which solution is most
> likely to be
> > available?
> >
> > Just asking,
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 3, 2002 14:14
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> > > Cc: seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > >
> > >
> > > Gary,
> > >
> > > I disagree about your assessment of the near term prospects
> > > for CAR, see
> > > my earlier note to Charlie.
> > >
> > > But I agree that CT has wider applicability, because it
> may be used
> in
> > > cases where the next access router is
> > > deterministically selected by the Layer 2 protocol due to timing
> > > considerations.
> > >
> > > I also see the two as separate and, to a certain extent
> > > complimentary in
> > > function. But the process question of "how do we standardize the
> > > contents?" is a similar one, though the answer may differ for the
> two.
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <john.loughney@nokia.com>; <kempf@docomolabs-usa.com>
> > > Cc: <seamoby@ietf.org>
> > > Sent: Wednesday, April 03, 2002 6:37 AM
> > > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > >
> > >
> > > > John, et al:
> > > >
> > > > As far as I am concerned, we worked hard on defining CT
> requirements
> > > to be
> > > > "proactive":
> > > > that is, happening "before" a handoff. Has CAR now
> supplanted this
> > > > capability in
> > > > everyones mind? If so, then I think the main value of
> CT has been
> > > lost.
> > > >
> > > > Here's an observation for everyone to consider: in the
> > > manner that CAR
> > > (and
> > > > TARS) is
> > > > being talked about, there is an implication that the mobile
> > > will have
> > > a
> > > > choice of
> > > > channels to handover to. These channels are to be differentiated
> by
> > > the
> > > > services and
> > > > QoS that they provide. It is hard, at this point, to
> see that this
> > > will be
> > > > the norm
> > > > for near future. Yes, if 802.11 is used for "hot spot
> > > coverage", there
> > > will
> > > > very likely
> > > > be overlap with cellular channels, but the need to make a choice
> for
> > > one
> > > > over the other
> > > > (if based upon QoS parameters like bandwidth, then the
> choice will
> > > almost
> > > > always be
> > > > 802.11), will be rare.
> > > >
> > > > On the other hand, if there is *any* opportunity to
> > > handover, then CT
> > > can be
> > > > employed
> > > > to improve the handover.
> > > >
> > > > In short, CT has a wider applicability and benefit to improving
> > > handover
> > > > performance, whereas,
> > > > CAR has a limited applicability, particularly in the short term.
> > > >
> > > > Cheers,
> > > > Gary
> > > >
> > > > PS: I think it that everyone should be concerned that the
> definition
> > > of CAR
> > > > is being massaged
> > > > into a being a replacement for the proposal to perform
> CT from MN
> to
> > > access
> > > > network - a concept
> > > > that the working group did not favour, for many good, technical,
> > > reasons.
> > > >
> > > > > -----Original Message-----
> > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > > > Sent: April 3, 2002 01:21
> > > > > To: kempf@docomolabs-usa.com
> > > > > Cc: seamoby@ietf.org
> > > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > > > >
> > > > >
> > > > > Hi James,
> > > > > > > What NSIS will be working on is a generalized
> framework, to
> > > enable
> > > > > > > end to edge signaling, end to end signaling and perhaps
> > > > > edge to edge
> > > > > > > signaling.
> > > > > > >
> > > > > > > For the end-to-edge signaling, the access network (maybe
> even
> > > the
> > > > > > > access router) would/could be proxying QoS for network
> > > > > towards the
> > > > > > > end node.
> > > > > > >
> > > > > >
> > > > > > So it sounds to me the only issue is that NSIS would look at
> > > > > > prehandoff or posthandoff end to edge (host to
> > > network?) signaling
> > > > > > rather than at the time of handoff, is that right?
> > > > >
> > > > > I'm not sure what you mean.  I will say it another way.
> > > NSIS would
> > > > > not like to re-negotiate QoS after each handoff.  If Seamoby
> could
> > > > > do some work with CARD (pre-handoff) and CT (during &
> > > post-handoff)
> > > > > that would make renogotiation less needed, that would
> be great.
> > > > >
> > > > > John
> > > > >
> > > > > _______________________________________________
> > > > > Seamoby mailing list
> > > > > Seamoby@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > >
> > > >
> > >
> > >
> >
>
>

------_=_NextPart_001_01C1DB4E.3AB34044-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 3 15:50: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 PAA15371 for ; Wed, 3 Apr 2002 15:50:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25994 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 15: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 PAA24519; Wed, 3 Apr 2002 15:30: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 PAA24435 for ; Wed, 3 Apr 2002 15:30:04 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14807 for ; Wed, 3 Apr 2002 15:30:00 -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 g33KTKS26882; Wed, 3 Apr 2002 15:29:21 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 15:29:22 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A8@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 15:29:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB4E.3AB34044" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB4E.3AB34044 Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 15:02 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > Gary, > > I did not say that there would be QoS handover. What I see is CAR "QoS handover": a handover in which their is a quality of service attribute associated with the session either before or after or before and after handover. As opposed to a "best effort" handover in which the forwarding treatment of the IP packets before, during and after handover are "best effort". No specific mechanisms implied. > providing the user on the mobile with information about what's > available, and the user makes the selection. When they buy > the service, > they're told that they can get "broadband" or "narrowband" > and how the > laptop tells them when broadband is available. A much more tractable > problem I think. ? Are we talking about handover here or initial access? I fully agree with the idea that if I turn on my laptop/pda, and there are multiple wireless services available, it would be nice to be able to have a choice of which one I used (I would also like to know cost, reliability, coverage - i.e. will I loss the service in one step). Do I need to do this with a dynamic protocol? Well, if I assume that there are many operators, and through some unknown (and complicated subscription process), I will have an active subscription for wireless access with all of them, and if I assume that every operator has a different QoS offering, yes a dynamic protocol is needed. Do I need to know bandwidth, latency, error rates, etc., etc. Well, *I* might be able to make a choice given these parameters, but the majority of Internet users are not engineers (frankly, I think I would get tired of making this decision). How does one translate "bandwidth", "latency" etc. into "narrowband", "broadband", etc. Implied here is a standardized translation of QoS capabilities to Classes of Service which catching marketing labels like Gold, Silver, and Bronze. They have to be standard if the user is going to be able to compare two QoS offerings. But why would I need a discovery protocol if I was subscribed to Docomo access services and choosing between Docomo 802.11 access and Docomo GPRS access? And why would I need it to handoff between Docomo 802.11 access and Docomo GPRS access? (I appologize for over-use of the Docomo name. It is just a convenient proper noun for "THE operator".) What am I missing here? Gary > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; > > Cc: > Sent: Wednesday, April 03, 2002 11:46 AM > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > James: > > > > Ok. You probably know something about the solution that I > don't see. > > > > But, in your email describing a scenario with QoS handover between > GPRS > > and 802.11: if CT/QoS signalling were available today, why would > Docomo > > need CAR to enable GPRS/802.11 handovers? Could they not > engineer both > > wireless subnets with sufficient static mapping of QoS capabilities > between > > the two? Within a year time frame, which solution is most > likely to be > > available? > > > > Just asking, > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 3, 2002 14:14 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > > > Cc: seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > Gary, > > > > > > I disagree about your assessment of the near term prospects > > > for CAR, see > > > my earlier note to Charlie. > > > > > > But I agree that CT has wider applicability, because it > may be used > in > > > cases where the next access router is > > > deterministically selected by the Layer 2 protocol due to timing > > > considerations. > > > > > > I also see the two as separate and, to a certain extent > > > complimentary in > > > function. But the process question of "how do we standardize the > > > contents?" is a similar one, though the answer may differ for the > two. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Gary Kenward" > > > To: ; > > > Cc: > > > Sent: Wednesday, April 03, 2002 6:37 AM > > > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > > John, et al: > > > > > > > > As far as I am concerned, we worked hard on defining CT > requirements > > > to be > > > > "proactive": > > > > that is, happening "before" a handoff. Has CAR now > supplanted this > > > > capability in > > > > everyones mind? If so, then I think the main value of > CT has been > > > lost. > > > > > > > > Here's an observation for everyone to consider: in the > > > manner that CAR > > > (and > > > > TARS) is > > > > being talked about, there is an implication that the mobile > > > will have > > > a > > > > choice of > > > > channels to handover to. These channels are to be differentiated > by > > > the > > > > services and > > > > QoS that they provide. It is hard, at this point, to > see that this > > > will be > > > > the norm > > > > for near future. Yes, if 802.11 is used for "hot spot > > > coverage", there > > > will > > > > very likely > > > > be overlap with cellular channels, but the need to make a choice > for > > > one > > > > over the other > > > > (if based upon QoS parameters like bandwidth, then the > choice will > > > almost > > > > always be > > > > 802.11), will be rare. > > > > > > > > On the other hand, if there is *any* opportunity to > > > handover, then CT > > > can be > > > > employed > > > > to improve the handover. > > > > > > > > In short, CT has a wider applicability and benefit to improving > > > handover > > > > performance, whereas, > > > > CAR has a limited applicability, particularly in the short term. > > > > > > > > Cheers, > > > > Gary > > > > > > > > PS: I think it that everyone should be concerned that the > definition > > > of CAR > > > > is being massaged > > > > into a being a replacement for the proposal to perform > CT from MN > to > > > access > > > > network - a concept > > > > that the working group did not favour, for many good, technical, > > > reasons. > > > > > > > > > -----Original Message----- > > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > > Sent: April 3, 2002 01:21 > > > > > To: kempf@docomolabs-usa.com > > > > > Cc: seamoby@ietf.org > > > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > > > > > > > > > > > > Hi James, > > > > > > > What NSIS will be working on is a generalized > framework, to > > > enable > > > > > > > end to edge signaling, end to end signaling and perhaps > > > > > edge to edge > > > > > > > signaling. > > > > > > > > > > > > > > For the end-to-edge signaling, the access network (maybe > even > > > the > > > > > > > access router) would/could be proxying QoS for network > > > > > towards the > > > > > > > end node. > > > > > > > > > > > > > > > > > > > So it sounds to me the only issue is that NSIS would look at > > > > > > prehandoff or posthandoff end to edge (host to > > > network?) signaling > > > > > > rather than at the time of handoff, is that right? > > > > > > > > > > I'm not sure what you mean. I will say it another way. > > > NSIS would > > > > > not like to re-negotiate QoS after each handoff. If Seamoby > could > > > > > do some work with CARD (pre-handoff) and CT (during & > > > post-handoff) > > > > > that would make renogotiation less needed, that would > be great. > > > > > > > > > > John > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1DB4E.3AB34044 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 15:02
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> Gary,
>
> I did not say that there would be QoS handover. What I see is CAR

  "QoS handover": a handover in which their is a quality of service
attribute associated with the session either before or after or before
and after handover. As opposed to a "best effort" handover in which
the forwarding treatment of the IP packets before, during and after handover
are "best effort".

  No specific mechanisms implied.

> providing the user on the mobile with information about what's
> available, and the user makes the selection. When they buy
> the service,
> they're told that they can get "broadband"  or "narrowband"
> and how the
> laptop tells them when broadband is available. A much more tractable
> problem I think.


  ? Are we talking about handover here or initial access? I fully agree
with the idea that if I turn on my laptop/pda, and there are multiple
wireless services available, it would be nice to be able to have a choice
of which one I used (I would also like to know cost, reliability, coverage
- i.e. will I loss the service in one step).

Do I need to do this with a dynamic protocol? Well, if I assume that
there are many operators, and through some unknown (and complicated
subscription process), I will have an active subscription for wireless
access with all of them, and if I assume that every operator has a different
QoS offering, yes a dynamic protocol is needed.

Do I need to know bandwidth, latency, error rates, etc., etc. Well, *I* might
be able to make a choice given these parameters, but the majority of Internet
users are not engineers (frankly, I think I would get tired of making this
decision). How does one translate "bandwidth", "latency" etc. into "narrowband",
"broadband", etc. Implied here is a standardized translation of QoS capabilities
to Classes of Service which catching marketing labels like Gold, Silver, and Bronze.
They have to be standard if the user is going to be able to compare two QoS offerings.

But why would I need a discovery protocol if I was subscribed to Docomo access
services and choosing between Docomo 802.11 access and Docomo GPRS access? And why
would I need it to handoff between Docomo 802.11 access and Docomo GPRS access?

(I appologize for over-use of the Docomo name. It is just a convenient proper
noun for "THE operator".)

What am I missing here?

Gary

>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>;
> <john.loughney@nokia.com>
> Cc: <seamoby@ietf.org>
> Sent: Wednesday, April 03, 2002 11:46 AM
> Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > James:
> >
> >  Ok. You probably know something about the solution that I
> don't see.
> >
> >  But, in your email describing a scenario with QoS handover between
> GPRS
> > and 802.11: if CT/QoS signalling were available today, why would
> Docomo
> > need CAR to enable GPRS/802.11 handovers? Could they not
> engineer both
> > wireless subnets with sufficient static mapping of QoS capabilities
> between
> > the two? Within a year time frame, which solution is most
> likely to be
> > available?
> >
> > Just asking,
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 3, 2002 14:14
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> > > Cc: seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > >
> > >
> > > Gary,
> > >
> > > I disagree about your assessment of the near term prospects
> > > for CAR, see
> > > my earlier note to Charlie.
> > >
> > > But I agree that CT has wider applicability, because it
> may be used
> in
> > > cases where the next access router is
> > > deterministically selected by the Layer 2 protocol due to timing
> > > considerations.
> > >
> > > I also see the two as separate and, to a certain extent
> > > complimentary in
> > > function. But the process question of "how do we standardize the
> > > contents?" is a similar one, though the answer may differ for the
> two.
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > To: <john.loughney@nokia.com>; <kempf@docomolabs-usa.com>
> > > Cc: <seamoby@ietf.org>
> > > Sent: Wednesday, April 03, 2002 6:37 AM
> > > Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > >
> > >
> > > > John, et al:
> > > >
> > > > As far as I am concerned, we worked hard on defining CT
> requirements
> > > to be
> > > > "proactive":
> > > > that is, happening "before" a handoff. Has CAR now
> supplanted this
> > > > capability in
> > > > everyones mind? If so, then I think the main value of
> CT has been
> > > lost.
> > > >
> > > > Here's an observation for everyone to consider: in the
> > > manner that CAR
> > > (and
> > > > TARS) is
> > > > being talked about, there is an implication that the mobile
> > > will have
> > > a
> > > > choice of
> > > > channels to handover to. These channels are to be differentiated
> by
> > > the
> > > > services and
> > > > QoS that they provide. It is hard, at this point, to
> see that this
> > > will be
> > > > the norm
> > > > for near future. Yes, if 802.11 is used for "hot spot
> > > coverage", there
> > > will
> > > > very likely
> > > > be overlap with cellular channels, but the need to make a choice
> for
> > > one
> > > > over the other
> > > > (if based upon QoS parameters like bandwidth, then the
> choice will
> > > almost
> > > > always be
> > > > 802.11), will be rare.
> > > >
> > > > On the other hand, if there is *any* opportunity to
> > > handover, then CT
> > > can be
> > > > employed
> > > > to improve the handover.
> > > >
> > > > In short, CT has a wider applicability and benefit to improving
> > > handover
> > > > performance, whereas,
> > > > CAR has a limited applicability, particularly in the short term.
> > > >
> > > > Cheers,
> > > > Gary
> > > >
> > > > PS: I think it that everyone should be concerned that the
> definition
> > > of CAR
> > > > is being massaged
> > > > into a being a replacement for the proposal to perform
> CT from MN
> to
> > > access
> > > > network - a concept
> > > > that the working group did not favour, for many good, technical,
> > > reasons.
> > > >
> > > > > -----Original Message-----
> > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > > > Sent: April 3, 2002 01:21
> > > > > To: kempf@docomolabs-usa.com
> > > > > Cc: seamoby@ietf.org
> > > > > Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery
> > > > >
> > > > >
> > > > > Hi James,
> > > > > > > What NSIS will be working on is a generalized
> framework, to
> > > enable
> > > > > > > end to edge signaling, end to end signaling and perhaps
> > > > > edge to edge
> > > > > > > signaling.
> > > > > > >
> > > > > > > For the end-to-edge signaling, the access network (maybe
> even
> > > the
> > > > > > > access router) would/could be proxying QoS for network
> > > > > towards the
> > > > > > > end node.
> > > > > > >
> > > > > >
> > > > > > So it sounds to me the only issue is that NSIS would look at
> > > > > > prehandoff or posthandoff end to edge (host to
> > > network?) signaling
> > > > > > rather than at the time of handoff, is that right?
> > > > >
> > > > > I'm not sure what you mean.  I will say it another way.
> > > NSIS would
> > > > > not like to re-negotiate QoS after each handoff.  If Seamoby
> could
> > > > > do some work with CARD (pre-handoff) and CT (during &
> > > post-handoff)
> > > > > that would make renogotiation less needed, that would
> be great.
> > > > >
> > > > > John
> > > > >
> > > > > _______________________________________________
> > > > > Seamoby mailing list
> > > > > Seamoby@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > >
> > > >
> > >
> > >
> >
>
>

------_=_NextPart_001_01C1DB4E.3AB34044-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 16: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 QAA15754 for ; Wed, 3 Apr 2002 16: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 PAA25848; Wed, 3 Apr 2002 15:47: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 PAA25818 for ; Wed, 3 Apr 2002 15:47: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 PAA15325 for ; Wed, 3 Apr 2002 15:47:46 -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 g33Kl9I22999; Wed, 3 Apr 2002 12:47:09 -0800 (PST) Message-ID: <027301c1db50$7f61b160$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA49A8@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:45:32 -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 why would I need a discovery protocol if I was subscribed to Docomo > access > services and choosing between Docomo 802.11 access and Docomo GPRS access? > And why > would I need it to handoff between Docomo 802.11 access and Docomo GPRS > access? > Like I said, hotspot coverage may not be continuous and so it would be convenient to have some way to inform the user or some software on the laptop when such service is available so they can turn on the interface card. The presumption is that they keep the card off (as I do with my 802.11 interface on my laptop) when there is no service to avoid unnecessary power drain or interference, such as on an airplane. Also, if The Operator has multiple kinds of coverage, they could just as easily offer a proprietary solution. An interoperability standard is needed because there will be some operators who won't offer hotspot service, but they will have business arrangements with others who do. Does this sound too simple? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 3 16:07: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 QAA15766 for ; Wed, 3 Apr 2002 16:07:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27017 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 16: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 PAA25848; Wed, 3 Apr 2002 15:47: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 PAA25818 for ; Wed, 3 Apr 2002 15:47: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 PAA15325 for ; Wed, 3 Apr 2002 15:47:46 -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 g33Kl9I22999; Wed, 3 Apr 2002 12:47:09 -0800 (PST) Message-ID: <027301c1db50$7f61b160$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA49A8@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 12:45:32 -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 why would I need a discovery protocol if I was subscribed to Docomo > access > services and choosing between Docomo 802.11 access and Docomo GPRS access? > And why > would I need it to handoff between Docomo 802.11 access and Docomo GPRS > access? > Like I said, hotspot coverage may not be continuous and so it would be convenient to have some way to inform the user or some software on the laptop when such service is available so they can turn on the interface card. The presumption is that they keep the card off (as I do with my 802.11 interface on my laptop) when there is no service to avoid unnecessary power drain or interference, such as on an airplane. Also, if The Operator has multiple kinds of coverage, they could just as easily offer a proprietary solution. An interoperability standard is needed because there will be some operators who won't offer hotspot service, but they will have business arrangements with others who do. Does this sound too simple? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 16:25: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 QAA16188 for ; Wed, 3 Apr 2002 16:25: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 QAA27059; Wed, 3 Apr 2002 16: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 QAA27030 for ; Wed, 3 Apr 2002 16:07:32 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15783 for ; Wed, 3 Apr 2002 16:07:27 -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 g33L6Pi13662; Wed, 3 Apr 2002 16:06:25 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 16:06:27 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49AB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 16:06:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB53.6759260E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB53.6759260E Content-Type: text/plain; charset="iso-8859-1" No, not too simple. But I still haven't heard a need for a dynamic protocol, particularly over-the-air. Inter-operability can be resolved through SLAs. I agree that you need some indication in the change of availability of coverage, however, I wonder how you will detect the recent availability of an 802.11 channel if your modem is powered down ;^}? It's probably time to drop this thread. I will monitor the list to see if I can discern an answer to my main question. Thanks, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 15:46 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > But why would I need a discovery protocol if I was subscribed to > Docomo > > access > > services and choosing between Docomo 802.11 access and Docomo GPRS > access? > > And why > > would I need it to handoff between Docomo 802.11 access and Docomo > GPRS > > access? > > > > Like I said, hotspot coverage may not be continuous and so it would be > convenient to have some way to inform the user or some software on the > laptop when such service is available so they can turn on the > interface > card. The presumption is that they keep the card off (as I do with my > 802.11 interface on my laptop) when there is no service to avoid > unnecessary power drain or interference, such as on an airplane. > > Also, if The Operator has multiple kinds of coverage, they > could just as > easily offer a proprietary solution. An interoperability standard is > needed because there will be some operators who won't offer hotspot > service, but they will have business arrangements with others who do. > > Does this sound too simple? > > jak > > ------_=_NextPart_001_01C1DB53.6759260E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

No, not too simple. But I still haven't heard a need for a dynamic
protocol, particularly over-the-air. Inter-operability can be resolved
through SLAs. 

I agree that you need some indication in the change of availability of
coverage, however, I wonder how you will detect the recent availability of
an 802.11 channel if your modem is powered down ;^}?

It's probably time to drop this thread. I will monitor the list to see
if I can discern an answer to my main question.

Thanks,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 15:46
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > But why would I need a discovery protocol if I was subscribed to
> Docomo
> > access
> > services and choosing between Docomo 802.11 access and Docomo GPRS
> access?
> > And why
> > would I need it to handoff between Docomo 802.11 access and Docomo
> GPRS
> > access?
> >
>
> Like I said, hotspot coverage may not be continuous and so it would be
> convenient to have some way to inform the user or some software on the
> laptop when such service is available so they can turn on the
> interface
> card. The presumption is that they keep the card off (as I do with my
> 802.11 interface on my laptop) when there is no service to avoid
> unnecessary power drain or interference, such as on an airplane.
>
> Also, if The Operator has multiple kinds of coverage, they
> could just as
> easily offer a proprietary solution. An interoperability standard is
> needed because there will be some operators who won't offer hotspot
> service, but they will have business arrangements with others who do.
>
> Does this sound too simple?
>
>                 jak
>
>

------_=_NextPart_001_01C1DB53.6759260E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 3 16:25: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 QAA16199 for ; Wed, 3 Apr 2002 16:25:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27781 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 16:25: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 QAA27059; Wed, 3 Apr 2002 16: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 QAA27030 for ; Wed, 3 Apr 2002 16:07:32 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15783 for ; Wed, 3 Apr 2002 16:07:27 -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 g33L6Pi13662; Wed, 3 Apr 2002 16:06:25 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 16:06:27 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49AB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Wed, 3 Apr 2002 16:06:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB53.6759260E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DB53.6759260E Content-Type: text/plain; charset="iso-8859-1" No, not too simple. But I still haven't heard a need for a dynamic protocol, particularly over-the-air. Inter-operability can be resolved through SLAs. I agree that you need some indication in the change of availability of coverage, however, I wonder how you will detect the recent availability of an 802.11 channel if your modem is powered down ;^}? It's probably time to drop this thread. I will monitor the list to see if I can discern an answer to my main question. Thanks, Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 3, 2002 15:46 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > But why would I need a discovery protocol if I was subscribed to > Docomo > > access > > services and choosing between Docomo 802.11 access and Docomo GPRS > access? > > And why > > would I need it to handoff between Docomo 802.11 access and Docomo > GPRS > > access? > > > > Like I said, hotspot coverage may not be continuous and so it would be > convenient to have some way to inform the user or some software on the > laptop when such service is available so they can turn on the > interface > card. The presumption is that they keep the card off (as I do with my > 802.11 interface on my laptop) when there is no service to avoid > unnecessary power drain or interference, such as on an airplane. > > Also, if The Operator has multiple kinds of coverage, they > could just as > easily offer a proprietary solution. An interoperability standard is > needed because there will be some operators who won't offer hotspot > service, but they will have business arrangements with others who do. > > Does this sound too simple? > > jak > > ------_=_NextPart_001_01C1DB53.6759260E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

No, not too simple. But I still haven't heard a need for a dynamic
protocol, particularly over-the-air. Inter-operability can be resolved
through SLAs. 

I agree that you need some indication in the change of availability of
coverage, however, I wonder how you will detect the recent availability of
an 802.11 channel if your modem is powered down ;^}?

It's probably time to drop this thread. I will monitor the list to see
if I can discern an answer to my main question.

Thanks,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 15:46
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > But why would I need a discovery protocol if I was subscribed to
> Docomo
> > access
> > services and choosing between Docomo 802.11 access and Docomo GPRS
> access?
> > And why
> > would I need it to handoff between Docomo 802.11 access and Docomo
> GPRS
> > access?
> >
>
> Like I said, hotspot coverage may not be continuous and so it would be
> convenient to have some way to inform the user or some software on the
> laptop when such service is available so they can turn on the
> interface
> card. The presumption is that they keep the card off (as I do with my
> 802.11 interface on my laptop) when there is no service to avoid
> unnecessary power drain or interference, such as on an airplane.
>
> Also, if The Operator has multiple kinds of coverage, they
> could just as
> easily offer a proprietary solution. An interoperability standard is
> needed because there will be some operators who won't offer hotspot
> service, but they will have business arrangements with others who do.
>
> Does this sound too simple?
>
>                 jak
>
>

------_=_NextPart_001_01C1DB53.6759260E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 20: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 UAA21052 for ; Wed, 3 Apr 2002 20:53: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 UAA12335; Wed, 3 Apr 2002 20:37: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 UAA12306 for ; Wed, 3 Apr 2002 20:37:33 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20765 for ; Wed, 3 Apr 2002 20:37:30 -0500 (EST) From: Hakan.N.Persson@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 03:37:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB79.4C3A03C4" Subject: RE: [Seamoby] Examples of CAR discovery Date: Thu, 4 Apr 2002 03:37:35 +0200 Message-ID: <75D1795582274D49B4AFC02A165E879818A785@TMS041MB.tcad.telia.se> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHamjArkI+ITN6WSw+oFTSKG8K1uwA0YCyg To: , , , , X-OriginalArrivalTime: 04 Apr 2002 01:37:36.0538 (UTC) FILETIME=[4C9407A0:01C1DB79] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C1DB79.4C3A03C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would assume that the SIR and other specific L2 measurements used for = handover are/would be best specified where the specific access = techniques are defined, or? Not all techniques can provide everything. = Then the selection algorithm for inter-technology/networking need to use = those available togehter with any other available info.=20 =20 /H=E5kan -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 3 april 2002 01:00 To: Persson, H=E5kan N. /Research /08-713 82 33, 070-588 16 12; = kempf@docomolabs-usa.com; john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery SIR: For SIR to be a useful inter-networking, inter-technology, handover = parameter, we would have to standardize not only the parameter, but the method for measuring SIR, would we not? This = would also be true for BER? Latency (for an example of the latter I refer to the debates over the EF RFC in Diff Serv). =20 Gary -----Original Message----- From: Hakan.N.Persson@telia.se [mailto:Hakan.N.Persson@telia.se] Sent: April 2, 2002 17:21 To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; = john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Hi, =20 =20 Also, the L2 measures like signal to interference ratios (SIR) etc. can = be used, possibly together with some other information like required SIR = for a specific QoS requirement, to estimate how much "bandwidth" are = available to use for new users with a specific QoS requirement. If there = are more than one candidate AP/AR available then it is useful to choose = the one that meet your QoS needs also from a load situation point of = view and not only the radio situation. If not, then either the QoS will = be too poor or you may loose the connection. This not an IP level choice = but more a L2 choice even if there are more than one radio technology = involved.=20 =20 However an access router also need to have the required capacity to = admit new users with specific QoS requirements and if a certain AR does = not have the required capacity on IP level then the same problem will = occur as above if the required QoS on e.g. IP-level cannot be fulfilled. = Otherwise the assumption need to be that the AR capacity is always = assumed to be dimensioned such that it could handle all expected traffic = to/from the connected access points and the outgoing routes. =20 Regards, H=E5kan Persson =20 -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 2 april 2002 19:06 To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Actually, the usual measures for handover for wireless networks are=20 very much QoS related. In noise limited systems (e.g. AMPS), the measure = used is Signal to Noise Ratio (SNR); in interference limited systems = (e.g. CDMA)=20 the measure used is Carrier to Interference Ratio (CIR), where the = interference=20 comes from primarly other MNs. There are also a number of wireless data = systems=20 out there that use BER as a measure.=20 In all of these cases, the measure is used to determine whether there is = a "better"=20 channel for communications. This is L2 QoS.=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: April 2, 2002 11:44=20 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] Examples of CAR discovery=20 >=20 >=20 > John,=20 >=20 > > > So it sounds to me like dynamic QoS negotiation for handover=20 > > > has fallen between the cracks of the WGs.=20 > >=20 > > Do we need full-blown dynamic QoS negotiation for handover?=20 > Originally=20 > > (meaning circa last spring, after the MicroMobility work was removed = > from=20 > > SeaMoby), part of the access router section work was to be a=20 > capabilities=20 > > exchange between ARs, or so I thought. Thinking in terms of baby=20 > steps,=20 > > havning some mechanism which allows a basic mechanisms=20 > (which may end=20 > up=20 > > looking like context tranfer) would not be a bad thing.=20 > >=20 > > To express it more concretely, AR1 and AR2 exchange capability=20 > information.=20 > > This could be done using context transfer even ...=20 > >=20 >=20 > I think what is desired here is a way to take IP level QoS into=20 > consideration when selecting the next access point and access=20 > router to=20 > move to. Today only power is taken into consideration, and=20 > that at Layer=20 > 2.=20 >=20 > jak=20 >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 >=20 ------_=_NextPart_001_01C1DB79.4C3A03C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Examples of CAR discovery
I=20 would assume that the SIR and other specific L2 measurements used for = handover=20 are/would be best specified where the specific access = techniques are=20 defined, or? Not all techniques can provide everything. Then the = selection=20 algorithm for inter-technology/networking need to use those available = togehter=20 with any other available info. 
 
/H=E5kan
-----Original Message-----
From: Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: den 3 april 2002=20 01:00
To: Persson, H=E5kan N. /Research /08-713 82 33, = 070-588 16 12;=20 kempf@docomolabs-usa.com; john.loughney@nokia.com; = hchaskar@hotmail.com;=20 seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR=20 discovery

SIR: For SIR to be a useful = inter-networking,=20 inter-technology, handover parameter, we would have to standardize not = only
the parameter, but the method for measuring = SIR,=20 would we not? This would also be true for BER? Latency (for an example = of
the latter I refer to the debates over the = EF RFC in=20 Diff Serv).
 
Gary
-----Original Message-----
From: = Hakan.N.Persson@telia.se=20 [mailto:Hakan.N.Persson@telia.se]
Sent: April 2, 2002=20 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH];=20 kempf@docomolabs-usa.com; john.loughney@nokia.com; = hchaskar@hotmail.com;=20 seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR=20 discovery

Hi,  
 
Also, the L2 measures like signal to interference = ratios (SIR)=20 etc. can be used, possibly together with some other=20 information like required SIR for a specific QoS requirement, = to=20 estimate how much "bandwidth" are available to use for new = users=20 with a specific QoS requirement. If there are more than one=20 candidate AP/AR available then it is useful to=20 choose the one that meet your QoS needs also = from=20 a load situation point of view and not only the radio = situation. If=20 not, then either the QoS will be too poor or you may loose the=20 connection. This not an IP level choice but more a L2 = choice even=20 if there are more than one radio technology involved. =
 
However an access router also need to have the required = capacity to=20 admit new users with specific QoS requirements and if a certain = AR does not have the required capacity on IP level then the = same=20 problem will occur as above if the required QoS on e.g. IP-level = cannot be=20 fulfilled. Otherwise the assumption need = to be that=20 the AR capacity is always assumed to be dimensioned such that it = could=20 handle all expected traffic to/from the connected access points and = the=20 outgoing routes.
 
Regards,
H=E5kan Persson
 
-----Original Message-----
From: Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: den 2 april = 2002=20 19:06
To: 'James Kempf'; john.loughney@nokia.com;=20 hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: = [Seamoby]=20 Examples of CAR discovery

Actually, the usual measures for handover for = wireless=20 networks are
very much QoS related. In = noise=20 limited systems (e.g. AMPS), the measure
used is=20 Signal to Noise Ratio (SNR); in interference limited systems (e.g. = CDMA)
the measure used is Carrier to = Interference=20 Ratio (CIR), where the interference
comes from=20 primarly other MNs. There are also a number of wireless data=20 systems
out there that use BER as a = measure.=20

In all of these cases, the measure is used to = determine=20 whether there is a "better"
channel for=20 communications. This is L2 QoS.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: April 2, 2002 11:44
> To: john.loughney@nokia.com; hchaskar@hotmail.com;=20 seamoby@ietf.org
> Subject: Re: = [Seamoby]=20 Examples of CAR discovery
> =
>
> John, =
>
> > > So it = sounds to me like=20 dynamic QoS negotiation for handover
> >=20 > has fallen between the cracks of the WGs.
> >
> > Do we need = full-blown=20 dynamic QoS negotiation for handover?
>=20 Originally
> > (meaning circa last = spring,=20 after the MicroMobility work was removed
>=20 from
> > SeaMoby), part of the = access router=20 section work was to be a
> = capabilities=20
> > exchange between ARs, or so I = thought. =20 Thinking in terms of baby
> = steps,=20
> > havning some mechanism which allows a = basic=20 mechanisms
> (which may end =
> up
> > looking like = context=20 tranfer) would not be a bad thing.
>=20 >
> > To express it more = concretely, AR1=20 and AR2 exchange capability
>=20 information.
> > This could be = done using=20 context transfer even ...
> = >=20
>
> I think = what is desired=20 here is a way to take IP level QoS into
>=20 consideration when selecting the next access point and access=20
> router to
> move=20 to. Today only power is taken into consideration, and =
> that at Layer
> = 2.
>
>          =   =20 jak
>
>=20
>=20 _______________________________________________
> Seamoby mailing list
>=20 Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby= =20
>=20

------_=_NextPart_001_01C1DB79.4C3A03C4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 3 20:53: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 UAA21065 for ; Wed, 3 Apr 2002 20:53:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA12704 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 20:53: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 UAA12335; Wed, 3 Apr 2002 20:37: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 UAA12306 for ; Wed, 3 Apr 2002 20:37:33 -0500 (EST) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20765 for ; Wed, 3 Apr 2002 20:37:30 -0500 (EST) From: Hakan.N.Persson@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 03:37:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB79.4C3A03C4" Subject: RE: [Seamoby] Examples of CAR discovery Date: Thu, 4 Apr 2002 03:37:35 +0200 Message-ID: <75D1795582274D49B4AFC02A165E879818A785@TMS041MB.tcad.telia.se> Thread-Topic: [Seamoby] Examples of CAR discovery Thread-Index: AcHamjArkI+ITN6WSw+oFTSKG8K1uwA0YCyg To: , , , , X-OriginalArrivalTime: 04 Apr 2002 01:37:36.0538 (UTC) FILETIME=[4C9407A0:01C1DB79] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C1DB79.4C3A03C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would assume that the SIR and other specific L2 measurements used for = handover are/would be best specified where the specific access = techniques are defined, or? Not all techniques can provide everything. = Then the selection algorithm for inter-technology/networking need to use = those available togehter with any other available info.=20 =20 /H=E5kan -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 3 april 2002 01:00 To: Persson, H=E5kan N. /Research /08-713 82 33, 070-588 16 12; = kempf@docomolabs-usa.com; john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery SIR: For SIR to be a useful inter-networking, inter-technology, handover = parameter, we would have to standardize not only the parameter, but the method for measuring SIR, would we not? This = would also be true for BER? Latency (for an example of the latter I refer to the debates over the EF RFC in Diff Serv). =20 Gary -----Original Message----- From: Hakan.N.Persson@telia.se [mailto:Hakan.N.Persson@telia.se] Sent: April 2, 2002 17:21 To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; = john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Hi, =20 =20 Also, the L2 measures like signal to interference ratios (SIR) etc. can = be used, possibly together with some other information like required SIR = for a specific QoS requirement, to estimate how much "bandwidth" are = available to use for new users with a specific QoS requirement. If there = are more than one candidate AP/AR available then it is useful to choose = the one that meet your QoS needs also from a load situation point of = view and not only the radio situation. If not, then either the QoS will = be too poor or you may loose the connection. This not an IP level choice = but more a L2 choice even if there are more than one radio technology = involved.=20 =20 However an access router also need to have the required capacity to = admit new users with specific QoS requirements and if a certain AR does = not have the required capacity on IP level then the same problem will = occur as above if the required QoS on e.g. IP-level cannot be fulfilled. = Otherwise the assumption need to be that the AR capacity is always = assumed to be dimensioned such that it could handle all expected traffic = to/from the connected access points and the outgoing routes. =20 Regards, H=E5kan Persson =20 -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: den 2 april 2002 19:06 To: 'James Kempf'; john.loughney@nokia.com; hchaskar@hotmail.com; = seamoby@ietf.org Subject: RE: [Seamoby] Examples of CAR discovery Actually, the usual measures for handover for wireless networks are=20 very much QoS related. In noise limited systems (e.g. AMPS), the measure = used is Signal to Noise Ratio (SNR); in interference limited systems = (e.g. CDMA)=20 the measure used is Carrier to Interference Ratio (CIR), where the = interference=20 comes from primarly other MNs. There are also a number of wireless data = systems=20 out there that use BER as a measure.=20 In all of these cases, the measure is used to determine whether there is = a "better"=20 channel for communications. This is L2 QoS.=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: April 2, 2002 11:44=20 > To: john.loughney@nokia.com; hchaskar@hotmail.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] Examples of CAR discovery=20 >=20 >=20 > John,=20 >=20 > > > So it sounds to me like dynamic QoS negotiation for handover=20 > > > has fallen between the cracks of the WGs.=20 > >=20 > > Do we need full-blown dynamic QoS negotiation for handover?=20 > Originally=20 > > (meaning circa last spring, after the MicroMobility work was removed = > from=20 > > SeaMoby), part of the access router section work was to be a=20 > capabilities=20 > > exchange between ARs, or so I thought. Thinking in terms of baby=20 > steps,=20 > > havning some mechanism which allows a basic mechanisms=20 > (which may end=20 > up=20 > > looking like context tranfer) would not be a bad thing.=20 > >=20 > > To express it more concretely, AR1 and AR2 exchange capability=20 > information.=20 > > This could be done using context transfer even ...=20 > >=20 >=20 > I think what is desired here is a way to take IP level QoS into=20 > consideration when selecting the next access point and access=20 > router to=20 > move to. Today only power is taken into consideration, and=20 > that at Layer=20 > 2.=20 >=20 > jak=20 >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 >=20 ------_=_NextPart_001_01C1DB79.4C3A03C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Examples of CAR discovery
I=20 would assume that the SIR and other specific L2 measurements used for = handover=20 are/would be best specified where the specific access = techniques are=20 defined, or? Not all techniques can provide everything. Then the = selection=20 algorithm for inter-technology/networking need to use those available = togehter=20 with any other available info. 
 
/H=E5kan
-----Original Message-----
From: Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: den 3 april 2002=20 01:00
To: Persson, H=E5kan N. /Research /08-713 82 33, = 070-588 16 12;=20 kempf@docomolabs-usa.com; john.loughney@nokia.com; = hchaskar@hotmail.com;=20 seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR=20 discovery

SIR: For SIR to be a useful = inter-networking,=20 inter-technology, handover parameter, we would have to standardize not = only
the parameter, but the method for measuring = SIR,=20 would we not? This would also be true for BER? Latency (for an example = of
the latter I refer to the debates over the = EF RFC in=20 Diff Serv).
 
Gary
-----Original Message-----
From: = Hakan.N.Persson@telia.se=20 [mailto:Hakan.N.Persson@telia.se]
Sent: April 2, 2002=20 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH];=20 kempf@docomolabs-usa.com; john.loughney@nokia.com; = hchaskar@hotmail.com;=20 seamoby@ietf.org
Subject: RE: [Seamoby] Examples of CAR=20 discovery

Hi,  
 
Also, the L2 measures like signal to interference = ratios (SIR)=20 etc. can be used, possibly together with some other=20 information like required SIR for a specific QoS requirement, = to=20 estimate how much "bandwidth" are available to use for new = users=20 with a specific QoS requirement. If there are more than one=20 candidate AP/AR available then it is useful to=20 choose the one that meet your QoS needs also = from=20 a load situation point of view and not only the radio = situation. If=20 not, then either the QoS will be too poor or you may loose the=20 connection. This not an IP level choice but more a L2 = choice even=20 if there are more than one radio technology involved. =
 
However an access router also need to have the required = capacity to=20 admit new users with specific QoS requirements and if a certain = AR does not have the required capacity on IP level then the = same=20 problem will occur as above if the required QoS on e.g. IP-level = cannot be=20 fulfilled. Otherwise the assumption need = to be that=20 the AR capacity is always assumed to be dimensioned such that it = could=20 handle all expected traffic to/from the connected access points and = the=20 outgoing routes.
 
Regards,
H=E5kan Persson
 
-----Original Message-----
From: Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: den 2 april = 2002=20 19:06
To: 'James Kempf'; john.loughney@nokia.com;=20 hchaskar@hotmail.com; seamoby@ietf.org
Subject: RE: = [Seamoby]=20 Examples of CAR discovery

Actually, the usual measures for handover for = wireless=20 networks are
very much QoS related. In = noise=20 limited systems (e.g. AMPS), the measure
used is=20 Signal to Noise Ratio (SNR); in interference limited systems (e.g. = CDMA)
the measure used is Carrier to = Interference=20 Ratio (CIR), where the interference
comes from=20 primarly other MNs. There are also a number of wireless data=20 systems
out there that use BER as a = measure.=20

In all of these cases, the measure is used to = determine=20 whether there is a "better"
channel for=20 communications. This is L2 QoS.

Gary


> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: April 2, 2002 11:44
> To: john.loughney@nokia.com; hchaskar@hotmail.com;=20 seamoby@ietf.org
> Subject: Re: = [Seamoby]=20 Examples of CAR discovery
> =
>
> John, =
>
> > > So it = sounds to me like=20 dynamic QoS negotiation for handover
> >=20 > has fallen between the cracks of the WGs.
> >
> > Do we need = full-blown=20 dynamic QoS negotiation for handover?
>=20 Originally
> > (meaning circa last = spring,=20 after the MicroMobility work was removed
>=20 from
> > SeaMoby), part of the = access router=20 section work was to be a
> = capabilities=20
> > exchange between ARs, or so I = thought. =20 Thinking in terms of baby
> = steps,=20
> > havning some mechanism which allows a = basic=20 mechanisms
> (which may end =
> up
> > looking like = context=20 tranfer) would not be a bad thing.
>=20 >
> > To express it more = concretely, AR1=20 and AR2 exchange capability
>=20 information.
> > This could be = done using=20 context transfer even ...
> = >=20
>
> I think = what is desired=20 here is a way to take IP level QoS into
>=20 consideration when selecting the next access point and access=20
> router to
> move=20 to. Today only power is taken into consideration, and =
> that at Layer
> = 2.
>
>          =   =20 jak
>
>=20
>=20 _______________________________________________
> Seamoby mailing list
>=20 Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby= =20
>=20

------_=_NextPart_001_01C1DB79.4C3A03C4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 22:48: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 WAA24847 for ; Wed, 3 Apr 2002 22:48: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 WAA17964; Wed, 3 Apr 2002 22:32: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 WAA17923 for ; Wed, 3 Apr 2002 22:32:17 -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 WAA24426 for ; Wed, 3 Apr 2002 22:32:13 -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 g343VRu16022 for ; Thu, 4 Apr 2002 06:31:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 06:32:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 06:32:15 +0300 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] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 06:32:13 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA4@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbSY9rXRlW8GngS7mtm2mgam2PQQAP2ETg To: , Cc: X-OriginalArrivalTime: 04 Apr 2002 03:32:15.0593 (UTC) FILETIME=[50D08590:01C1DB89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA17924 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > The real overlap I was concerned with was between CT and NSIS. There is no overlap. > What is the role of NSIS with regards to handover? There is no role of NSIS in a handover. > If NSIS is invoked to establish/negotiate QoS for a handover, what happens > to the context being transferred? NSIS will not be invoked to establish/negotiate QoS for a handover. In chartering NSIS, discussion of Seamoby came up with the ADs. The idea was that NSIS may use CT for QoS support with handovers. I hope CT is done soon, so that NSIS could use CT ... John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 3 22:48: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 WAA24860 for ; Wed, 3 Apr 2002 22:48:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA18886 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 22:48: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 WAA17964; Wed, 3 Apr 2002 22:32: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 WAA17923 for ; Wed, 3 Apr 2002 22:32:17 -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 WAA24426 for ; Wed, 3 Apr 2002 22:32:13 -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 g343VRu16022 for ; Thu, 4 Apr 2002 06:31:27 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 06:32:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 06:32:15 +0300 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] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 06:32:13 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA4@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbSY9rXRlW8GngS7mtm2mgam2PQQAP2ETg To: , Cc: X-OriginalArrivalTime: 04 Apr 2002 03:32:15.0593 (UTC) FILETIME=[50D08590:01C1DB89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA17924 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > The real overlap I was concerned with was between CT and NSIS. There is no overlap. > What is the role of NSIS with regards to handover? There is no role of NSIS in a handover. > If NSIS is invoked to establish/negotiate QoS for a handover, what happens > to the context being transferred? NSIS will not be invoked to establish/negotiate QoS for a handover. In chartering NSIS, discussion of Seamoby came up with the ADs. The idea was that NSIS may use CT for QoS support with handovers. I hope CT is done soon, so that NSIS could use CT ... John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 3 22:56: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 WAA25033 for ; Wed, 3 Apr 2002 22: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 WAA18321; Wed, 3 Apr 2002 22:37: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 WAA18292 for ; Wed, 3 Apr 2002 22:37:32 -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 WAA24493 for ; Wed, 3 Apr 2002 22:37:25 -0500 (EST) From: john.loughney@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 g343bh518470 for ; Thu, 4 Apr 2002 06:37:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 06:37:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 06:37:27 +0300 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] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 06:37:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA6@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbNvivhXP3fECXSVa3sqICtXnsegAUuAkQ To: Cc: X-OriginalArrivalTime: 04 Apr 2002 03:37:27.0956 (UTC) FILETIME=[0AFF5540:01C1DB8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA18293 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > "5.1.2 Resource availability information on request > In some scenarios, e.g., the mobile terminal scenario, it is > required to query, whether resources are available, without > performing a reservation on the resource. One solution might be a > feedback mechanism based on which a QoS inferred handover can take > place." As there is no CARD solution yet, NSIS may need to have its own solution, unless CARD meets NSIS' needs. However, feel free to bring this up on the NSIS list. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 3 22: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 WAA25042 for ; Wed, 3 Apr 2002 22:56:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA19206 for seamoby-archive@odin.ietf.org; Wed, 3 Apr 2002 22: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 WAA18321; Wed, 3 Apr 2002 22:37: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 WAA18292 for ; Wed, 3 Apr 2002 22:37:32 -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 WAA24493 for ; Wed, 3 Apr 2002 22:37:25 -0500 (EST) From: john.loughney@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 g343bh518470 for ; Thu, 4 Apr 2002 06:37:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Apr 2002 06:37:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 06:37:27 +0300 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] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 06:37:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA6@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] NSIS was:Examples of CAR discovery Thread-Index: AcHbNvivhXP3fECXSVa3sqICtXnsegAUuAkQ To: Cc: X-OriginalArrivalTime: 04 Apr 2002 03:37:27.0956 (UTC) FILETIME=[0AFF5540:01C1DB8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA18293 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Gary, > "5.1.2 Resource availability information on request > In some scenarios, e.g., the mobile terminal scenario, it is > required to query, whether resources are available, without > performing a reservation on the resource. One solution might be a > feedback mechanism based on which a QoS inferred handover can take > place." As there is no CARD solution yet, NSIS may need to have its own solution, unless CARD meets NSIS' needs. However, feel free to bring this up on the NSIS list. John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 4 02:47: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 CAA06287 for ; Thu, 4 Apr 2002 02: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 CAA09448; Thu, 4 Apr 2002 02:20: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 CAA09381 for ; Thu, 4 Apr 2002 02:20:46 -0500 (EST) Received: from hotmail.com (oe70.law4.hotmail.com [216.33.148.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05969 for ; Thu, 4 Apr 2002 02:20:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 3 Apr 2002 23:20:15 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "Gary Kenward" , "'James Kempf'" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA49AB@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 16:25:22 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023D_01C1DBF5.51A2AA90" 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: 04 Apr 2002 07:20:15.0781 (UTC) FILETIME=[2AD78D50:01C1DBA9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_023D_01C1DBF5.51A2AA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: NSIS was:Examples of CAR discoveryHi, Gary, The idea is that the current access router can inform the mobile node of = the availability of other access technology if the current access router = has the knowledge. Then the mobile node can turn on, for example, the 802.11 interface and = start scanning for the (802.11) L2 beacon. The advantage of this approach is that the mobile node does not have to = keep the 802.11 interface on all the time. I think this advantage = applies no matter whether the different access networks belong to the = same operator or now. A dynamic protocol that enables the current access router to have such = knowledge is necessary. Being dynamic is, of course, good because the = availability of the 802.11 channel may change. We have not discussed about concrete solutions (or the actual discovery = protocol) yet on the mailing list. So we will have to see what will be = over-the-air and what others won't. Hope this may answer your question. Thanks. Eunsoo ----- Original Message -----=20 From: Gary Kenward=20 To: 'James Kempf' ; john.loughney@nokia.com=20 Cc: seamoby@ietf.org=20 Sent: Wednesday, April 03, 2002 1:06 PM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery No, not too simple. But I still haven't heard a need for a dynamic=20 protocol, particularly over-the-air. Inter-operability can be resolved = through SLAs. =20 I agree that you need some indication in the change of availability of = coverage, however, I wonder how you will detect the recent = availability of=20 an 802.11 channel if your modem is powered down ;^}?=20 It's probably time to drop this thread. I will monitor the list to see = if I can discern an answer to my main question.=20 Thanks,=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: April 3, 2002 15:46=20 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com=20 > Cc: seamoby@ietf.org=20 > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery=20 >=20 >=20 > > But why would I need a discovery protocol if I was subscribed to=20 > Docomo=20 > > access=20 > > services and choosing between Docomo 802.11 access and Docomo GPRS = > access?=20 > > And why=20 > > would I need it to handoff between Docomo 802.11 access and Docomo = > GPRS=20 > > access?=20 > >=20 >=20 > Like I said, hotspot coverage may not be continuous and so it would = be=20 > convenient to have some way to inform the user or some software on = the=20 > laptop when such service is available so they can turn on the=20 > interface=20 > card. The presumption is that they keep the card off (as I do with = my=20 > 802.11 interface on my laptop) when there is no service to avoid=20 > unnecessary power drain or interference, such as on an airplane.=20 >=20 > Also, if The Operator has multiple kinds of coverage, they=20 > could just as=20 > easily offer a proprietary solution. An interoperability standard is = > needed because there will be some operators who won't offer hotspot=20 > service, but they will have business arrangements with others who = do.=20 >=20 > Does this sound too simple?=20 >=20 > jak=20 >=20 >=20 ------=_NextPart_000_023D_01C1DBF5.51A2AA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: NSIS was:Examples of CAR = discovery
Hi, Gary,
 
The idea is that the current access = router can=20 inform the mobile node of the availability of other = access technology if=20 the current access router has the knowledge.
Then the mobile node can turn on, for = example, the=20 802.11 interface and start scanning for the (802.11) L2=20 beacon.
The advantage of this approach is = that the=20 mobile node does not have to keep the 802.11 interface on all the time. = I think=20 this advantage applies no matter whether the different access networks = belong to=20 the same operator or now.
 
A dynamic protocol that enables the = current access=20 router to have such knowledge is necessary. Being dynamic is, of course, = good=20 because the availability of the 802.11 channel may change.
 
We have not discussed about = concrete solutions=20 (or the actual discovery protocol) yet on the mailing list. So we will = have to=20 see what will be over-the-air and what others won't.
 
Hope this may answer your = question.
Thanks.
 
Eunsoo
----- Original Message -----
From:=20 Gary Kenward
To: 'James Kempf' ; john.loughney@nokia.com =
Sent: Wednesday, April 03, 2002 = 1:06=20 PM
Subject: RE: [Seamoby] RE: NSIS = was:Examples of CAR discovery

No, not too simple. But I still haven't heard a need = for a=20 dynamic
protocol, particularly over-the-air. = Inter-operability can be resolved
through = SLAs. =20

I agree that you need some indication in the change = of=20 availability of
coverage, however, I wonder = how you=20 will detect the recent availability of
an = 802.11=20 channel if your modem is powered down ;^}?

It's probably time to drop this thread. I will = monitor the=20 list to see
if I can discern an answer to my = main=20 question.

Thanks,
Gary

> -----Original Message-----
>=20 From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: April 3, 2002 15:46
>=20 To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com =
> Cc: seamoby@ietf.org
> = Subject: Re:=20 [Seamoby] RE: NSIS was:Examples of CAR discovery
>=20
>
> > But = why would I=20 need a discovery protocol if I was subscribed to
>=20 Docomo
> > access
>=20 > services and choosing between Docomo 802.11 access and Docomo = GPRS=20
> access?
> > = And why=20
> > would I need it to handoff between Docomo = 802.11=20 access and Docomo
> GPRS
> > access?
> > =
>
> Like I said, hotspot = coverage may not=20 be continuous and so it would be
> = convenient to=20 have some way to inform the user or some software on the =
> laptop when such service is available so they can turn = on the=20
> interface
> card. The=20 presumption is that they keep the card off (as I do with my =
> 802.11 interface on my laptop) when there is no service = to=20 avoid
> unnecessary power drain or = interference,=20 such as on an airplane.
> =
> Also, if The Operator has multiple kinds of coverage, = they=20
> could just as
> easily=20 offer a proprietary solution. An interoperability standard is =
> needed because there will be some operators who won't = offer=20 hotspot
> service, but they will have = business=20 arrangements with others who do.
> =
> Does this sound too simple?
>=20
>          =       =20 jak
>
>=20

------=_NextPart_000_023D_01C1DBF5.51A2AA90-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 4 02:47: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 CAA06297 for ; Thu, 4 Apr 2002 02:47:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA10784 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 02:47: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 CAA09448; Thu, 4 Apr 2002 02:20: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 CAA09381 for ; Thu, 4 Apr 2002 02:20:46 -0500 (EST) Received: from hotmail.com (oe70.law4.hotmail.com [216.33.148.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05969 for ; Thu, 4 Apr 2002 02:20:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 3 Apr 2002 23:20:15 -0800 X-Originating-IP: [211.192.81.212] From: "Eunsoo Shim" To: "Gary Kenward" , "'James Kempf'" , Cc: References: <9FBD322B7824D511B36900508BF93C9C01AA49AB@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 16:25:22 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023D_01C1DBF5.51A2AA90" 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: 04 Apr 2002 07:20:15.0781 (UTC) FILETIME=[2AD78D50:01C1DBA9] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_023D_01C1DBF5.51A2AA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: NSIS was:Examples of CAR discoveryHi, Gary, The idea is that the current access router can inform the mobile node of = the availability of other access technology if the current access router = has the knowledge. Then the mobile node can turn on, for example, the 802.11 interface and = start scanning for the (802.11) L2 beacon. The advantage of this approach is that the mobile node does not have to = keep the 802.11 interface on all the time. I think this advantage = applies no matter whether the different access networks belong to the = same operator or now. A dynamic protocol that enables the current access router to have such = knowledge is necessary. Being dynamic is, of course, good because the = availability of the 802.11 channel may change. We have not discussed about concrete solutions (or the actual discovery = protocol) yet on the mailing list. So we will have to see what will be = over-the-air and what others won't. Hope this may answer your question. Thanks. Eunsoo ----- Original Message -----=20 From: Gary Kenward=20 To: 'James Kempf' ; john.loughney@nokia.com=20 Cc: seamoby@ietf.org=20 Sent: Wednesday, April 03, 2002 1:06 PM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery No, not too simple. But I still haven't heard a need for a dynamic=20 protocol, particularly over-the-air. Inter-operability can be resolved = through SLAs. =20 I agree that you need some indication in the change of availability of = coverage, however, I wonder how you will detect the recent = availability of=20 an 802.11 channel if your modem is powered down ;^}?=20 It's probably time to drop this thread. I will monitor the list to see = if I can discern an answer to my main question.=20 Thanks,=20 Gary=20 > -----Original Message-----=20 > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: April 3, 2002 15:46=20 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com=20 > Cc: seamoby@ietf.org=20 > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery=20 >=20 >=20 > > But why would I need a discovery protocol if I was subscribed to=20 > Docomo=20 > > access=20 > > services and choosing between Docomo 802.11 access and Docomo GPRS = > access?=20 > > And why=20 > > would I need it to handoff between Docomo 802.11 access and Docomo = > GPRS=20 > > access?=20 > >=20 >=20 > Like I said, hotspot coverage may not be continuous and so it would = be=20 > convenient to have some way to inform the user or some software on = the=20 > laptop when such service is available so they can turn on the=20 > interface=20 > card. The presumption is that they keep the card off (as I do with = my=20 > 802.11 interface on my laptop) when there is no service to avoid=20 > unnecessary power drain or interference, such as on an airplane.=20 >=20 > Also, if The Operator has multiple kinds of coverage, they=20 > could just as=20 > easily offer a proprietary solution. An interoperability standard is = > needed because there will be some operators who won't offer hotspot=20 > service, but they will have business arrangements with others who = do.=20 >=20 > Does this sound too simple?=20 >=20 > jak=20 >=20 >=20 ------=_NextPart_000_023D_01C1DBF5.51A2AA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: NSIS was:Examples of CAR = discovery
Hi, Gary,
 
The idea is that the current access = router can=20 inform the mobile node of the availability of other = access technology if=20 the current access router has the knowledge.
Then the mobile node can turn on, for = example, the=20 802.11 interface and start scanning for the (802.11) L2=20 beacon.
The advantage of this approach is = that the=20 mobile node does not have to keep the 802.11 interface on all the time. = I think=20 this advantage applies no matter whether the different access networks = belong to=20 the same operator or now.
 
A dynamic protocol that enables the = current access=20 router to have such knowledge is necessary. Being dynamic is, of course, = good=20 because the availability of the 802.11 channel may change.
 
We have not discussed about = concrete solutions=20 (or the actual discovery protocol) yet on the mailing list. So we will = have to=20 see what will be over-the-air and what others won't.
 
Hope this may answer your = question.
Thanks.
 
Eunsoo
----- Original Message -----
From:=20 Gary Kenward
To: 'James Kempf' ; john.loughney@nokia.com =
Sent: Wednesday, April 03, 2002 = 1:06=20 PM
Subject: RE: [Seamoby] RE: NSIS = was:Examples of CAR discovery

No, not too simple. But I still haven't heard a need = for a=20 dynamic
protocol, particularly over-the-air. = Inter-operability can be resolved
through = SLAs. =20

I agree that you need some indication in the change = of=20 availability of
coverage, however, I wonder = how you=20 will detect the recent availability of
an = 802.11=20 channel if your modem is powered down ;^}?

It's probably time to drop this thread. I will = monitor the=20 list to see
if I can discern an answer to my = main=20 question.

Thanks,
Gary

> -----Original Message-----
>=20 From: James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: April 3, 2002 15:46
>=20 To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com =
> Cc: seamoby@ietf.org
> = Subject: Re:=20 [Seamoby] RE: NSIS was:Examples of CAR discovery
>=20
>
> > But = why would I=20 need a discovery protocol if I was subscribed to
>=20 Docomo
> > access
>=20 > services and choosing between Docomo 802.11 access and Docomo = GPRS=20
> access?
> > = And why=20
> > would I need it to handoff between Docomo = 802.11=20 access and Docomo
> GPRS
> > access?
> > =
>
> Like I said, hotspot = coverage may not=20 be continuous and so it would be
> = convenient to=20 have some way to inform the user or some software on the =
> laptop when such service is available so they can turn = on the=20
> interface
> card. The=20 presumption is that they keep the card off (as I do with my =
> 802.11 interface on my laptop) when there is no service = to=20 avoid
> unnecessary power drain or = interference,=20 such as on an airplane.
> =
> Also, if The Operator has multiple kinds of coverage, = they=20
> could just as
> easily=20 offer a proprietary solution. An interoperability standard is =
> needed because there will be some operators who won't = offer=20 hotspot
> service, but they will have = business=20 arrangements with others who do.
> =
> Does this sound too simple?
>=20
>          =       =20 jak
>
>=20

------=_NextPart_000_023D_01C1DBF5.51A2AA90-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 4 12: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 MAA23673 for ; Thu, 4 Apr 2002 12: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 LAA14768; Thu, 4 Apr 2002 11:59: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 LAA14739 for ; Thu, 4 Apr 2002 11:59: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 LAA22691 for ; Thu, 4 Apr 2002 11:59:19 -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 g34GwfI21567; Thu, 4 Apr 2002 08:58:45 -0800 (PST) Message-ID: <008101c1dbf9$c1ad1510$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA6@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 08:57: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 John, So we are in the requirements phase for CARD. Now would be just the right time for NSIS to come up with an email or draft that described its needs for CARD. Any later and there is a risk that we might miss something. jak ----- Original Message ----- From: To: Cc: Sent: Wednesday, April 03, 2002 7:37 PM Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > Hi Gary, > > > "5.1.2 Resource availability information on request > > In some scenarios, e.g., the mobile terminal scenario, it is > > required to query, whether resources are available, without > > performing a reservation on the resource. One solution might be a > > feedback mechanism based on which a QoS inferred handover can take > > place." > > As there is no CARD solution yet, NSIS may need to have its own > solution, unless CARD meets NSIS' needs. However, feel free to > bring this up on the NSIS list. > > 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 Apr 4 12: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 MAA23684 for ; Thu, 4 Apr 2002 12:13:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17215 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 12:13: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 LAA14768; Thu, 4 Apr 2002 11:59: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 LAA14739 for ; Thu, 4 Apr 2002 11:59: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 LAA22691 for ; Thu, 4 Apr 2002 11:59:19 -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 g34GwfI21567; Thu, 4 Apr 2002 08:58:45 -0800 (PST) Message-ID: <008101c1dbf9$c1ad1510$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DA6@esebe004.NOE.Nokia.com> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 08:57: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 John, So we are in the requirements phase for CARD. Now would be just the right time for NSIS to come up with an email or draft that described its needs for CARD. Any later and there is a risk that we might miss something. jak ----- Original Message ----- From: To: Cc: Sent: Wednesday, April 03, 2002 7:37 PM Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery > Hi Gary, > > > "5.1.2 Resource availability information on request > > In some scenarios, e.g., the mobile terminal scenario, it is > > required to query, whether resources are available, without > > performing a reservation on the resource. One solution might be a > > feedback mechanism based on which a QoS inferred handover can take > > place." > > As there is no CARD solution yet, NSIS may need to have its own > solution, unless CARD meets NSIS' needs. However, feel free to > bring this up on the NSIS list. > > 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 Apr 4 13:08: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 NAA28670 for ; Thu, 4 Apr 2002 13: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 MAA20060; Thu, 4 Apr 2002 12:54: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 MAA20032 for ; Thu, 4 Apr 2002 12:54:20 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28214 for ; Thu, 4 Apr 2002 12:54:18 -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 g34HopP12318; Thu, 4 Apr 2002 12:50:51 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 12:50:54 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49BF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Eunsoo Shim'" , "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 12:50:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC00.C3D8247C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DC00.C3D8247C Content-Type: text/plain; charset="iso-8859-1" Thanks Eunsoo. I have no problem with the basic concept of this advertisement. I do not support the idea of trying to capture the nature of the 802.11 channel, in particular dynamically. I do not believe that accurate (and thus useful) information can be captured and relayed. So be it. The usual way out of this is to allow the advertisement to contain data chunks that are opaque to the IP layer (and thus, to the IETF ;^} ). Gary -----Original Message----- From: Eunsoo Shim [mailto:eunsooshim@hotmail.com] Sent: April 4, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; john.loughney@nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Hi, Gary, The idea is that the current access router can inform the mobile node of the availability of other access technology if the current access router has the knowledge. Then the mobile node can turn on, for example, the 802.11 interface and start scanning for the (802.11) L2 beacon. The advantage of this approach is that the mobile node does not have to keep the 802.11 interface on all the time. I think this advantage applies no matter whether the different access networks belong to the same operator or now. A dynamic protocol that enables the current access router to have such knowledge is necessary. Being dynamic is, of course, good because the availability of the 802.11 channel may change. We have not discussed about concrete solutions (or the actual discovery protocol) yet on the mailing list. So we will have to see what will be over-the-air and what others won't. Hope this may answer your question. Thanks. Eunsoo ----- Original Message ----- From: Gary Kenward To: 'James Kempf' ; john.loughney@nokia.com Cc: seamoby@ietf.org Sent: Wednesday, April 03, 2002 1:06 PM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery No, not too simple. But I still haven't heard a need for a dynamic protocol, particularly over-the-air. Inter-operability can be resolved through SLAs. I agree that you need some indication in the change of availability of coverage, however, I wonder how you will detect the recent availability of an 802.11 channel if your modem is powered down ;^}? It's probably time to drop this thread. I will monitor the list to see if I can discern an answer to my main question. Thanks, Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: April 3, 2002 15:46 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > But why would I need a discovery protocol if I was subscribed to > Docomo > > access > > services and choosing between Docomo 802.11 access and Docomo GPRS > access? > > And why > > would I need it to handoff between Docomo 802.11 access and Docomo > GPRS > > access? > > > > Like I said, hotspot coverage may not be continuous and so it would be > convenient to have some way to inform the user or some software on the > laptop when such service is available so they can turn on the > interface > card. The presumption is that they keep the card off (as I do with my > 802.11 interface on my laptop) when there is no service to avoid > unnecessary power drain or interference, such as on an airplane. > > Also, if The Operator has multiple kinds of coverage, they > could just as > easily offer a proprietary solution. An interoperability standard is > needed because there will be some operators who won't offer hotspot > service, but they will have business arrangements with others who do. > > Does this sound too simple? > > jak > > ------_=_NextPart_001_01C1DC00.C3D8247C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
Thanks Eunsoo.
 
I have no problem with the basic concept of this advertisement. I do not support the idea of trying to capture the nature
of the 802.11 channel, in particular dynamically. I do not believe that accurate (and thus useful) information can be captured
and relayed.
 
So be it. The usual way out of this is to allow the advertisement to contain data chunks that are opaque to the IP layer (and thus,
to the IETF ;^} ).
 
Gary
-----Original Message-----
From: Eunsoo Shim [mailto:eunsooshim@hotmail.com]
Sent: April 4, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; john.loughney@nokia.com
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery

Hi, Gary,
 
The idea is that the current access router can inform the mobile node of the availability of other access technology if the current access router has the knowledge.
Then the mobile node can turn on, for example, the 802.11 interface and start scanning for the (802.11) L2 beacon.
The advantage of this approach is that the mobile node does not have to keep the 802.11 interface on all the time. I think this advantage applies no matter whether the different access networks belong to the same operator or now.
 
A dynamic protocol that enables the current access router to have such knowledge is necessary. Being dynamic is, of course, good because the availability of the 802.11 channel may change.
 
We have not discussed about concrete solutions (or the actual discovery protocol) yet on the mailing list. So we will have to see what will be over-the-air and what others won't.
 
Hope this may answer your question.
Thanks.
 
Eunsoo
----- Original Message -----
Sent: Wednesday, April 03, 2002 1:06 PM
Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

No, not too simple. But I still haven't heard a need for a dynamic
protocol, particularly over-the-air. Inter-operability can be resolved
through SLAs. 

I agree that you need some indication in the change of availability of
coverage, however, I wonder how you will detect the recent availability of
an 802.11 channel if your modem is powered down ;^}?

It's probably time to drop this thread. I will monitor the list to see
if I can discern an answer to my main question.

Thanks,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 15:46
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > But why would I need a discovery protocol if I was subscribed to
> Docomo
> > access
> > services and choosing between Docomo 802.11 access and Docomo GPRS
> access?
> > And why
> > would I need it to handoff between Docomo 802.11 access and Docomo
> GPRS
> > access?
> >
>
> Like I said, hotspot coverage may not be continuous and so it would be
> convenient to have some way to inform the user or some software on the
> laptop when such service is available so they can turn on the
> interface
> card. The presumption is that they keep the card off (as I do with my
> 802.11 interface on my laptop) when there is no service to avoid
> unnecessary power drain or interference, such as on an airplane.
>
> Also, if The Operator has multiple kinds of coverage, they
> could just as
> easily offer a proprietary solution. An interoperability standard is
> needed because there will be some operators who won't offer hotspot
> service, but they will have business arrangements with others who do.
>
> Does this sound too simple?
>
>                 jak
>
>

------_=_NextPart_001_01C1DC00.C3D8247C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 4 13:08: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 NAA28680 for ; Thu, 4 Apr 2002 13:08:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21269 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 13:08: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 MAA20060; Thu, 4 Apr 2002 12:54: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 MAA20032 for ; Thu, 4 Apr 2002 12:54:20 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28214 for ; Thu, 4 Apr 2002 12:54:18 -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 g34HopP12318; Thu, 4 Apr 2002 12:50:51 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 12:50:54 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49BF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Eunsoo Shim'" , "'James Kempf'" , john.loughney@nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 12:50:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DC00.C3D8247C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DC00.C3D8247C Content-Type: text/plain; charset="iso-8859-1" Thanks Eunsoo. I have no problem with the basic concept of this advertisement. I do not support the idea of trying to capture the nature of the 802.11 channel, in particular dynamically. I do not believe that accurate (and thus useful) information can be captured and relayed. So be it. The usual way out of this is to allow the advertisement to contain data chunks that are opaque to the IP layer (and thus, to the IETF ;^} ). Gary -----Original Message----- From: Eunsoo Shim [mailto:eunsooshim@hotmail.com] Sent: April 4, 2002 19:25 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; john.loughney@nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery Hi, Gary, The idea is that the current access router can inform the mobile node of the availability of other access technology if the current access router has the knowledge. Then the mobile node can turn on, for example, the 802.11 interface and start scanning for the (802.11) L2 beacon. The advantage of this approach is that the mobile node does not have to keep the 802.11 interface on all the time. I think this advantage applies no matter whether the different access networks belong to the same operator or now. A dynamic protocol that enables the current access router to have such knowledge is necessary. Being dynamic is, of course, good because the availability of the 802.11 channel may change. We have not discussed about concrete solutions (or the actual discovery protocol) yet on the mailing list. So we will have to see what will be over-the-air and what others won't. Hope this may answer your question. Thanks. Eunsoo ----- Original Message ----- From: Gary Kenward To: 'James Kempf' ; john.loughney@nokia.com Cc: seamoby@ietf.org Sent: Wednesday, April 03, 2002 1:06 PM Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery No, not too simple. But I still haven't heard a need for a dynamic protocol, particularly over-the-air. Inter-operability can be resolved through SLAs. I agree that you need some indication in the change of availability of coverage, however, I wonder how you will detect the recent availability of an 802.11 channel if your modem is powered down ;^}? It's probably time to drop this thread. I will monitor the list to see if I can discern an answer to my main question. Thanks, Gary > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: April 3, 2002 15:46 > To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com > Cc: seamoby@ietf.org > Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery > > > > But why would I need a discovery protocol if I was subscribed to > Docomo > > access > > services and choosing between Docomo 802.11 access and Docomo GPRS > access? > > And why > > would I need it to handoff between Docomo 802.11 access and Docomo > GPRS > > access? > > > > Like I said, hotspot coverage may not be continuous and so it would be > convenient to have some way to inform the user or some software on the > laptop when such service is available so they can turn on the > interface > card. The presumption is that they keep the card off (as I do with my > 802.11 interface on my laptop) when there is no service to avoid > unnecessary power drain or interference, such as on an airplane. > > Also, if The Operator has multiple kinds of coverage, they > could just as > easily offer a proprietary solution. An interoperability standard is > needed because there will be some operators who won't offer hotspot > service, but they will have business arrangements with others who do. > > Does this sound too simple? > > jak > > ------_=_NextPart_001_01C1DC00.C3D8247C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
Thanks Eunsoo.
 
I have no problem with the basic concept of this advertisement. I do not support the idea of trying to capture the nature
of the 802.11 channel, in particular dynamically. I do not believe that accurate (and thus useful) information can be captured
and relayed.
 
So be it. The usual way out of this is to allow the advertisement to contain data chunks that are opaque to the IP layer (and thus,
to the IETF ;^} ).
 
Gary
-----Original Message-----
From: Eunsoo Shim [mailto:eunsooshim@hotmail.com]
Sent: April 4, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; john.loughney@nokia.com
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery

Hi, Gary,
 
The idea is that the current access router can inform the mobile node of the availability of other access technology if the current access router has the knowledge.
Then the mobile node can turn on, for example, the 802.11 interface and start scanning for the (802.11) L2 beacon.
The advantage of this approach is that the mobile node does not have to keep the 802.11 interface on all the time. I think this advantage applies no matter whether the different access networks belong to the same operator or now.
 
A dynamic protocol that enables the current access router to have such knowledge is necessary. Being dynamic is, of course, good because the availability of the 802.11 channel may change.
 
We have not discussed about concrete solutions (or the actual discovery protocol) yet on the mailing list. So we will have to see what will be over-the-air and what others won't.
 
Hope this may answer your question.
Thanks.
 
Eunsoo
----- Original Message -----
Sent: Wednesday, April 03, 2002 1:06 PM
Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

No, not too simple. But I still haven't heard a need for a dynamic
protocol, particularly over-the-air. Inter-operability can be resolved
through SLAs. 

I agree that you need some indication in the change of availability of
coverage, however, I wonder how you will detect the recent availability of
an 802.11 channel if your modem is powered down ;^}?

It's probably time to drop this thread. I will monitor the list to see
if I can discern an answer to my main question.

Thanks,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 3, 2002 15:46
> To: Kenward, Gary [WDLN2:AN10:EXCH]; john.loughney@nokia.com
> Cc: seamoby@ietf.org
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
>
>
> > But why would I need a discovery protocol if I was subscribed to
> Docomo
> > access
> > services and choosing between Docomo 802.11 access and Docomo GPRS
> access?
> > And why
> > would I need it to handoff between Docomo 802.11 access and Docomo
> GPRS
> > access?
> >
>
> Like I said, hotspot coverage may not be continuous and so it would be
> convenient to have some way to inform the user or some software on the
> laptop when such service is available so they can turn on the
> interface
> card. The presumption is that they keep the card off (as I do with my
> 802.11 interface on my laptop) when there is no service to avoid
> unnecessary power drain or interference, such as on an airplane.
>
> Also, if The Operator has multiple kinds of coverage, they
> could just as
> easily offer a proprietary solution. An interoperability standard is
> needed because there will be some operators who won't offer hotspot
> service, but they will have business arrangements with others who do.
>
> Does this sound too simple?
>
>                 jak
>
>

------_=_NextPart_001_01C1DC00.C3D8247C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 4 16:04: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 QAA08759 for ; Thu, 4 Apr 2002 16:04: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 PAA01005; Thu, 4 Apr 2002 15:45: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 PAA00974 for ; Thu, 4 Apr 2002 15:45:23 -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 PAA08052 for ; Thu, 4 Apr 2002 15:45:20 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA25597 for ; Thu, 4 Apr 2002 13:45:22 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA16231 for ; Thu, 4 Apr 2002 13:45:22 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 14:45:21 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465001F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Charlie Perkins Cc: seamoby@ietf.org Date: Thu, 4 Apr 2002 14:45:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Charlie, The work you describe below sounds potentially valuable, but I really don't think Seamoby is the right place to standardize it, since it is not specifically focused on QoS. There may be need for QoS CT, but, again, I don't think Seamoby's charter extends to standardizing particular feature contexts. My understanding of the charter is that Seamoby will be standardizing on a container for CT. From what John described about about NSIS, I think it would fit into the charter (i.e. end to edge). Madjid>> Well there was talk about individual contexts, and there has been many drafts submitted, but your view is acceptable, however, now could you clarify, what would exactly fit in the charter? QoS context definition in CT, or QoS capability as part of CAR, or QoS end to edge signaling Thanks. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 4 16:04: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 QAA08768 for ; Thu, 4 Apr 2002 16:04:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02292 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 16:04: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 PAA01005; Thu, 4 Apr 2002 15:45: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 PAA00974 for ; Thu, 4 Apr 2002 15:45:23 -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 PAA08052 for ; Thu, 4 Apr 2002 15:45:20 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA25597 for ; Thu, 4 Apr 2002 13:45:22 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA16231 for ; Thu, 4 Apr 2002 13:45:22 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 14:45:21 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465001F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Charlie Perkins Cc: seamoby@ietf.org Date: Thu, 4 Apr 2002 14:45:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Charlie, The work you describe below sounds potentially valuable, but I really don't think Seamoby is the right place to standardize it, since it is not specifically focused on QoS. There may be need for QoS CT, but, again, I don't think Seamoby's charter extends to standardizing particular feature contexts. My understanding of the charter is that Seamoby will be standardizing on a container for CT. From what John described about about NSIS, I think it would fit into the charter (i.e. end to edge). Madjid>> Well there was talk about individual contexts, and there has been many drafts submitted, but your view is acceptable, however, now could you clarify, what would exactly fit in the charter? QoS context definition in CT, or QoS capability as part of CAR, or QoS end to edge signaling Thanks. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 4 16:22: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 QAA09213 for ; Thu, 4 Apr 2002 16:22: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 QAA02164; Thu, 4 Apr 2002 16:02: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 QAA02135 for ; Thu, 4 Apr 2002 16:02:17 -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 QAA08650 for ; Thu, 4 Apr 2002 16:02:07 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA12979 for ; Thu, 4 Apr 2002 14:02:10 -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 OAA24571 for ; Thu, 4 Apr 2002 14:02:10 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 15:02:10 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650020@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 15:02:08 -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 Marcus the idea behind CT was to transfer information that is common between the oldnetwork and new network. If the new network is forcing the MN to accept new allocations or if the QoS control mechanisms in the new network deploy different QoS information than the old network, then QoS CT is less beneficial. CT was never intended to do protocol matching or negotiations. And since it is a "seamoby" protocol, to my understanding it would not penetrate beyond the access network (or maybe even access router). end to end protocol signaling would not be handled by CT as defined in seamoby. BR, Madjid -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Wednesday, April 03, 2002 7:38 AM To: john.loughney@nokia.com; kempf@docomolabs-usa.com; charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery --On Tuesday, April 02, 2002 11:12 AM +0300 john.loughney@nokia.com wrote: [...] > I think that NSIS and SeaMoby / Context Transfer may interwork to provide > a good solution, in my opinion. I agree that CT might help for a good solution. However, for the QoS part, it is not only about a CT from one acess to anouther, but also about the rest of the path providing guarantees involved, where (as far as I understood the CT work) context transfer itself does not help too much. > NSIS most likely will be using a 'on path' signaling model, where the > QoS signaling takes the same path as the data. I don't think we have this aggreement in the NSIS group. Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing 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 Apr 4 16:22: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 QAA09222 for ; Thu, 4 Apr 2002 16:22:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02843 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 16:22: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 QAA02164; Thu, 4 Apr 2002 16:02: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 QAA02135 for ; Thu, 4 Apr 2002 16:02:17 -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 QAA08650 for ; Thu, 4 Apr 2002 16:02:07 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA12979 for ; Thu, 4 Apr 2002 14:02:10 -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 OAA24571 for ; Thu, 4 Apr 2002 14:02:10 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 15:02:10 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650020@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'brunner@ccrle.nec.de'" , john.loughney@nokia.com, kempf@docomolabs-usa.com, charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery Date: Thu, 4 Apr 2002 15:02:08 -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 Marcus the idea behind CT was to transfer information that is common between the oldnetwork and new network. If the new network is forcing the MN to accept new allocations or if the QoS control mechanisms in the new network deploy different QoS information than the old network, then QoS CT is less beneficial. CT was never intended to do protocol matching or negotiations. And since it is a "seamoby" protocol, to my understanding it would not penetrate beyond the access network (or maybe even access router). end to end protocol signaling would not be handled by CT as defined in seamoby. BR, Madjid -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Wednesday, April 03, 2002 7:38 AM To: john.loughney@nokia.com; kempf@docomolabs-usa.com; charliep@iprg.nokia.com Cc: seamoby@ietf.org Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery --On Tuesday, April 02, 2002 11:12 AM +0300 john.loughney@nokia.com wrote: [...] > I think that NSIS and SeaMoby / Context Transfer may interwork to provide > a good solution, in my opinion. I agree that CT might help for a good solution. However, for the QoS part, it is not only about a CT from one acess to anouther, but also about the rest of the path providing guarantees involved, where (as far as I understood the CT work) context transfer itself does not help too much. > NSIS most likely will be using a 'on path' signaling model, where the > QoS signaling takes the same path as the data. I don't think we have this aggreement in the NSIS group. Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Seamoby mailing 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 Apr 4 16: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 QAA09318 for ; Thu, 4 Apr 2002 16: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 QAA02528; Thu, 4 Apr 2002 16:12: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 QAA02497 for ; Thu, 4 Apr 2002 16:12: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 QAA08925 for ; Thu, 4 Apr 2002 16:12: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 g34LBjI01672; Thu, 4 Apr 2002 13:11:46 -0800 (PST) Message-ID: <02a601c1dc1d$19f9d410$7e6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Charlie Perkins" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0465001F@IL27EXM10.cig.mot.com> Date: Thu, 4 Apr 2002 13:10: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 Subject: [Seamoby] Re: What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit My reading of the charter is that Seamoby will standardize the container but not contents. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Charlie Perkins" Cc: Sent: Thursday, April 04, 2002 12:45 PM Subject: What aspect of QoS fits in (was examples of CAR...) > > > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > > > Madjid>> Well there was talk about individual contexts, and > there has been many drafts submitted, but your view is acceptable, > however, now could you clarify, what would exactly fit in the charter? > QoS context definition in CT, > or > QoS capability as part of CAR, > or > QoS end to edge signaling > > Thanks. > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 4 16:24: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 QAA09328 for ; Thu, 4 Apr 2002 16:24:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03003 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 16: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 QAA02528; Thu, 4 Apr 2002 16:12: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 QAA02497 for ; Thu, 4 Apr 2002 16:12: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 QAA08925 for ; Thu, 4 Apr 2002 16:12: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 g34LBjI01672; Thu, 4 Apr 2002 13:11:46 -0800 (PST) Message-ID: <02a601c1dc1d$19f9d410$7e6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Charlie Perkins" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0465001F@IL27EXM10.cig.mot.com> Date: Thu, 4 Apr 2002 13:10: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 Subject: [Seamoby] Re: What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit My reading of the charter is that Seamoby will standardize the container but not contents. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Charlie Perkins" Cc: Sent: Thursday, April 04, 2002 12:45 PM Subject: What aspect of QoS fits in (was examples of CAR...) > > > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > > > Madjid>> Well there was talk about individual contexts, and > there has been many drafts submitted, but your view is acceptable, > however, now could you clarify, what would exactly fit in the charter? > QoS context definition in CT, > or > QoS capability as part of CAR, > or > QoS end to edge signaling > > Thanks. > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 4 16:38: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 QAA09841 for ; Thu, 4 Apr 2002 16:38: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 QAA02988; Thu, 4 Apr 2002 16: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 QAA02959 for ; Thu, 4 Apr 2002 16:24:00 -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 QAA09306 for ; Thu, 4 Apr 2002 16:23:56 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA03336 for ; Thu, 4 Apr 2002 14:23:59 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA18125 for ; Thu, 4 Apr 2002 14:23:59 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 15:23:58 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650022@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Charlie Perkins Cc: seamoby@ietf.org Date: Thu, 4 Apr 2002 15:23:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Ok QoS context is out. But I am still confused about your statement > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > What aspect of NSIS/ QoS fits in the charter then??? QoS capabilities? Signaling? Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, April 04, 2002 3:10 PM To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins Cc: seamoby@ietf.org Subject: Re: What aspect of QoS fits in (was examples of CAR...) My reading of the charter is that Seamoby will standardize the container but not contents. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Charlie Perkins" Cc: Sent: Thursday, April 04, 2002 12:45 PM Subject: What aspect of QoS fits in (was examples of CAR...) > > > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > > > Madjid>> Well there was talk about individual contexts, and > there has been many drafts submitted, but your view is acceptable, > however, now could you clarify, what would exactly fit in the charter? > QoS context definition in CT, > or > QoS capability as part of CAR, > or > QoS end to edge signaling > > Thanks. > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 4 16:38: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 QAA09853 for ; Thu, 4 Apr 2002 16:38:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04250 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 16:38: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 QAA02988; Thu, 4 Apr 2002 16: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 QAA02959 for ; Thu, 4 Apr 2002 16:24:00 -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 QAA09306 for ; Thu, 4 Apr 2002 16:23:56 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA03336 for ; Thu, 4 Apr 2002 14:23:59 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA18125 for ; Thu, 4 Apr 2002 14:23:59 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 15:23:58 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650022@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Charlie Perkins Cc: seamoby@ietf.org Date: Thu, 4 Apr 2002 15:23:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Ok QoS context is out. But I am still confused about your statement > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > What aspect of NSIS/ QoS fits in the charter then??? QoS capabilities? Signaling? Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, April 04, 2002 3:10 PM To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins Cc: seamoby@ietf.org Subject: Re: What aspect of QoS fits in (was examples of CAR...) My reading of the charter is that Seamoby will standardize the container but not contents. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Charlie Perkins" Cc: Sent: Thursday, April 04, 2002 12:45 PM Subject: What aspect of QoS fits in (was examples of CAR...) > > > Charlie, > > The work you describe below sounds potentially valuable, but I really > don't think Seamoby is the right place to standardize it, since it is > not specifically focused on QoS. There may be need for QoS CT, but, > again, I don't think Seamoby's charter extends to standardizing > particular feature contexts. My understanding of the charter is that > Seamoby will be standardizing on a container for CT. > > >From what John described about about NSIS, I think it would fit into the > charter (i.e. end to edge). > > > Madjid>> Well there was talk about individual contexts, and > there has been many drafts submitted, but your view is acceptable, > however, now could you clarify, what would exactly fit in the charter? > QoS context definition in CT, > or > QoS capability as part of CAR, > or > QoS end to edge signaling > > Thanks. > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 4 17:10: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 RAA10795 for ; Thu, 4 Apr 2002 17:10: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 QAA04295; Thu, 4 Apr 2002 16:38: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 QAA04264 for ; Thu, 4 Apr 2002 16:38:42 -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 QAA09869 for ; Thu, 4 Apr 2002 16:38:38 -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 NAA21304; Thu, 4 Apr 2002 13:38:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34LcAT02251; Thu, 4 Apr 2002 13:38:10 -0800 X-mProtect: <200204042138> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt9XDxv; Thu, 04 Apr 2002 13:38:08 PST Message-ID: <3CACC7C0.44BA999F@iprg.nokia.com> Date: Thu, 04 Apr 2002 13:38:08 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR...) References: <35DBB8B7AC89D4118E98009027B1009B04650022@IL27EXM10.cig.mot.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 Hello Madjid, For myself, I wasn't trying to get QoS into the seamoby charter. However, I do think it is crucial to allow the seamoby CAR discovery protocol to handle the possibility of finding a suitable access router that has enough capacity available to fulfill the mobile node's needs. That is something that is dynamic. Without it, I would see CARD as almost useless. As the chair indicates, we don't have to standardize the contents, only the container. However, if we don't have some contents in mind, we might design the wrong container, or the wrong way to carry the container. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Ok QoS context is out. But I am still confused about your statement > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > What aspect of NSIS/ QoS fits in the charter then??? > QoS capabilities? Signaling? > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, April 04, 2002 3:10 PM > To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins > Cc: seamoby@ietf.org > Subject: Re: What aspect of QoS fits in (was examples of CAR...) > > My reading of the charter is that Seamoby will standardize the container > but not contents. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; "Charlie Perkins" > > Cc: > Sent: Thursday, April 04, 2002 12:45 PM > Subject: What aspect of QoS fits in (was examples of CAR...) > > > > > > > Charlie, > > > > The work you describe below sounds potentially valuable, but I really > > don't think Seamoby is the right place to standardize it, since it is > > not specifically focused on QoS. There may be need for QoS CT, but, > > again, I don't think Seamoby's charter extends to standardizing > > particular feature contexts. My understanding of the charter is that > > Seamoby will be standardizing on a container for CT. > > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > > > > Madjid>> Well there was talk about individual contexts, and > > there has been many drafts submitted, but your view is acceptable, > > however, now could you clarify, what would exactly fit in the charter? > > QoS context definition in CT, > > or > > QoS capability as part of CAR, > > or > > QoS end to edge signaling > > > > Thanks. > > > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 4 17:10: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 RAA10805 for ; Thu, 4 Apr 2002 17:10:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06538 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 17:10: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 QAA04295; Thu, 4 Apr 2002 16:38: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 QAA04264 for ; Thu, 4 Apr 2002 16:38:42 -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 QAA09869 for ; Thu, 4 Apr 2002 16:38:38 -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 NAA21304; Thu, 4 Apr 2002 13:38:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g34LcAT02251; Thu, 4 Apr 2002 13:38:10 -0800 X-mProtect: <200204042138> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt9XDxv; Thu, 04 Apr 2002 13:38:08 PST Message-ID: <3CACC7C0.44BA999F@iprg.nokia.com> Date: Thu, 04 Apr 2002 13:38:08 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR...) References: <35DBB8B7AC89D4118E98009027B1009B04650022@IL27EXM10.cig.mot.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 Hello Madjid, For myself, I wasn't trying to get QoS into the seamoby charter. However, I do think it is crucial to allow the seamoby CAR discovery protocol to handle the possibility of finding a suitable access router that has enough capacity available to fulfill the mobile node's needs. That is something that is dynamic. Without it, I would see CARD as almost useless. As the chair indicates, we don't have to standardize the contents, only the container. However, if we don't have some contents in mind, we might design the wrong container, or the wrong way to carry the container. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Ok QoS context is out. But I am still confused about your statement > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > What aspect of NSIS/ QoS fits in the charter then??? > QoS capabilities? Signaling? > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, April 04, 2002 3:10 PM > To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins > Cc: seamoby@ietf.org > Subject: Re: What aspect of QoS fits in (was examples of CAR...) > > My reading of the charter is that Seamoby will standardize the container > but not contents. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; "Charlie Perkins" > > Cc: > Sent: Thursday, April 04, 2002 12:45 PM > Subject: What aspect of QoS fits in (was examples of CAR...) > > > > > > > Charlie, > > > > The work you describe below sounds potentially valuable, but I really > > don't think Seamoby is the right place to standardize it, since it is > > not specifically focused on QoS. There may be need for QoS CT, but, > > again, I don't think Seamoby's charter extends to standardizing > > particular feature contexts. My understanding of the charter is that > > Seamoby will be standardizing on a container for CT. > > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > > > > Madjid>> Well there was talk about individual contexts, and > > there has been many drafts submitted, but your view is acceptable, > > however, now could you clarify, what would exactly fit in the charter? > > QoS context definition in CT, > > or > > QoS capability as part of CAR, > > or > > QoS end to edge signaling > > > > Thanks. > > > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 4 17:14: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 RAA10847 for ; Thu, 4 Apr 2002 17:14: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 QAA05057; Thu, 4 Apr 2002 16:57: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 QAA05029 for ; Thu, 4 Apr 2002 16:57:02 -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 QAA10294 for ; Thu, 4 Apr 2002 16:56:57 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA23143 for ; Thu, 4 Apr 2002 14:56:59 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA24600 for ; Thu, 4 Apr 2002 14:56:59 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 15:56:59 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650029@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR ...) Date: Thu, 4 Apr 2002 15:56:52 -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 Hi Charlie, I agree with you on both of your points. I don't think you need to standardize QoS control information either, since you would have many different QoS technologies to deal with, but I am not sure how useful a CARd protocol completely dismisses signaling of QoS capabilities (which could simply mean capacity to handle the flows or not) would be. Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Thursday, April 04, 2002 3:38 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: Re: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR...) Hello Madjid, For myself, I wasn't trying to get QoS into the seamoby charter. However, I do think it is crucial to allow the seamoby CAR discovery protocol to handle the possibility of finding a suitable access router that has enough capacity available to fulfill the mobile node's needs. That is something that is dynamic. Without it, I would see CARD as almost useless. As the chair indicates, we don't have to standardize the contents, only the container. However, if we don't have some contents in mind, we might design the wrong container, or the wrong way to carry the container. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Ok QoS context is out. But I am still confused about your statement > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > What aspect of NSIS/ QoS fits in the charter then??? > QoS capabilities? Signaling? > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, April 04, 2002 3:10 PM > To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins > Cc: seamoby@ietf.org > Subject: Re: What aspect of QoS fits in (was examples of CAR...) > > My reading of the charter is that Seamoby will standardize the container > but not contents. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; "Charlie Perkins" > > Cc: > Sent: Thursday, April 04, 2002 12:45 PM > Subject: What aspect of QoS fits in (was examples of CAR...) > > > > > > > Charlie, > > > > The work you describe below sounds potentially valuable, but I really > > don't think Seamoby is the right place to standardize it, since it is > > not specifically focused on QoS. There may be need for QoS CT, but, > > again, I don't think Seamoby's charter extends to standardizing > > particular feature contexts. My understanding of the charter is that > > Seamoby will be standardizing on a container for CT. > > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > > > > Madjid>> Well there was talk about individual contexts, and > > there has been many drafts submitted, but your view is acceptable, > > however, now could you clarify, what would exactly fit in the charter? > > QoS context definition in CT, > > or > > QoS capability as part of CAR, > > or > > QoS end to edge signaling > > > > Thanks. > > > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 4 17:14: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 RAA10857 for ; Thu, 4 Apr 2002 17:14:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06669 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 17: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 QAA05057; Thu, 4 Apr 2002 16:57: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 QAA05029 for ; Thu, 4 Apr 2002 16:57:02 -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 QAA10294 for ; Thu, 4 Apr 2002 16:56:57 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA23143 for ; Thu, 4 Apr 2002 14:56:59 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA24600 for ; Thu, 4 Apr 2002 14:56:59 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Apr 2002 15:56:59 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650029@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR ...) Date: Thu, 4 Apr 2002 15:56:52 -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 Hi Charlie, I agree with you on both of your points. I don't think you need to standardize QoS control information either, since you would have many different QoS technologies to deal with, but I am not sure how useful a CARd protocol completely dismisses signaling of QoS capabilities (which could simply mean capacity to handle the flows or not) would be. Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Thursday, April 04, 2002 3:38 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: Re: [Seamoby] RE: What aspect of QoS fits in (was examples of CAR...) Hello Madjid, For myself, I wasn't trying to get QoS into the seamoby charter. However, I do think it is crucial to allow the seamoby CAR discovery protocol to handle the possibility of finding a suitable access router that has enough capacity available to fulfill the mobile node's needs. That is something that is dynamic. Without it, I would see CARD as almost useless. As the chair indicates, we don't have to standardize the contents, only the container. However, if we don't have some contents in mind, we might design the wrong container, or the wrong way to carry the container. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Ok QoS context is out. But I am still confused about your statement > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > What aspect of NSIS/ QoS fits in the charter then??? > QoS capabilities? Signaling? > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, April 04, 2002 3:10 PM > To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins > Cc: seamoby@ietf.org > Subject: Re: What aspect of QoS fits in (was examples of CAR...) > > My reading of the charter is that Seamoby will standardize the container > but not contents. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; "Charlie Perkins" > > Cc: > Sent: Thursday, April 04, 2002 12:45 PM > Subject: What aspect of QoS fits in (was examples of CAR...) > > > > > > > Charlie, > > > > The work you describe below sounds potentially valuable, but I really > > don't think Seamoby is the right place to standardize it, since it is > > not specifically focused on QoS. There may be need for QoS CT, but, > > again, I don't think Seamoby's charter extends to standardizing > > particular feature contexts. My understanding of the charter is that > > Seamoby will be standardizing on a container for CT. > > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > > > > Madjid>> Well there was talk about individual contexts, and > > there has been many drafts submitted, but your view is acceptable, > > however, now could you clarify, what would exactly fit in the charter? > > QoS context definition in CT, > > or > > QoS capability as part of CAR, > > or > > QoS end to edge signaling > > > > Thanks. > > > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 4 18: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 SAA12693 for ; Thu, 4 Apr 2002 18: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 SAA10130; Thu, 4 Apr 2002 18:20: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 SAA10064 for ; Thu, 4 Apr 2002 18:20: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 SAA12498 for ; Thu, 4 Apr 2002 18:20: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 g34NJfI06765; Thu, 4 Apr 2002 15:19:42 -0800 (PST) Message-ID: <02ef01c1dc2e$f8f0c6e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Charlie Perkins" Cc: References: <35DBB8B7AC89D4118E98009027B1009B04650022@IL27EXM10.cig.mot.com> Date: Thu, 4 Apr 2002 15:18: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 Subject: [Seamoby] Re: What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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 assume signaling cause that's what NSIS is about. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Charlie Perkins" Cc: Sent: Thursday, April 04, 2002 1:23 PM Subject: RE: What aspect of QoS fits in (was examples of CAR...) > Ok QoS context is out. But I am still confused about your statement > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > What aspect of NSIS/ QoS fits in the charter then??? > QoS capabilities? Signaling? > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, April 04, 2002 3:10 PM > To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins > Cc: seamoby@ietf.org > Subject: Re: What aspect of QoS fits in (was examples of CAR...) > > > My reading of the charter is that Seamoby will standardize the container > but not contents. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; "Charlie Perkins" > > Cc: > Sent: Thursday, April 04, 2002 12:45 PM > Subject: What aspect of QoS fits in (was examples of CAR...) > > > > > > > > Charlie, > > > > The work you describe below sounds potentially valuable, but I really > > don't think Seamoby is the right place to standardize it, since it is > > not specifically focused on QoS. There may be need for QoS CT, but, > > again, I don't think Seamoby's charter extends to standardizing > > particular feature contexts. My understanding of the charter is that > > Seamoby will be standardizing on a container for CT. > > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > > > > Madjid>> Well there was talk about individual contexts, and > > there has been many drafts submitted, but your view is acceptable, > > however, now could you clarify, what would exactly fit in the charter? > > QoS context definition in CT, > > or > > QoS capability as part of CAR, > > or > > QoS end to edge signaling > > > > Thanks. > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 4 18: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 SAA12702 for ; Thu, 4 Apr 2002 18:33:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10932 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 18:33: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 SAA10130; Thu, 4 Apr 2002 18:20: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 SAA10064 for ; Thu, 4 Apr 2002 18:20: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 SAA12498 for ; Thu, 4 Apr 2002 18:20: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 g34NJfI06765; Thu, 4 Apr 2002 15:19:42 -0800 (PST) Message-ID: <02ef01c1dc2e$f8f0c6e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Charlie Perkins" Cc: References: <35DBB8B7AC89D4118E98009027B1009B04650022@IL27EXM10.cig.mot.com> Date: Thu, 4 Apr 2002 15:18: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 Subject: [Seamoby] Re: What aspect of QoS fits in (was examples of CAR...) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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 assume signaling cause that's what NSIS is about. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Charlie Perkins" Cc: Sent: Thursday, April 04, 2002 1:23 PM Subject: RE: What aspect of QoS fits in (was examples of CAR...) > Ok QoS context is out. But I am still confused about your statement > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > What aspect of NSIS/ QoS fits in the charter then??? > QoS capabilities? Signaling? > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, April 04, 2002 3:10 PM > To: Nakhjiri Madjid-MNAKHJI1; Charlie Perkins > Cc: seamoby@ietf.org > Subject: Re: What aspect of QoS fits in (was examples of CAR...) > > > My reading of the charter is that Seamoby will standardize the container > but not contents. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: "'James Kempf'" ; "Charlie Perkins" > > Cc: > Sent: Thursday, April 04, 2002 12:45 PM > Subject: What aspect of QoS fits in (was examples of CAR...) > > > > > > > > Charlie, > > > > The work you describe below sounds potentially valuable, but I really > > don't think Seamoby is the right place to standardize it, since it is > > not specifically focused on QoS. There may be need for QoS CT, but, > > again, I don't think Seamoby's charter extends to standardizing > > particular feature contexts. My understanding of the charter is that > > Seamoby will be standardizing on a container for CT. > > > > >From what John described about about NSIS, I think it would fit into > the > > charter (i.e. end to edge). > > > > > > Madjid>> Well there was talk about individual contexts, and > > there has been many drafts submitted, but your view is acceptable, > > however, now could you clarify, what would exactly fit in the charter? > > QoS context definition in CT, > > or > > QoS capability as part of CAR, > > or > > QoS end to edge signaling > > > > Thanks. > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 4 22:57: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 WAA18242 for ; Thu, 4 Apr 2002 22:57: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 WAA22685; Thu, 4 Apr 2002 22:39: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 WAA22656 for ; Thu, 4 Apr 2002 22:39:32 -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 WAA17884 for ; Thu, 4 Apr 2002 22:39:29 -0500 (EST) From: john.loughney@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 g353dk520304 for ; Fri, 5 Apr 2002 06:39:46 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 06:39:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 06:39:31 +0300 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] Re: What aspect of QoS fits in (was examples of CAR...) Date: Fri, 5 Apr 2002 06:39:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DC2@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Re: What aspect of QoS fits in (was examples of CAR...) Thread-Index: AcHcHXbHXeGhVLSuR/+T4tzpxNjVYQANeibw To: , , Cc: X-OriginalArrivalTime: 05 Apr 2002 03:39:31.0476 (UTC) FILETIME=[7F08BD40:01C1DC53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22657 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, > My reading of the charter is that Seamoby will standardize > the container but not contents. So no WG drafts on contents of SeaMoby containers. However, Personal Drafts are always OK. Should we get so far as to complete CT & CARD, rechartering is always possible ;) John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 4 22:57: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 WAA18254 for ; Thu, 4 Apr 2002 22:57:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA23174 for seamoby-archive@odin.ietf.org; Thu, 4 Apr 2002 22: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 WAA22685; Thu, 4 Apr 2002 22:39: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 WAA22656 for ; Thu, 4 Apr 2002 22:39:32 -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 WAA17884 for ; Thu, 4 Apr 2002 22:39:29 -0500 (EST) From: john.loughney@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 g353dk520304 for ; Fri, 5 Apr 2002 06:39:46 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 06:39:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 06:39:31 +0300 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] Re: What aspect of QoS fits in (was examples of CAR...) Date: Fri, 5 Apr 2002 06:39:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DC2@esebe004.NOE.Nokia.com> Thread-Topic: [Seamoby] Re: What aspect of QoS fits in (was examples of CAR...) Thread-Index: AcHcHXbHXeGhVLSuR/+T4tzpxNjVYQANeibw To: , , Cc: X-OriginalArrivalTime: 05 Apr 2002 03:39:31.0476 (UTC) FILETIME=[7F08BD40:01C1DC53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22657 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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, > My reading of the charter is that Seamoby will standardize > the container but not contents. So no WG drafts on contents of SeaMoby containers. However, Personal Drafts are always OK. Should we get so far as to complete CT & CARD, rechartering is always possible ;) John _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 11:23: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 LAA08826 for ; Fri, 5 Apr 2002 11:23: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 LAA10751; Fri, 5 Apr 2002 11:07: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 LAA10653 for ; Fri, 5 Apr 2002 11:07:07 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08328; Fri, 5 Apr 2002 11:06:44 -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 g35G67w25668; Fri, 5 Apr 2002 11:06:07 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 11:06:07 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org Cc: "'seamoby@ietf.org'" Date: Fri, 5 Apr 2002 11:06:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB8.3380F6AC" Subject: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCB8.3380F6AC Content-Type: text/plain; charset="iso-8859-1" Hemant: Just a point of clarification, but as I understand CARD (and I don't understand it well), it is not a QoS negotiation protocol. The main application that you are referring to primarily arises out of a perceived need to determine at the MN the best link layer to handover over to when inter-technology handovers are involved. It can be applied to intra-technology handovers, but the value in that situation is highly questionable (e.g. since it is a discovery protocol, the implication is that the purpose is to determine the choice of channels available; for intra-technology handovers, there are many, many reasons why this "choice" may not be available). There is a requirement, 5.1.2, which seems to imply NSIS involvement during/after a handover. John has stated that this is not the intention (please correct me if I have this wrong John), in which case I think 5.1.2 needs to be clarified. Specifically, is NSIS to be used to negotiated new QoS for an existing flow after a handover, or is it specifically for establishing QoS for a new flow? I don't think the answer is boolean: the role of NSIS in QoS re-negotiation is still open, I believe, and clearly handover is a dynamic situation that could cause the QoS provided to change. I have been told there is no issue, but here's a frightening scenario: - a handover takes place, and context transfer has been used to move the QoS context to the new routers (by the requirements for CT this could be intra-, or inter- technology. Some of us believe that for "seamless" handovers, the context will be available at routers before the first packets need to be forwarded. This implies that there is a relationship, probabilistic perhaps, between the handover process and the target ARs for CT. - CARD is used by the MN to influence the handover decision (it is not clear to me how this happens, but it seems clear that for a more "seamless" handover, the MN should chose an AR that has received the appropriate context; if not, then what? - NSIS kicks in and starts re-negotiating QoS because of changes introduced by the handover; How do these three protocols interact to produce predictable outcomes? Or, perhaps, the question is, how do the functional entities associated with the three protocols interact before, during and after a handover? If it the interaction is within the functional entities, the respective wg's could declare the issue out of scope, but this approach does not sit well with me, for it seems to defer the problem to the people who have to implement this "stuff". Am I imagining things? Cheers, Gary > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: April 4, 2002 22:33 > To: nsis@ietf.org > Subject: RE: [NSIS] Establishing QoS after handoff. > > > Hi Sharif: > > There is currently a debate going on in Seamoby as to whether > this QoS negotiation be covered by NSIS or Seamoby (CAR > discovery protocol). > > IMHO it should be covered by CAR discovery and not NSIS. CAR > discovery is supposed to identify candidate access routers > for handoff and QoS is an important property for candidacy. > > Br, > Hemant > > -----Original Message----- > From: ext Shahrier, Sharif M. > [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Thursday, April 04, 2002 3:35 PM > To: Shahrier, Sharif M. > Cc: 'nsis@ietf.org' > Subject: [NSIS] Establishing QoS after handoff. > > > > I have a question for clarification. > > I think it was stated that NSIS should only be concerned with the > establishment of QoS after handoff. > > This is inconvienent with respect to IP-level QoS > negotiation, which ideally > should be done before handoff has taken place. > > QoS negotiation is in the current requirements draft. > > So, NSIS signaling protocol development should be concerned > with activity > before handoff occurs. > > Sharif. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DCB8.3380F6AC Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] Establishing QoS after handoff.

Hemant:

  Just a point of clarification, but as I understand CARD (and
I don't understand it well), it is not a QoS negotiation
protocol. The main application that you are referring to primarily
arises out of a perceived need to determine at the MN the best link
layer to handover over to when inter-technology handovers are involved.
It can be applied to intra-technology handovers, but the value in
that situation is highly questionable (e.g. since it is a discovery
protocol, the implication is that the purpose is to determine the
choice of channels available; for intra-technology handovers, there
are many, many reasons why this "choice" may not be available).

  There is a requirement, 5.1.2, which seems to imply NSIS involvement
during/after a handover. John has stated that this is not the intention
(please correct me if I have this wrong John), in which case I think
5.1.2 needs to be clarified.

  Specifically, is NSIS to be used to negotiated new QoS for an
existing flow after a handover, or is it specifically for establishing
QoS for a new flow? I don't think the answer is boolean: the role
of NSIS in QoS re-negotiation is still open, I believe, and clearly
handover is a dynamic situation that could cause the QoS provided to change.

  I have been told there is no issue, but here's a frightening scenario:

        - a handover takes place, and context transfer has been used to
       move the QoS context to the new routers (by the requirements for
       CT this could be intra-, or inter- technology. Some of us believe
       that for "seamless" handovers, the context will be available at
       routers before the first packets need to be forwarded. This implies
       that there is a relationship, probabilistic perhaps, between
       the handover process and the target ARs for CT.

     - CARD is used by the MN to influence the handover decision (it
       is not clear to me how this happens, but it seems clear that
       for a more "seamless" handover, the MN should chose an AR that
       has received the appropriate context; if not, then what?

     - NSIS kicks in and starts re-negotiating QoS because of changes
       introduced by the handover;

  How do these three protocols interact to produce predictable outcomes?
Or, perhaps, the question is, how do the functional entities associated
with the three protocols interact before, during and after a handover?
If it the interaction is within the functional entities, the respective
wg's could declare the issue out of scope, but this approach does not
sit well with me, for it seems to defer the problem to the people who
have to implement this "stuff".

  Am I imagining things?

Cheers,
Gary


> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: April 4, 2002 22:33
> To: nsis@ietf.org
> Subject: RE: [NSIS] Establishing QoS after handoff.
>
>
> Hi Sharif:
>
> There is currently a debate going on in Seamoby as to whether
> this QoS negotiation be covered by NSIS or Seamoby (CAR
> discovery protocol).
>
> IMHO it should be covered by CAR discovery and not NSIS. CAR
> discovery is supposed to identify candidate access routers
> for handoff and QoS is an important property for candidacy.
>
> Br,
> Hemant
>
> -----Original Message-----
> From: ext Shahrier, Sharif M.
> [mailto:Sharif.Shahrier@InterDigital.com]
> Sent: Thursday, April 04, 2002 3:35 PM
> To: Shahrier, Sharif M.
> Cc: 'nsis@ietf.org'
> Subject: [NSIS] Establishing QoS after handoff.
>
>
>
> I have a question for clarification.
>
> I think it was stated that NSIS should only be concerned with the
> establishment of QoS after handoff.
>
> This is inconvienent with respect to IP-level QoS
> negotiation, which ideally
> should be done before handoff has taken place.
>
> QoS negotiation is in the current requirements draft.
>
> So, NSIS signaling protocol development should be concerned
> with activity
> before handoff occurs.
>
> Sharif.
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DCB8.3380F6AC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 11:23: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 LAA08836 for ; Fri, 5 Apr 2002 11:23:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11324 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 11:23: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 LAA10751; Fri, 5 Apr 2002 11:07: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 LAA10653 for ; Fri, 5 Apr 2002 11:07:07 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08328; Fri, 5 Apr 2002 11:06:44 -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 g35G67w25668; Fri, 5 Apr 2002 11:06:07 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 11:06:07 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org Cc: "'seamoby@ietf.org'" Date: Fri, 5 Apr 2002 11:06:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB8.3380F6AC" Subject: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCB8.3380F6AC Content-Type: text/plain; charset="iso-8859-1" Hemant: Just a point of clarification, but as I understand CARD (and I don't understand it well), it is not a QoS negotiation protocol. The main application that you are referring to primarily arises out of a perceived need to determine at the MN the best link layer to handover over to when inter-technology handovers are involved. It can be applied to intra-technology handovers, but the value in that situation is highly questionable (e.g. since it is a discovery protocol, the implication is that the purpose is to determine the choice of channels available; for intra-technology handovers, there are many, many reasons why this "choice" may not be available). There is a requirement, 5.1.2, which seems to imply NSIS involvement during/after a handover. John has stated that this is not the intention (please correct me if I have this wrong John), in which case I think 5.1.2 needs to be clarified. Specifically, is NSIS to be used to negotiated new QoS for an existing flow after a handover, or is it specifically for establishing QoS for a new flow? I don't think the answer is boolean: the role of NSIS in QoS re-negotiation is still open, I believe, and clearly handover is a dynamic situation that could cause the QoS provided to change. I have been told there is no issue, but here's a frightening scenario: - a handover takes place, and context transfer has been used to move the QoS context to the new routers (by the requirements for CT this could be intra-, or inter- technology. Some of us believe that for "seamless" handovers, the context will be available at routers before the first packets need to be forwarded. This implies that there is a relationship, probabilistic perhaps, between the handover process and the target ARs for CT. - CARD is used by the MN to influence the handover decision (it is not clear to me how this happens, but it seems clear that for a more "seamless" handover, the MN should chose an AR that has received the appropriate context; if not, then what? - NSIS kicks in and starts re-negotiating QoS because of changes introduced by the handover; How do these three protocols interact to produce predictable outcomes? Or, perhaps, the question is, how do the functional entities associated with the three protocols interact before, during and after a handover? If it the interaction is within the functional entities, the respective wg's could declare the issue out of scope, but this approach does not sit well with me, for it seems to defer the problem to the people who have to implement this "stuff". Am I imagining things? Cheers, Gary > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: April 4, 2002 22:33 > To: nsis@ietf.org > Subject: RE: [NSIS] Establishing QoS after handoff. > > > Hi Sharif: > > There is currently a debate going on in Seamoby as to whether > this QoS negotiation be covered by NSIS or Seamoby (CAR > discovery protocol). > > IMHO it should be covered by CAR discovery and not NSIS. CAR > discovery is supposed to identify candidate access routers > for handoff and QoS is an important property for candidacy. > > Br, > Hemant > > -----Original Message----- > From: ext Shahrier, Sharif M. > [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Thursday, April 04, 2002 3:35 PM > To: Shahrier, Sharif M. > Cc: 'nsis@ietf.org' > Subject: [NSIS] Establishing QoS after handoff. > > > > I have a question for clarification. > > I think it was stated that NSIS should only be concerned with the > establishment of QoS after handoff. > > This is inconvienent with respect to IP-level QoS > negotiation, which ideally > should be done before handoff has taken place. > > QoS negotiation is in the current requirements draft. > > So, NSIS signaling protocol development should be concerned > with activity > before handoff occurs. > > Sharif. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DCB8.3380F6AC Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] Establishing QoS after handoff.

Hemant:

  Just a point of clarification, but as I understand CARD (and
I don't understand it well), it is not a QoS negotiation
protocol. The main application that you are referring to primarily
arises out of a perceived need to determine at the MN the best link
layer to handover over to when inter-technology handovers are involved.
It can be applied to intra-technology handovers, but the value in
that situation is highly questionable (e.g. since it is a discovery
protocol, the implication is that the purpose is to determine the
choice of channels available; for intra-technology handovers, there
are many, many reasons why this "choice" may not be available).

  There is a requirement, 5.1.2, which seems to imply NSIS involvement
during/after a handover. John has stated that this is not the intention
(please correct me if I have this wrong John), in which case I think
5.1.2 needs to be clarified.

  Specifically, is NSIS to be used to negotiated new QoS for an
existing flow after a handover, or is it specifically for establishing
QoS for a new flow? I don't think the answer is boolean: the role
of NSIS in QoS re-negotiation is still open, I believe, and clearly
handover is a dynamic situation that could cause the QoS provided to change.

  I have been told there is no issue, but here's a frightening scenario:

        - a handover takes place, and context transfer has been used to
       move the QoS context to the new routers (by the requirements for
       CT this could be intra-, or inter- technology. Some of us believe
       that for "seamless" handovers, the context will be available at
       routers before the first packets need to be forwarded. This implies
       that there is a relationship, probabilistic perhaps, between
       the handover process and the target ARs for CT.

     - CARD is used by the MN to influence the handover decision (it
       is not clear to me how this happens, but it seems clear that
       for a more "seamless" handover, the MN should chose an AR that
       has received the appropriate context; if not, then what?

     - NSIS kicks in and starts re-negotiating QoS because of changes
       introduced by the handover;

  How do these three protocols interact to produce predictable outcomes?
Or, perhaps, the question is, how do the functional entities associated
with the three protocols interact before, during and after a handover?
If it the interaction is within the functional entities, the respective
wg's could declare the issue out of scope, but this approach does not
sit well with me, for it seems to defer the problem to the people who
have to implement this "stuff".

  Am I imagining things?

Cheers,
Gary


> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: April 4, 2002 22:33
> To: nsis@ietf.org
> Subject: RE: [NSIS] Establishing QoS after handoff.
>
>
> Hi Sharif:
>
> There is currently a debate going on in Seamoby as to whether
> this QoS negotiation be covered by NSIS or Seamoby (CAR
> discovery protocol).
>
> IMHO it should be covered by CAR discovery and not NSIS. CAR
> discovery is supposed to identify candidate access routers
> for handoff and QoS is an important property for candidacy.
>
> Br,
> Hemant
>
> -----Original Message-----
> From: ext Shahrier, Sharif M.
> [mailto:Sharif.Shahrier@InterDigital.com]
> Sent: Thursday, April 04, 2002 3:35 PM
> To: Shahrier, Sharif M.
> Cc: 'nsis@ietf.org'
> Subject: [NSIS] Establishing QoS after handoff.
>
>
>
> I have a question for clarification.
>
> I think it was stated that NSIS should only be concerned with the
> establishment of QoS after handoff.
>
> This is inconvienent with respect to IP-level QoS
> negotiation, which ideally
> should be done before handoff has taken place.
>
> QoS negotiation is in the current requirements draft.
>
> So, NSIS signaling protocol development should be concerned
> with activity
> before handoff occurs.
>
> Sharif.
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DCB8.3380F6AC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 12:18: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 MAA10562 for ; Fri, 5 Apr 2002 12:18: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 MAA14417; Fri, 5 Apr 2002 12:02: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 MAA14307 for ; Fri, 5 Apr 2002 12:01:52 -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 MAA09890; Fri, 5 Apr 2002 12:01:45 -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 JAA07869; Fri, 5 Apr 2002 09:01:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35H1HT16962; Fri, 5 Apr 2002 09:01:17 -0800 X-mProtect: <200204051701> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7kAR5Z; Fri, 05 Apr 2002 09:01:15 PST Message-ID: <3CADD85C.F8C8D50F@iprg.nokia.com> Date: Fri, 05 Apr 2002 09:01:16 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.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 Hello, well, if the issue is QoS establishment after handover, - CT is applicable for establishing QoS state at the AR - if further signaling is desired beyond the AR, NSIS may consider it. I don't see how _signaling_ for QoS establishment beyond AR is relevant for seamoby. CAR _discovery_ could exchange QoS capability as one of the parameters that might then be fed to a selection algorithm. Any signaling for actually establishing QoS itself beyond the AR should be outside the scope of seamoby.. Regards, -Rajeev Gary Kenward wrote: > > > Hemant: > > Just a point of clarification, but as I understand CARD (and > I don't understand it well), it is not a QoS negotiation > protocol. The main application that you are referring to primarily > arises out of a perceived need to determine at the MN the best link > layer to handover over to when inter-technology handovers are > involved. > It can be applied to intra-technology handovers, but the value in > that situation is highly questionable (e.g. since it is a discovery > protocol, the implication is that the purpose is to determine the > choice of channels available; for intra-technology handovers, there > are many, many reasons why this "choice" may not be available). > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > during/after a handover. John has stated that this is not the > intention > (please correct me if I have this wrong John), in which case I think > 5.1.2 needs to be clarified. > > Specifically, is NSIS to be used to negotiated new QoS for an > existing flow after a handover, or is it specifically for establishing > > QoS for a new flow? I don't think the answer is boolean: the role > of NSIS in QoS re-negotiation is still open, I believe, and clearly > handover is a dynamic situation that could cause the QoS provided to > change. > > I have been told there is no issue, but here's a frightening > scenario: > > - a handover takes place, and context transfer has been used > to > move the QoS context to the new routers (by the requirements > for > CT this could be intra-, or inter- technology. Some of us > believe > that for "seamless" handovers, the context will be available at > > routers before the first packets need to be forwarded. This > implies > that there is a relationship, probabilistic perhaps, between > the handover process and the target ARs for CT. > > - CARD is used by the MN to influence the handover decision (it > is not clear to me how this happens, but it seems clear that > for a more "seamless" handover, the MN should chose an AR that > has received the appropriate context; if not, then what? > > - NSIS kicks in and starts re-negotiating QoS because of changes > introduced by the handover; > > How do these three protocols interact to produce predictable > outcomes? > Or, perhaps, the question is, how do the functional entities > associated > with the three protocols interact before, during and after a handover? > > If it the interaction is within the functional entities, the > respective > wg's could declare the issue out of scope, but this approach does not > sit well with me, for it seems to defer the problem to the people who > have to implement this "stuff". > > Am I imagining things? > > Cheers, > Gary > > > -----Original Message----- > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > Sent: April 4, 2002 22:33 > > To: nsis@ietf.org > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > Hi Sharif: > > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > > > Br, > > Hemant > > > > -----Original Message----- > > From: ext Shahrier, Sharif M. > > [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Thursday, April 04, 2002 3:35 PM > > To: Shahrier, Sharif M. > > Cc: 'nsis@ietf.org' > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > I have a question for clarification. > > > > I think it was stated that NSIS should only be concerned with the > > establishment of QoS after handoff. > > > > This is inconvienent with respect to IP-level QoS > > negotiation, which ideally > > should be done before handoff has taken place. > > > > QoS negotiation is in the current requirements draft. > > > > So, NSIS signaling protocol development should be concerned > > with activity > > before handoff occurs. > > > > Sharif. > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 12:18: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 MAA10573 for ; Fri, 5 Apr 2002 12:18:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15363 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 12:18: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 MAA14417; Fri, 5 Apr 2002 12:02: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 MAA14307 for ; Fri, 5 Apr 2002 12:01:52 -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 MAA09890; Fri, 5 Apr 2002 12:01:45 -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 JAA07869; Fri, 5 Apr 2002 09:01:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35H1HT16962; Fri, 5 Apr 2002 09:01:17 -0800 X-mProtect: <200204051701> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7kAR5Z; Fri, 05 Apr 2002 09:01:15 PST Message-ID: <3CADD85C.F8C8D50F@iprg.nokia.com> Date: Fri, 05 Apr 2002 09:01:16 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.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 Hello, well, if the issue is QoS establishment after handover, - CT is applicable for establishing QoS state at the AR - if further signaling is desired beyond the AR, NSIS may consider it. I don't see how _signaling_ for QoS establishment beyond AR is relevant for seamoby. CAR _discovery_ could exchange QoS capability as one of the parameters that might then be fed to a selection algorithm. Any signaling for actually establishing QoS itself beyond the AR should be outside the scope of seamoby.. Regards, -Rajeev Gary Kenward wrote: > > > Hemant: > > Just a point of clarification, but as I understand CARD (and > I don't understand it well), it is not a QoS negotiation > protocol. The main application that you are referring to primarily > arises out of a perceived need to determine at the MN the best link > layer to handover over to when inter-technology handovers are > involved. > It can be applied to intra-technology handovers, but the value in > that situation is highly questionable (e.g. since it is a discovery > protocol, the implication is that the purpose is to determine the > choice of channels available; for intra-technology handovers, there > are many, many reasons why this "choice" may not be available). > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > during/after a handover. John has stated that this is not the > intention > (please correct me if I have this wrong John), in which case I think > 5.1.2 needs to be clarified. > > Specifically, is NSIS to be used to negotiated new QoS for an > existing flow after a handover, or is it specifically for establishing > > QoS for a new flow? I don't think the answer is boolean: the role > of NSIS in QoS re-negotiation is still open, I believe, and clearly > handover is a dynamic situation that could cause the QoS provided to > change. > > I have been told there is no issue, but here's a frightening > scenario: > > - a handover takes place, and context transfer has been used > to > move the QoS context to the new routers (by the requirements > for > CT this could be intra-, or inter- technology. Some of us > believe > that for "seamless" handovers, the context will be available at > > routers before the first packets need to be forwarded. This > implies > that there is a relationship, probabilistic perhaps, between > the handover process and the target ARs for CT. > > - CARD is used by the MN to influence the handover decision (it > is not clear to me how this happens, but it seems clear that > for a more "seamless" handover, the MN should chose an AR that > has received the appropriate context; if not, then what? > > - NSIS kicks in and starts re-negotiating QoS because of changes > introduced by the handover; > > How do these three protocols interact to produce predictable > outcomes? > Or, perhaps, the question is, how do the functional entities > associated > with the three protocols interact before, during and after a handover? > > If it the interaction is within the functional entities, the > respective > wg's could declare the issue out of scope, but this approach does not > sit well with me, for it seems to defer the problem to the people who > have to implement this "stuff". > > Am I imagining things? > > Cheers, > Gary > > > -----Original Message----- > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > Sent: April 4, 2002 22:33 > > To: nsis@ietf.org > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > Hi Sharif: > > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > > > Br, > > Hemant > > > > -----Original Message----- > > From: ext Shahrier, Sharif M. > > [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Thursday, April 04, 2002 3:35 PM > > To: Shahrier, Sharif M. > > Cc: 'nsis@ietf.org' > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > I have a question for clarification. > > > > I think it was stated that NSIS should only be concerned with the > > establishment of QoS after handoff. > > > > This is inconvienent with respect to IP-level QoS > > negotiation, which ideally > > should be done before handoff has taken place. > > > > QoS negotiation is in the current requirements draft. > > > > So, NSIS signaling protocol development should be concerned > > with activity > > before handoff occurs. > > > > Sharif. > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 12:27: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 MAA10792 for ; Fri, 5 Apr 2002 12:27: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 MAA15036; Fri, 5 Apr 2002 12:10: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 MAA14993 for ; Fri, 5 Apr 2002 12:10:10 -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 MAA10304; Fri, 5 Apr 2002 12:10: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 g35H94I00267; Fri, 5 Apr 2002 09:09:04 -0800 (PST) Message-ID: <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Gary Kenward" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 09:07: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 There is an issue if CT fails. In that case, some kind of negotiation after handover would be required. So, I'd say that some indication of CT failure is needed. As for CAR, I don't see the relevance for QoS negotiation, though it may be useful for finding a new wireless medium. I also see it primarily for intertechnology handover, or, at best, interprovider handover. jak ----- Original Message ----- From: "Rajeev Koodli" To: "Gary Kenward" Cc: ; ; Sent: Friday, April 05, 2002 9:01 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello, > > well, if the issue is QoS establishment after handover, > > - CT is applicable for establishing QoS state at the AR > - if further signaling is desired beyond the AR, NSIS may > consider it. I don't see how _signaling_ for QoS establishment > beyond AR is relevant for seamoby. > > CAR _discovery_ could exchange QoS capability as one of the > parameters that might then be fed to a selection algorithm. Any > signaling for actually establishing QoS itself beyond the AR > should be outside the scope of seamoby.. > > Regards, > > -Rajeev > > > Gary Kenward wrote: > > > > > > > Hemant: > > > > Just a point of clarification, but as I understand CARD (and > > I don't understand it well), it is not a QoS negotiation > > protocol. The main application that you are referring to primarily > > arises out of a perceived need to determine at the MN the best link > > layer to handover over to when inter-technology handovers are > > involved. > > It can be applied to intra-technology handovers, but the value in > > that situation is highly questionable (e.g. since it is a discovery > > protocol, the implication is that the purpose is to determine the > > choice of channels available; for intra-technology handovers, there > > are many, many reasons why this "choice" may not be available). > > > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > > > during/after a handover. John has stated that this is not the > > intention > > (please correct me if I have this wrong John), in which case I think > > 5.1.2 needs to be clarified. > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > existing flow after a handover, or is it specifically for establishing > > > > QoS for a new flow? I don't think the answer is boolean: the role > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > handover is a dynamic situation that could cause the QoS provided to > > change. > > > > I have been told there is no issue, but here's a frightening > > scenario: > > > > - a handover takes place, and context transfer has been used > > to > > move the QoS context to the new routers (by the requirements > > for > > CT this could be intra-, or inter- technology. Some of us > > believe > > that for "seamless" handovers, the context will be available at > > > > routers before the first packets need to be forwarded. This > > implies > > that there is a relationship, probabilistic perhaps, between > > the handover process and the target ARs for CT. > > > > - CARD is used by the MN to influence the handover decision (it > > is not clear to me how this happens, but it seems clear that > > for a more "seamless" handover, the MN should chose an AR that > > has received the appropriate context; if not, then what? > > > > - NSIS kicks in and starts re-negotiating QoS because of changes > > introduced by the handover; > > > > How do these three protocols interact to produce predictable > > outcomes? > > Or, perhaps, the question is, how do the functional entities > > associated > > with the three protocols interact before, during and after a handover? > > > > If it the interaction is within the functional entities, the > > respective > > wg's could declare the issue out of scope, but this approach does not > > sit well with me, for it seems to defer the problem to the people who > > have to implement this "stuff". > > > > Am I imagining things? > > > > Cheers, > > Gary > > > > > -----Original Message----- > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > Sent: April 4, 2002 22:33 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Hi Sharif: > > > > > > There is currently a debate going on in Seamoby as to whether > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > discovery protocol). > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > discovery is supposed to identify candidate access routers > > > for handoff and QoS is an important property for candidacy. > > > > > > Br, > > > Hemant > > > > > > -----Original Message----- > > > From: ext Shahrier, Sharif M. > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > Sent: Thursday, April 04, 2002 3:35 PM > > > To: Shahrier, Sharif M. > > > Cc: 'nsis@ietf.org' > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > I have a question for clarification. > > > > > > I think it was stated that NSIS should only be concerned with the > > > establishment of QoS after handoff. > > > > > > This is inconvienent with respect to IP-level QoS > > > negotiation, which ideally > > > should be done before handoff has taken place. > > > > > > QoS negotiation is in the current requirements draft. > > > > > > So, NSIS signaling protocol development should be concerned > > > with activity > > > before handoff occurs. > > > > > > Sharif. > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 5 12:27: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 MAA10802 for ; Fri, 5 Apr 2002 12:27:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15786 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 12:27: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 MAA15036; Fri, 5 Apr 2002 12:10: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 MAA14993 for ; Fri, 5 Apr 2002 12:10:10 -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 MAA10304; Fri, 5 Apr 2002 12:10: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 g35H94I00267; Fri, 5 Apr 2002 09:09:04 -0800 (PST) Message-ID: <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Gary Kenward" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 09:07: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 There is an issue if CT fails. In that case, some kind of negotiation after handover would be required. So, I'd say that some indication of CT failure is needed. As for CAR, I don't see the relevance for QoS negotiation, though it may be useful for finding a new wireless medium. I also see it primarily for intertechnology handover, or, at best, interprovider handover. jak ----- Original Message ----- From: "Rajeev Koodli" To: "Gary Kenward" Cc: ; ; Sent: Friday, April 05, 2002 9:01 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello, > > well, if the issue is QoS establishment after handover, > > - CT is applicable for establishing QoS state at the AR > - if further signaling is desired beyond the AR, NSIS may > consider it. I don't see how _signaling_ for QoS establishment > beyond AR is relevant for seamoby. > > CAR _discovery_ could exchange QoS capability as one of the > parameters that might then be fed to a selection algorithm. Any > signaling for actually establishing QoS itself beyond the AR > should be outside the scope of seamoby.. > > Regards, > > -Rajeev > > > Gary Kenward wrote: > > > > > > > Hemant: > > > > Just a point of clarification, but as I understand CARD (and > > I don't understand it well), it is not a QoS negotiation > > protocol. The main application that you are referring to primarily > > arises out of a perceived need to determine at the MN the best link > > layer to handover over to when inter-technology handovers are > > involved. > > It can be applied to intra-technology handovers, but the value in > > that situation is highly questionable (e.g. since it is a discovery > > protocol, the implication is that the purpose is to determine the > > choice of channels available; for intra-technology handovers, there > > are many, many reasons why this "choice" may not be available). > > > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > > > during/after a handover. John has stated that this is not the > > intention > > (please correct me if I have this wrong John), in which case I think > > 5.1.2 needs to be clarified. > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > existing flow after a handover, or is it specifically for establishing > > > > QoS for a new flow? I don't think the answer is boolean: the role > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > handover is a dynamic situation that could cause the QoS provided to > > change. > > > > I have been told there is no issue, but here's a frightening > > scenario: > > > > - a handover takes place, and context transfer has been used > > to > > move the QoS context to the new routers (by the requirements > > for > > CT this could be intra-, or inter- technology. Some of us > > believe > > that for "seamless" handovers, the context will be available at > > > > routers before the first packets need to be forwarded. This > > implies > > that there is a relationship, probabilistic perhaps, between > > the handover process and the target ARs for CT. > > > > - CARD is used by the MN to influence the handover decision (it > > is not clear to me how this happens, but it seems clear that > > for a more "seamless" handover, the MN should chose an AR that > > has received the appropriate context; if not, then what? > > > > - NSIS kicks in and starts re-negotiating QoS because of changes > > introduced by the handover; > > > > How do these three protocols interact to produce predictable > > outcomes? > > Or, perhaps, the question is, how do the functional entities > > associated > > with the three protocols interact before, during and after a handover? > > > > If it the interaction is within the functional entities, the > > respective > > wg's could declare the issue out of scope, but this approach does not > > sit well with me, for it seems to defer the problem to the people who > > have to implement this "stuff". > > > > Am I imagining things? > > > > Cheers, > > Gary > > > > > -----Original Message----- > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > Sent: April 4, 2002 22:33 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Hi Sharif: > > > > > > There is currently a debate going on in Seamoby as to whether > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > discovery protocol). > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > discovery is supposed to identify candidate access routers > > > for handoff and QoS is an important property for candidacy. > > > > > > Br, > > > Hemant > > > > > > -----Original Message----- > > > From: ext Shahrier, Sharif M. > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > Sent: Thursday, April 04, 2002 3:35 PM > > > To: Shahrier, Sharif M. > > > Cc: 'nsis@ietf.org' > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > I have a question for clarification. > > > > > > I think it was stated that NSIS should only be concerned with the > > > establishment of QoS after handoff. > > > > > > This is inconvienent with respect to IP-level QoS > > > negotiation, which ideally > > > should be done before handoff has taken place. > > > > > > QoS negotiation is in the current requirements draft. > > > > > > So, NSIS signaling protocol development should be concerned > > > with activity > > > before handoff occurs. > > > > > > Sharif. > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 5 12:32: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 MAA10958 for ; Fri, 5 Apr 2002 12:32: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 MAA15470; Fri, 5 Apr 2002 12: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 MAA15401 for ; Fri, 5 Apr 2002 12:19: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 MAA10611; Fri, 5 Apr 2002 12:19:49 -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 JAA09381; Fri, 5 Apr 2002 09:19:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35HJLj07698; Fri, 5 Apr 2002 09:19:21 -0800 X-mProtect: <200204051719> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlaMFPH; Fri, 05 Apr 2002 09:19:19 PST Message-ID: <3CADDC97.70EFE709@iprg.nokia.com> Date: Fri, 05 Apr 2002 09:19:20 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$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, James Kempf wrote: > There is an issue if CT fails. In that case, some kind of negotiation > after handover would be required. > > So, I'd say that some indication of CT failure is needed. > Yes, but this is between AR and MN. If CT fails, the AR should notify the MN to engage in context re-creation. My point was specific to signaling _beyond_ AR (i.e., upstream signaling) independent of failure/success of CT. Hope this is clearer.. -Rajeev > > As for CAR, I don't see the relevance for QoS negotiation, though it may > be useful for finding a new wireless medium. I also see it primarily for > intertechnology handover, or, at best, interprovider handover. > > jak > ----- Original Message ----- > From: "Rajeev Koodli" > To: "Gary Kenward" > Cc: ; ; > Sent: Friday, April 05, 2002 9:01 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > > handover is a dynamic situation that could cause the QoS provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer has been used > > > to > > > move the QoS context to the new routers (by the requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be available > at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover decision (it > > > is not clear to me how this happens, but it seems clear that > > > for a more "seamless" handover, the MN should chose an AR > that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and after a > handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this approach does > not > > > sit well with me, for it seems to defer the problem to the people > who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > Seamoby mailing 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 Apr 5 12:32: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 MAA10974 for ; Fri, 5 Apr 2002 12:32:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16542 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 12:32: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 MAA15470; Fri, 5 Apr 2002 12: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 MAA15401 for ; Fri, 5 Apr 2002 12:19: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 MAA10611; Fri, 5 Apr 2002 12:19:49 -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 JAA09381; Fri, 5 Apr 2002 09:19:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35HJLj07698; Fri, 5 Apr 2002 09:19:21 -0800 X-mProtect: <200204051719> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlaMFPH; Fri, 05 Apr 2002 09:19:19 PST Message-ID: <3CADDC97.70EFE709@iprg.nokia.com> Date: Fri, 05 Apr 2002 09:19:20 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$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, James Kempf wrote: > There is an issue if CT fails. In that case, some kind of negotiation > after handover would be required. > > So, I'd say that some indication of CT failure is needed. > Yes, but this is between AR and MN. If CT fails, the AR should notify the MN to engage in context re-creation. My point was specific to signaling _beyond_ AR (i.e., upstream signaling) independent of failure/success of CT. Hope this is clearer.. -Rajeev > > As for CAR, I don't see the relevance for QoS negotiation, though it may > be useful for finding a new wireless medium. I also see it primarily for > intertechnology handover, or, at best, interprovider handover. > > jak > ----- Original Message ----- > From: "Rajeev Koodli" > To: "Gary Kenward" > Cc: ; ; > Sent: Friday, April 05, 2002 9:01 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > > handover is a dynamic situation that could cause the QoS provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer has been used > > > to > > > move the QoS context to the new routers (by the requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be available > at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover decision (it > > > is not clear to me how this happens, but it seems clear that > > > for a more "seamless" handover, the MN should chose an AR > that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and after a > handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this approach does > not > > > sit well with me, for it seems to defer the problem to the people > who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > Seamoby mailing 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 Apr 5 12:42: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 MAA11263 for ; Fri, 5 Apr 2002 12:42: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 MAA16170; Fri, 5 Apr 2002 12:30: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 MAA16049 for ; Fri, 5 Apr 2002 12:30:19 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10907; Fri, 5 Apr 2002 12:30:12 -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 g35HPHe02097; Fri, 5 Apr 2002 12:25:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 12:25:17 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49CE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 12:25:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCC6.D6D9082C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCC6.D6D9082C Content-Type: text/plain; charset="iso-8859-1" Rajeev, James: This is how I see it also. I think that some work is required to identify the conditions under which each protocol is invoked. E.g. NSIS is not invoked with every handover, but is certainly there to be invoked if CT fails, or if there is a QoS disruption for whatever reason. Thanks. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 12:07 > To: Rajeev Koodli; Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > There is an issue if CT fails. In that case, some kind of negotiation > after handover would be required. > > So, I'd say that some indication of CT failure is needed. > > As for CAR, I don't see the relevance for QoS negotiation, > though it may > be useful for finding a new wireless medium. I also see it > primarily for > intertechnology handover, or, at best, interprovider handover. > > jak > ----- Original Message ----- > From: "Rajeev Koodli" > To: "Gary Kenward" > Cc: ; ; > Sent: Friday, April 05, 2002 9:01 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the > best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a > discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology > handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which > case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, > and clearly > > > handover is a dynamic situation that could cause the QoS > provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer > has been used > > > to > > > move the QoS context to the new routers (by the > requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be > available > at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic > perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover > decision (it > > > is not clear to me how this happens, but it seems > clear that > > > for a more "seamless" handover, the MN should chose an AR > that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and after a > handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this approach does > not > > > sit well with me, for it seems to defer the problem to the people > who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be > concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C1DCC6.D6D9082C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev, James:

  This is how I see it also. I think that some work
is required to identify the conditions under which each
protocol is invoked. E.g. NSIS is not invoked with every
handover, but is certainly there to be invoked if CT
fails, or if there is a QoS disruption for whatever reason.

Thanks.
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 12:07
> To: Rajeev Koodli; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> There is an issue if CT fails. In that case, some kind of negotiation
> after handover would be required.
>
> So, I'd say that some indication of CT failure is needed.
>
> As for CAR, I don't see the relevance for QoS negotiation,
> though it may
> be useful for finding a new wireless medium. I also see it
> primarily for
> intertechnology handover, or, at best, interprovider handover.
>
>             jak
> ----- Original Message -----
> From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> To: "Gary Kenward" <gkenward@nortelnetworks.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Friday, April 05, 2002 9:01 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> >
> > Hello,
> >
> > well, if the issue is QoS establishment after handover,
> >
> > - CT is applicable for establishing QoS state at the AR
> > - if further signaling is desired beyond the AR, NSIS may
> >     consider it. I don't see how _signaling_ for QoS establishment
> >     beyond AR is relevant for seamoby.
> >
> > CAR _discovery_ could exchange QoS capability as one of the
> > parameters that might then be fed to a selection algorithm. Any
> > signaling for actually establishing QoS itself beyond the AR
> > should be outside the scope of seamoby..
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> > Gary Kenward wrote:
> >
> > >
> > >
> > > Hemant:
> > >
> > >   Just a point of clarification, but as I understand CARD (and
> > > I don't understand it well), it is not a QoS negotiation
> > > protocol. The main application that you are referring to primarily
> > > arises out of a perceived need to determine at the MN the
> best link
> > > layer to handover over to when inter-technology handovers are
> > > involved.
> > > It can be applied to intra-technology handovers, but the value in
> > > that situation is highly questionable (e.g. since it is a
> discovery
> > > protocol, the implication is that the purpose is to determine the
> > > choice of channels available; for intra-technology
> handovers, there
> > > are many, many reasons why this "choice" may not be available).
> > >
> > >   There is a requirement, 5.1.2, which seems to imply NSIS
> involvement
> > >
> > > during/after a handover. John has stated that this is not the
> > > intention
> > > (please correct me if I have this wrong John), in which
> case I think
> > > 5.1.2 needs to be clarified.
> > >
> > >   Specifically, is NSIS to be used to negotiated new QoS for an
> > > existing flow after a handover, or is it specifically for
> establishing
> > >
> > > QoS for a new flow? I don't think the answer is boolean: the role
> > > of NSIS in QoS re-negotiation is still open, I believe,
> and clearly
> > > handover is a dynamic situation that could cause the QoS
> provided to
> > > change.
> > >
> > >   I have been told there is no issue, but here's a frightening
> > > scenario:
> > >
> > >         - a handover takes place, and context transfer
> has been used
> > > to
> > >        move the QoS context to the new routers (by the
> requirements
> > > for
> > >        CT this could be intra-, or inter- technology. Some of us
> > > believe
> > >        that for "seamless" handovers, the context will be
> available
> at
> > >
> > >        routers before the first packets need to be forwarded. This
> > > implies
> > >        that there is a relationship, probabilistic
> perhaps, between
> > >        the handover process and the target ARs for CT.
> > >
> > >      - CARD is used by the MN to influence the handover
> decision (it
> > >        is not clear to me how this happens, but it seems
> clear that
> > >        for a more "seamless" handover, the MN should chose an AR
> that
> > >        has received the appropriate context; if not, then what?
> > >
> > >      - NSIS kicks in and starts re-negotiating QoS because of
> changes
> > >        introduced by the handover;
> > >
> > >   How do these three protocols interact to produce predictable
> > > outcomes?
> > > Or, perhaps, the question is, how do the functional entities
> > > associated
> > > with the three protocols interact before, during and after a
> handover?
> > >
> > > If it the interaction is within the functional entities, the
> > > respective
> > > wg's could declare the issue out of scope, but this approach does
> not
> > > sit well with me, for it seems to defer the problem to the people
> who
> > > have to implement this "stuff".
> > >
> > >   Am I imagining things?
> > >
> > > Cheers,
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> > > > Sent: April 4, 2002 22:33
> > > > To: nsis@ietf.org
> > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > > Hi Sharif:
> > > >
> > > > There is currently a debate going on in Seamoby as to whether
> > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > discovery protocol).
> > > >
> > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > discovery is supposed to identify candidate access routers
> > > > for handoff and QoS is an important property for candidacy.
> > > >
> > > > Br,
> > > > Hemant
> > > >
> > > > -----Original Message-----
> > > > From: ext Shahrier, Sharif M.
> > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > To: Shahrier, Sharif M.
> > > > Cc: 'nsis@ietf.org'
> > > > Subject: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > >
> > > > I have a question for clarification.
> > > >
> > > > I think it was stated that NSIS should only be
> concerned with the
> > > > establishment of QoS after handoff.
> > > >
> > > > This is inconvienent with respect to IP-level QoS
> > > > negotiation, which ideally
> > > > should be done before handoff has taken place.
> > > >
> > > > QoS negotiation is in the current requirements draft.
> > > >
> > > > So, NSIS signaling protocol development should be concerned
> > > > with activity
> > > > before handoff occurs.
> > > >
> > > > Sharif.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C1DCC6.D6D9082C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 12:42: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 MAA11282 for ; Fri, 5 Apr 2002 12:42:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17066 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 12:42: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 MAA16170; Fri, 5 Apr 2002 12:30: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 MAA16049 for ; Fri, 5 Apr 2002 12:30:19 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10907; Fri, 5 Apr 2002 12:30:12 -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 g35HPHe02097; Fri, 5 Apr 2002 12:25:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 12:25:17 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49CE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 12:25:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCC6.D6D9082C" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCC6.D6D9082C Content-Type: text/plain; charset="iso-8859-1" Rajeev, James: This is how I see it also. I think that some work is required to identify the conditions under which each protocol is invoked. E.g. NSIS is not invoked with every handover, but is certainly there to be invoked if CT fails, or if there is a QoS disruption for whatever reason. Thanks. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 12:07 > To: Rajeev Koodli; Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > There is an issue if CT fails. In that case, some kind of negotiation > after handover would be required. > > So, I'd say that some indication of CT failure is needed. > > As for CAR, I don't see the relevance for QoS negotiation, > though it may > be useful for finding a new wireless medium. I also see it > primarily for > intertechnology handover, or, at best, interprovider handover. > > jak > ----- Original Message ----- > From: "Rajeev Koodli" > To: "Gary Kenward" > Cc: ; ; > Sent: Friday, April 05, 2002 9:01 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the > best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a > discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology > handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which > case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, > and clearly > > > handover is a dynamic situation that could cause the QoS > provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer > has been used > > > to > > > move the QoS context to the new routers (by the > requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be > available > at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic > perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover > decision (it > > > is not clear to me how this happens, but it seems > clear that > > > for a more "seamless" handover, the MN should chose an AR > that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and after a > handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this approach does > not > > > sit well with me, for it seems to defer the problem to the people > who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be > concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C1DCC6.D6D9082C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev, James:

  This is how I see it also. I think that some work
is required to identify the conditions under which each
protocol is invoked. E.g. NSIS is not invoked with every
handover, but is certainly there to be invoked if CT
fails, or if there is a QoS disruption for whatever reason.

Thanks.
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 12:07
> To: Rajeev Koodli; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> There is an issue if CT fails. In that case, some kind of negotiation
> after handover would be required.
>
> So, I'd say that some indication of CT failure is needed.
>
> As for CAR, I don't see the relevance for QoS negotiation,
> though it may
> be useful for finding a new wireless medium. I also see it
> primarily for
> intertechnology handover, or, at best, interprovider handover.
>
>             jak
> ----- Original Message -----
> From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> To: "Gary Kenward" <gkenward@nortelnetworks.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Friday, April 05, 2002 9:01 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> >
> > Hello,
> >
> > well, if the issue is QoS establishment after handover,
> >
> > - CT is applicable for establishing QoS state at the AR
> > - if further signaling is desired beyond the AR, NSIS may
> >     consider it. I don't see how _signaling_ for QoS establishment
> >     beyond AR is relevant for seamoby.
> >
> > CAR _discovery_ could exchange QoS capability as one of the
> > parameters that might then be fed to a selection algorithm. Any
> > signaling for actually establishing QoS itself beyond the AR
> > should be outside the scope of seamoby..
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> > Gary Kenward wrote:
> >
> > >
> > >
> > > Hemant:
> > >
> > >   Just a point of clarification, but as I understand CARD (and
> > > I don't understand it well), it is not a QoS negotiation
> > > protocol. The main application that you are referring to primarily
> > > arises out of a perceived need to determine at the MN the
> best link
> > > layer to handover over to when inter-technology handovers are
> > > involved.
> > > It can be applied to intra-technology handovers, but the value in
> > > that situation is highly questionable (e.g. since it is a
> discovery
> > > protocol, the implication is that the purpose is to determine the
> > > choice of channels available; for intra-technology
> handovers, there
> > > are many, many reasons why this "choice" may not be available).
> > >
> > >   There is a requirement, 5.1.2, which seems to imply NSIS
> involvement
> > >
> > > during/after a handover. John has stated that this is not the
> > > intention
> > > (please correct me if I have this wrong John), in which
> case I think
> > > 5.1.2 needs to be clarified.
> > >
> > >   Specifically, is NSIS to be used to negotiated new QoS for an
> > > existing flow after a handover, or is it specifically for
> establishing
> > >
> > > QoS for a new flow? I don't think the answer is boolean: the role
> > > of NSIS in QoS re-negotiation is still open, I believe,
> and clearly
> > > handover is a dynamic situation that could cause the QoS
> provided to
> > > change.
> > >
> > >   I have been told there is no issue, but here's a frightening
> > > scenario:
> > >
> > >         - a handover takes place, and context transfer
> has been used
> > > to
> > >        move the QoS context to the new routers (by the
> requirements
> > > for
> > >        CT this could be intra-, or inter- technology. Some of us
> > > believe
> > >        that for "seamless" handovers, the context will be
> available
> at
> > >
> > >        routers before the first packets need to be forwarded. This
> > > implies
> > >        that there is a relationship, probabilistic
> perhaps, between
> > >        the handover process and the target ARs for CT.
> > >
> > >      - CARD is used by the MN to influence the handover
> decision (it
> > >        is not clear to me how this happens, but it seems
> clear that
> > >        for a more "seamless" handover, the MN should chose an AR
> that
> > >        has received the appropriate context; if not, then what?
> > >
> > >      - NSIS kicks in and starts re-negotiating QoS because of
> changes
> > >        introduced by the handover;
> > >
> > >   How do these three protocols interact to produce predictable
> > > outcomes?
> > > Or, perhaps, the question is, how do the functional entities
> > > associated
> > > with the three protocols interact before, during and after a
> handover?
> > >
> > > If it the interaction is within the functional entities, the
> > > respective
> > > wg's could declare the issue out of scope, but this approach does
> not
> > > sit well with me, for it seems to defer the problem to the people
> who
> > > have to implement this "stuff".
> > >
> > >   Am I imagining things?
> > >
> > > Cheers,
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> > > > Sent: April 4, 2002 22:33
> > > > To: nsis@ietf.org
> > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > > Hi Sharif:
> > > >
> > > > There is currently a debate going on in Seamoby as to whether
> > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > discovery protocol).
> > > >
> > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > discovery is supposed to identify candidate access routers
> > > > for handoff and QoS is an important property for candidacy.
> > > >
> > > > Br,
> > > > Hemant
> > > >
> > > > -----Original Message-----
> > > > From: ext Shahrier, Sharif M.
> > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > To: Shahrier, Sharif M.
> > > > Cc: 'nsis@ietf.org'
> > > > Subject: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > >
> > > > I have a question for clarification.
> > > >
> > > > I think it was stated that NSIS should only be
> concerned with the
> > > > establishment of QoS after handoff.
> > > >
> > > > This is inconvienent with respect to IP-level QoS
> > > > negotiation, which ideally
> > > > should be done before handoff has taken place.
> > > >
> > > > QoS negotiation is in the current requirements draft.
> > > >
> > > > So, NSIS signaling protocol development should be concerned
> > > > with activity
> > > > before handoff occurs.
> > > >
> > > > Sharif.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C1DCC6.D6D9082C-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 12:57: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 MAA11613 for ; Fri, 5 Apr 2002 12:57: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 MAA16986; Fri, 5 Apr 2002 12:41: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 MAA16900 for ; Fri, 5 Apr 2002 12:41: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 MAA11248; Fri, 5 Apr 2002 12:41: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 g35HenI01102; Fri, 5 Apr 2002 09:40:49 -0800 (PST) Message-ID: <016801c1dcc8$ccdadd30$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 09:39: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 Rajeev, I agree, but there is still an issue of how the AR would notify the MN if CT fails. Is this covered by CT or not? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 9:19 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello Jim, > > James Kempf wrote: > > > There is an issue if CT fails. In that case, some kind of negotiation > > after handover would be required. > > > > So, I'd say that some indication of CT failure is needed. > > > > Yes, but this is between AR and MN. If CT fails, the AR should > notify the MN to engage in context re-creation. > > My point was specific to signaling _beyond_ AR (i.e., upstream signaling) > independent of failure/success of CT. > > Hope this is clearer.. > > -Rajeev > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it may > > be useful for finding a new wireless medium. I also see it primarily for > > intertechnology handover, or, at best, interprovider handover. > > > > jak > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "Gary Kenward" > > Cc: ; ; > > Sent: Friday, April 05, 2002 9:01 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > > > handover is a dynamic situation that could cause the QoS provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer has been used > > > > to > > > > move the QoS context to the new routers (by the requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be available > > at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover decision (it > > > > is not clear to me how this happens, but it seems clear that > > > > for a more "seamless" handover, the MN should chose an AR > > that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and after a > > handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this approach does > > not > > > > sit well with me, for it seems to defer the problem to the people > > who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Apr 5 12:57: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 MAA11623 for ; Fri, 5 Apr 2002 12:57:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17519 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 12:58: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 MAA16986; Fri, 5 Apr 2002 12:41: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 MAA16900 for ; Fri, 5 Apr 2002 12:41: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 MAA11248; Fri, 5 Apr 2002 12:41: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 g35HenI01102; Fri, 5 Apr 2002 09:40:49 -0800 (PST) Message-ID: <016801c1dcc8$ccdadd30$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 09:39: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 Rajeev, I agree, but there is still an issue of how the AR would notify the MN if CT fails. Is this covered by CT or not? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 9:19 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello Jim, > > James Kempf wrote: > > > There is an issue if CT fails. In that case, some kind of negotiation > > after handover would be required. > > > > So, I'd say that some indication of CT failure is needed. > > > > Yes, but this is between AR and MN. If CT fails, the AR should > notify the MN to engage in context re-creation. > > My point was specific to signaling _beyond_ AR (i.e., upstream signaling) > independent of failure/success of CT. > > Hope this is clearer.. > > -Rajeev > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it may > > be useful for finding a new wireless medium. I also see it primarily for > > intertechnology handover, or, at best, interprovider handover. > > > > jak > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "Gary Kenward" > > Cc: ; ; > > Sent: Friday, April 05, 2002 9:01 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > > > handover is a dynamic situation that could cause the QoS provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer has been used > > > > to > > > > move the QoS context to the new routers (by the requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be available > > at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover decision (it > > > > is not clear to me how this happens, but it seems clear that > > > > for a more "seamless" handover, the MN should chose an AR > > that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and after a > > handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this approach does > > not > > > > sit well with me, for it seems to defer the problem to the people > > who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Apr 5 13:12: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 NAA11867 for ; Fri, 5 Apr 2002 13:12: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 NAA18345; Fri, 5 Apr 2002 13:03: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 NAA18278 for ; Fri, 5 Apr 2002 13:03:29 -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 NAA11760; Fri, 5 Apr 2002 13:03:26 -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 KAA11513; Fri, 5 Apr 2002 10:02:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35I2t827551; Fri, 5 Apr 2002 10:02:55 -0800 X-mProtect: <200204051802> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxeowcx; Fri, 05 Apr 2002 10:02:54 PST Message-ID: <3CADE6CE.DD37DEDB@iprg.nokia.com> Date: Fri, 05 Apr 2002 10:02:54 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> <016801c1dcc8$ccdadd30$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 James Kempf wrote: > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > This notification should be covered by CT. We should offer seamless handover to NSIS :-) Seriously, this concerns robustness of CT protocol. -Rajeev > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > may > > > be useful for finding a new wireless medium. I also see it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should chose an AR > > > that > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing 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 Apr 5 13:12: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 NAA11876 for ; Fri, 5 Apr 2002 13:12:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18857 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 13:12: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 NAA18345; Fri, 5 Apr 2002 13:03: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 NAA18278 for ; Fri, 5 Apr 2002 13:03:29 -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 NAA11760; Fri, 5 Apr 2002 13:03:26 -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 KAA11513; Fri, 5 Apr 2002 10:02:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35I2t827551; Fri, 5 Apr 2002 10:02:55 -0800 X-mProtect: <200204051802> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxeowcx; Fri, 05 Apr 2002 10:02:54 PST Message-ID: <3CADE6CE.DD37DEDB@iprg.nokia.com> Date: Fri, 05 Apr 2002 10:02:54 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> <016801c1dcc8$ccdadd30$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 James Kempf wrote: > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > This notification should be covered by CT. We should offer seamless handover to NSIS :-) Seriously, this concerns robustness of CT protocol. -Rajeev > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > may > > > be useful for finding a new wireless medium. I also see it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should chose an AR > > > that > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing 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 Apr 5 13: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 NAA12070 for ; Fri, 5 Apr 2002 13: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 NAA18738; Fri, 5 Apr 2002 13:09: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 NAA18578 for ; Fri, 5 Apr 2002 13:09:08 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11826; Fri, 5 Apr 2002 13:09:04 -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 g35I8He04951; Fri, 5 Apr 2002 13:08:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 13:08:16 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49D0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 13:08:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCCC.DAFE9AC4" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCCC.DAFE9AC4 Content-Type: text/plain; charset="iso-8859-1" Well, as far as I see it, if CT fails it is due to one of three reasons: - the "network" is not aware that a handover to that AR is taking place (and the AR is forced to deal with the situation locally). - the context is not useable by the AR. - the AR cannot admit the flows. CT does not address the first two of these issues. The first is a handover issue; CT allows for the AR to attempt to fetch context (aka "reactive CT"), however, it is possible that the AR may choose to signal the MN rather then attempt to acquire old context). The second issues would seem to be a CARD issue (albeit, a network centric CARD issue). The third reason is, in my view, also a handover issue. The handover algorithm cannot handover flows to ARs that have no free resources. There are issues here resource reservation versus over-booking and timing. Is CARD an admission control protocol? Does it request resource reservation, or is it timely enough to assure that the resource availability does not change before the handover actually occurs? Regards, Gary PS I cross-posted the first email because the issue seemed to be relevant to both groups. If this is untrue, I will endeavour to take the issue to only one of the two lists. > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 12:39 > To: Rajeev Koodli > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS > negotiation, though it > may > > > be useful for finding a new wireless medium. I also see > it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context > transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the > handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should > chose an AR > > > that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > ------_=_NextPart_001_01C1DCCC.DAFE9AC4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Well, as far as I see it, if CT fails it is due to one of three reasons:
 
 - the "network" is not aware that a handover to that AR is taking place
   (and the AR is forced to deal with the situation locally).

 - the context is not useable by the AR.

 - the AR cannot admit the flows.

CT does not address the first two of these issues. The first is a handover
issue; CT allows for the AR to attempt to fetch context (aka "reactive CT"),
however, it is possible that the AR may choose to signal the MN rather then
attempt to acquire old context). The second issues would seem to be a CARD
issue (albeit, a network centric CARD issue).

The third reason is, in my view, also a handover issue. The handover algorithm
cannot handover flows to ARs that have no free resources. There are issues
here resource reservation versus over-booking and timing. Is CARD an admission
control protocol? Does it request resource reservation, or is it timely enough
to assure that the resource availability does not change before the handover
actually occurs?

Regards,
Gary

PS I cross-posted the first email because the issue seemed to be relevant to
both groups. If this is untrue, I will endeavour to take the issue to only
one of the two lists.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 12:39
> To: Rajeev Koodli
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Rajeev,
>
> I agree, but there is still an issue of how the AR would notify the MN
> if CT fails. Is this covered by CT or not?
>
>             jak
>
> ----- Original Message -----
> From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> To: "James Kempf" <kempf@docomolabs-usa.com>
> Cc: "Gary Kenward" <gkenward@nortelnetworks.com>;
> <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Friday, April 05, 2002 9:19 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> >
> > Hello Jim,
> >
> > James Kempf wrote:
> >
> > > There is an issue if CT fails. In that case, some kind of
> negotiation
> > > after handover would be required.
> > >
> > > So, I'd say that some indication of CT failure is needed.
> > >
> >
> > Yes, but this is between AR and MN. If CT fails, the AR should
> > notify the MN to engage in context re-creation.
> >
> > My point was specific to signaling _beyond_ AR (i.e., upstream
> signaling)
> > independent of failure/success of CT.
> >
> > Hope this is clearer..
> >
> > -Rajeev
> >
> >
> > >
> > > As for CAR, I don't see the relevance for QoS
> negotiation, though it
> may
> > > be useful for finding a new wireless medium. I also see
> it primarily
> for
> > > intertechnology handover, or, at best, interprovider handover.
> > >
> > >             jak
> > > ----- Original Message -----
> > > From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> > > To: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>;
> <seamoby@ietf.org>
> > > Sent: Friday, April 05, 2002 9:01 AM
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> primarily
> > > > > arises out of a perceived need to determine at the MN the best
> link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> in
> > > > > that situation is highly questionable (e.g. since it is a
> discovery
> > > > > protocol, the implication is that the purpose is to determine
> the
> > > > > choice of channels available; for intra-technology handovers,
> there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply NSIS
> > > involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which case I
> think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> role
> > > > > of NSIS in QoS re-negotiation is still open, I believe, and
> clearly
> > > > > handover is a dynamic situation that could cause the QoS
> provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context
> transfer has been
> used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> available
> > > at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> This
> > > > > implies
> > > > >        that there is a relationship, probabilistic perhaps,
> between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the
> handover decision
> (it
> > > > >        is not clear to me how this happens, but it seems clear
> that
> > > > >        for a more "seamless" handover, the MN should
> chose an AR
> > > that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS because of
> > > changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and after a
> > > handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this approach
> does
> > > not
> > > > > sit well with me, for it seems to defer the problem to the
> people
> > > who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> concerned with
> the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>

------_=_NextPart_001_01C1DCCC.DAFE9AC4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 13:18: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 NAA12083 for ; Fri, 5 Apr 2002 13:18:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19258 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 13:18: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 NAA18738; Fri, 5 Apr 2002 13:09: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 NAA18578 for ; Fri, 5 Apr 2002 13:09:08 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11826; Fri, 5 Apr 2002 13:09:04 -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 g35I8He04951; Fri, 5 Apr 2002 13:08:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 13:08:16 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49D0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 13:08:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCCC.DAFE9AC4" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCCC.DAFE9AC4 Content-Type: text/plain; charset="iso-8859-1" Well, as far as I see it, if CT fails it is due to one of three reasons: - the "network" is not aware that a handover to that AR is taking place (and the AR is forced to deal with the situation locally). - the context is not useable by the AR. - the AR cannot admit the flows. CT does not address the first two of these issues. The first is a handover issue; CT allows for the AR to attempt to fetch context (aka "reactive CT"), however, it is possible that the AR may choose to signal the MN rather then attempt to acquire old context). The second issues would seem to be a CARD issue (albeit, a network centric CARD issue). The third reason is, in my view, also a handover issue. The handover algorithm cannot handover flows to ARs that have no free resources. There are issues here resource reservation versus over-booking and timing. Is CARD an admission control protocol? Does it request resource reservation, or is it timely enough to assure that the resource availability does not change before the handover actually occurs? Regards, Gary PS I cross-posted the first email because the issue seemed to be relevant to both groups. If this is untrue, I will endeavour to take the issue to only one of the two lists. > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 12:39 > To: Rajeev Koodli > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS > negotiation, though it > may > > > be useful for finding a new wireless medium. I also see > it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context > transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the > handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should > chose an AR > > > that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > ------_=_NextPart_001_01C1DCCC.DAFE9AC4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Well, as far as I see it, if CT fails it is due to one of three reasons:
 
 - the "network" is not aware that a handover to that AR is taking place
   (and the AR is forced to deal with the situation locally).

 - the context is not useable by the AR.

 - the AR cannot admit the flows.

CT does not address the first two of these issues. The first is a handover
issue; CT allows for the AR to attempt to fetch context (aka "reactive CT"),
however, it is possible that the AR may choose to signal the MN rather then
attempt to acquire old context). The second issues would seem to be a CARD
issue (albeit, a network centric CARD issue).

The third reason is, in my view, also a handover issue. The handover algorithm
cannot handover flows to ARs that have no free resources. There are issues
here resource reservation versus over-booking and timing. Is CARD an admission
control protocol? Does it request resource reservation, or is it timely enough
to assure that the resource availability does not change before the handover
actually occurs?

Regards,
Gary

PS I cross-posted the first email because the issue seemed to be relevant to
both groups. If this is untrue, I will endeavour to take the issue to only
one of the two lists.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 12:39
> To: Rajeev Koodli
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Rajeev,
>
> I agree, but there is still an issue of how the AR would notify the MN
> if CT fails. Is this covered by CT or not?
>
>             jak
>
> ----- Original Message -----
> From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> To: "James Kempf" <kempf@docomolabs-usa.com>
> Cc: "Gary Kenward" <gkenward@nortelnetworks.com>;
> <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Friday, April 05, 2002 9:19 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> >
> > Hello Jim,
> >
> > James Kempf wrote:
> >
> > > There is an issue if CT fails. In that case, some kind of
> negotiation
> > > after handover would be required.
> > >
> > > So, I'd say that some indication of CT failure is needed.
> > >
> >
> > Yes, but this is between AR and MN. If CT fails, the AR should
> > notify the MN to engage in context re-creation.
> >
> > My point was specific to signaling _beyond_ AR (i.e., upstream
> signaling)
> > independent of failure/success of CT.
> >
> > Hope this is clearer..
> >
> > -Rajeev
> >
> >
> > >
> > > As for CAR, I don't see the relevance for QoS
> negotiation, though it
> may
> > > be useful for finding a new wireless medium. I also see
> it primarily
> for
> > > intertechnology handover, or, at best, interprovider handover.
> > >
> > >             jak
> > > ----- Original Message -----
> > > From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> > > To: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>;
> <seamoby@ietf.org>
> > > Sent: Friday, April 05, 2002 9:01 AM
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> primarily
> > > > > arises out of a perceived need to determine at the MN the best
> link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> in
> > > > > that situation is highly questionable (e.g. since it is a
> discovery
> > > > > protocol, the implication is that the purpose is to determine
> the
> > > > > choice of channels available; for intra-technology handovers,
> there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply NSIS
> > > involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which case I
> think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> role
> > > > > of NSIS in QoS re-negotiation is still open, I believe, and
> clearly
> > > > > handover is a dynamic situation that could cause the QoS
> provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context
> transfer has been
> used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> available
> > > at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> This
> > > > > implies
> > > > >        that there is a relationship, probabilistic perhaps,
> between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the
> handover decision
> (it
> > > > >        is not clear to me how this happens, but it seems clear
> that
> > > > >        for a more "seamless" handover, the MN should
> chose an AR
> > > that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS because of
> > > changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and after a
> > > handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this approach
> does
> > > not
> > > > > sit well with me, for it seems to defer the problem to the
> people
> > > who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> concerned with
> the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>

------_=_NextPart_001_01C1DCCC.DAFE9AC4-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 13:38: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 NAA12625 for ; Fri, 5 Apr 2002 13:38: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 NAA19569; Fri, 5 Apr 2002 13:24: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 NAA19508 for ; Fri, 5 Apr 2002 13:24: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 NAA12258; Fri, 5 Apr 2002 13:24: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 g35INZI02501; Fri, 5 Apr 2002 10:23:35 -0800 (PST) Message-ID: <01a501c1dcce$c6217660$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> <016801c1dcc8$ccdadd30$7e6015ac@T23KEMPF> <3CADE6CE.DD37DEDB@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 10:21: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 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Agree. But I don't see anything in the CT requirements about handling CT failure. ??? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 10:02 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the best > > link > > > > > > layer to handover over to when inter-technology handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > > choice of channels available; for intra-technology handovers, > > there > > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover decision > > (it > > > > > > is not clear to me how this happens, but it seems clear > > that > > > > > > for a more "seamless" handover, the MN should chose an AR > > > > that > > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 Fri Apr 5 13:38: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 NAA12635 for ; Fri, 5 Apr 2002 13:38:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20766 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 13:38: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 NAA19569; Fri, 5 Apr 2002 13:24: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 NAA19508 for ; Fri, 5 Apr 2002 13:24: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 NAA12258; Fri, 5 Apr 2002 13:24: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 g35INZI02501; Fri, 5 Apr 2002 10:23:35 -0800 (PST) Message-ID: <01a501c1dcce$c6217660$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> <016801c1dcc8$ccdadd30$7e6015ac@T23KEMPF> <3CADE6CE.DD37DEDB@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 10:21: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 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit Agree. But I don't see anything in the CT requirements about handling CT failure. ??? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 10:02 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the best > > link > > > > > > layer to handover over to when inter-technology handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > > choice of channels available; for intra-technology handovers, > > there > > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover decision > > (it > > > > > > is not clear to me how this happens, but it seems clear > > that > > > > > > for a more "seamless" handover, the MN should chose an AR > > > > that > > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 Fri Apr 5 13:48: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 NAA12993 for ; Fri, 5 Apr 2002 13:48: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 NAA20974; Fri, 5 Apr 2002 13:39: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 NAA20917 for ; Fri, 5 Apr 2002 13:39:39 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12671; Fri, 5 Apr 2002 13:39:35 -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 g35IZ4e06676; Fri, 5 Apr 2002 13:35:04 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 13:35:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49D3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 13:34:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCCF.3DBA5B2E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCCF.3DBA5B2E Content-Type: text/plain; charset="iso-8859-1" Well yes and no. First, CT is required to do everything it can to get the context across intact, as fast as possible, which, it was decided, meant that there was realistically only one opportunity to attempt to transfer the context. The emphasis was placed on requiring that a given transfer of context would not fail (e.g. the context integrity should be preserved through error control, etc.). Then, if the transfer failed it was because of something other then the transfer process itself. If CT fails, it is more likely then not that handover will not be seamless anyways, and there is nothing that CT can do, per se, to recover. Having said this, CT can be re-invoked by another entity, perhaps the handover control function, for recovery purposes. I'm trying to be brief, so I hope this captures what was a looooong discussion. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 13:22 > To: Rajeev Koodli > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > > > ------_=_NextPart_001_01C1DCCF.3DBA5B2E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Well yes and no.

First, CT is required to do everything it can to get the
context across intact, as fast as possible, which, it was decided, meant
that there was realistically only one opportunity to attempt to transfer
the context. The emphasis was placed on requiring that a given transfer of
context would not fail (e.g. the context integrity should be preserved through
error control, etc.). Then, if the transfer failed it was because of something
other then the transfer process itself.

If CT fails, it is more likely then not that handover will not be seamless
anyways, and there is nothing that CT can do, per se, to recover.
Having said this, CT can be re-invoked by another entity, perhaps the handover
control function, for recovery purposes.

I'm trying to be brief, so I hope this captures what was a looooong discussion.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 13:22
> To: Rajeev Koodli
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Agree.
>
> But I don't see anything in the CT requirements about handling CT
> failure.
>
> ???
>
>             jak
>
 >
>
>

------_=_NextPart_001_01C1DCCF.3DBA5B2E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 13:48: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 NAA13003 for ; Fri, 5 Apr 2002 13:48:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21458 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 13:48: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 NAA20974; Fri, 5 Apr 2002 13:39: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 NAA20917 for ; Fri, 5 Apr 2002 13:39:39 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12671; Fri, 5 Apr 2002 13:39:35 -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 g35IZ4e06676; Fri, 5 Apr 2002 13:35:04 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 13:35:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49D3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 13:34:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCCF.3DBA5B2E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DCCF.3DBA5B2E Content-Type: text/plain; charset="iso-8859-1" Well yes and no. First, CT is required to do everything it can to get the context across intact, as fast as possible, which, it was decided, meant that there was realistically only one opportunity to attempt to transfer the context. The emphasis was placed on requiring that a given transfer of context would not fail (e.g. the context integrity should be preserved through error control, etc.). Then, if the transfer failed it was because of something other then the transfer process itself. If CT fails, it is more likely then not that handover will not be seamless anyways, and there is nothing that CT can do, per se, to recover. Having said this, CT can be re-invoked by another entity, perhaps the handover control function, for recovery purposes. I'm trying to be brief, so I hope this captures what was a looooong discussion. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 13:22 > To: Rajeev Koodli > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > > > ------_=_NextPart_001_01C1DCCF.3DBA5B2E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Well yes and no.

First, CT is required to do everything it can to get the
context across intact, as fast as possible, which, it was decided, meant
that there was realistically only one opportunity to attempt to transfer
the context. The emphasis was placed on requiring that a given transfer of
context would not fail (e.g. the context integrity should be preserved through
error control, etc.). Then, if the transfer failed it was because of something
other then the transfer process itself.

If CT fails, it is more likely then not that handover will not be seamless
anyways, and there is nothing that CT can do, per se, to recover.
Having said this, CT can be re-invoked by another entity, perhaps the handover
control function, for recovery purposes.

I'm trying to be brief, so I hope this captures what was a looooong discussion.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 13:22
> To: Rajeev Koodli
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Agree.
>
> But I don't see anything in the CT requirements about handling CT
> failure.
>
> ???
>
>             jak
>
 >
>
>

------_=_NextPart_001_01C1DCCF.3DBA5B2E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 14:25: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 OAA14401 for ; Fri, 5 Apr 2002 14:25: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 OAA23107; Fri, 5 Apr 2002 14:13: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 OAA23041 for ; Fri, 5 Apr 2002 14:13:30 -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 OAA13848; Fri, 5 Apr 2002 14:13:25 -0500 (EST) From: Govind.Krishnamurthi@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 g35JG1H17282; Fri, 5 Apr 2002 13:16:01 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 13:13:27 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 13:12:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCD5.DF0B4838" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 14:12:47 -0500 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Thread-Index: AcHc09UCgOCOLnnTT+yWiX7chiBY4wAATuuQ To: , , Cc: , , X-OriginalArrivalTime: 05 Apr 2002 19:12:48.0390 (UTC) FILETIME=[DFCBBA60:01C1DCD5] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C1DCD5.DF0B4838 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gary, =20 The third reason is, in my view, also a handover issue. The handover = algorithm=20 cannot handover flows to ARs that have no free resources. There are = issues=20 here resource reservation versus over-booking and timing. Is CARD an = admission=20 control protocol? Does it request resource reservation, or is it timely = enough=20 to assure that the resource availability does not change before the = handover=20 actually occurs? =20 [Govind] IMHO, CARD can help an admission control protocol by giving = some relavant information about the AR.=20 But, I don't think it is an admission control protocol. Atleast I feel = this is true for CARD as it is described now. Best regards, Govind. =20 ------_=_NextPart_001_01C1DCD5.DF0B4838 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
Gary,
 

The third reason is, in my view, also a handover = issue. The=20 handover algorithm
cannot handover flows to = ARs that=20 have no free resources. There are issues
here resource=20 reservation versus over-booking and timing. Is CARD an = admission=20
control protocol? Does it request resource = reservation, or is=20 it timely enough
to assure that the resource = availability does not change before the handover
actually occurs?  

[Govind] IMHO, CARD can help an admission control = protocol by=20 giving some relavant information about the=20 AR. 

But,=20 I don't think it is an admission control protocol. Atleast I = feel this=20 is true for CARD as it is described now.

Best=20 regards,

Govind.

 

------_=_NextPart_001_01C1DCD5.DF0B4838-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 14:26: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 OAA14413 for ; Fri, 5 Apr 2002 14:25:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23555 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 14:26: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 OAA23107; Fri, 5 Apr 2002 14:13: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 OAA23041 for ; Fri, 5 Apr 2002 14:13:30 -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 OAA13848; Fri, 5 Apr 2002 14:13:25 -0500 (EST) From: Govind.Krishnamurthi@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 g35JG1H17282; Fri, 5 Apr 2002 13:16:01 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 13:13:27 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 13:12:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCD5.DF0B4838" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 14:12:47 -0500 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Thread-Index: AcHc09UCgOCOLnnTT+yWiX7chiBY4wAATuuQ To: , , Cc: , , X-OriginalArrivalTime: 05 Apr 2002 19:12:48.0390 (UTC) FILETIME=[DFCBBA60:01C1DCD5] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C1DCD5.DF0B4838 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gary, =20 The third reason is, in my view, also a handover issue. The handover = algorithm=20 cannot handover flows to ARs that have no free resources. There are = issues=20 here resource reservation versus over-booking and timing. Is CARD an = admission=20 control protocol? Does it request resource reservation, or is it timely = enough=20 to assure that the resource availability does not change before the = handover=20 actually occurs? =20 [Govind] IMHO, CARD can help an admission control protocol by giving = some relavant information about the AR.=20 But, I don't think it is an admission control protocol. Atleast I feel = this is true for CARD as it is described now. Best regards, Govind. =20 ------_=_NextPart_001_01C1DCD5.DF0B4838 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
Gary,
 

The third reason is, in my view, also a handover = issue. The=20 handover algorithm
cannot handover flows to = ARs that=20 have no free resources. There are issues
here resource=20 reservation versus over-booking and timing. Is CARD an = admission=20
control protocol? Does it request resource = reservation, or is=20 it timely enough
to assure that the resource = availability does not change before the handover
actually occurs?  

[Govind] IMHO, CARD can help an admission control = protocol by=20 giving some relavant information about the=20 AR. 

But,=20 I don't think it is an admission control protocol. Atleast I = feel this=20 is true for CARD as it is described now.

Best=20 regards,

Govind.

 

------_=_NextPart_001_01C1DCD5.DF0B4838-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 16:53: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 QAA19962 for ; Fri, 5 Apr 2002 16:53: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 QAA00717; Fri, 5 Apr 2002 16:44: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 QAA00653 for ; Fri, 5 Apr 2002 16:44:08 -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 QAA19751; Fri, 5 Apr 2002 16:44: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 NAA26077; Fri, 5 Apr 2002 13:43:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35LhXi03701; Fri, 5 Apr 2002 13:43:33 -0800 X-mProtect: <200204052143> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFKd5Lq; Fri, 05 Apr 2002 13:43:32 PST Message-ID: <3CAE1A84.5CFDB01D@iprg.nokia.com> Date: Fri, 05 Apr 2002 13:43:32 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'James Kempf'" , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49D3@zcard031.ca.nortel.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 Gary, CT is a protocol, and as such would have failure modes. For instance, transferred context is not useful at the target router. You could say that CARD should never let this happen. Does that mean that CT cannot be used where CARD is not available ? I hope not! In any case, I don't know of a protocol that does not have failure modes. We need a notification message in CT to inform when such a thing happens. Regards, -Rajeev Gary Kenward wrote: > > > Well yes and no. > > First, CT is required to do everything it can to get the > context across intact, as fast as possible, which, it was decided, > meant > that there was realistically only one opportunity to attempt to > transfer > the context. The emphasis was placed on requiring that a given > transfer of > context would not fail (e.g. the context integrity should be preserved > through > error control, etc.). Then, if the transfer failed it was because of > something > other then the transfer process itself. > > If CT fails, it is more likely then not that handover will not be > seamless > anyways, and there is nothing that CT can do, per se, to recover. > Having said this, CT can be re-invoked by another entity, perhaps the > handover > control function, for recovery purposes. > > I'm trying to be brief, so I hope this captures what was a looooong > discussion. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 5, 2002 13:22 > > To: Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 16:53: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 QAA19972 for ; Fri, 5 Apr 2002 16:53:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00934 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 16:53: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 QAA00717; Fri, 5 Apr 2002 16:44: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 QAA00653 for ; Fri, 5 Apr 2002 16:44:08 -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 QAA19751; Fri, 5 Apr 2002 16:44: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 NAA26077; Fri, 5 Apr 2002 13:43:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35LhXi03701; Fri, 5 Apr 2002 13:43:33 -0800 X-mProtect: <200204052143> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFKd5Lq; Fri, 05 Apr 2002 13:43:32 PST Message-ID: <3CAE1A84.5CFDB01D@iprg.nokia.com> Date: Fri, 05 Apr 2002 13:43:32 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'James Kempf'" , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49D3@zcard031.ca.nortel.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 Gary, CT is a protocol, and as such would have failure modes. For instance, transferred context is not useful at the target router. You could say that CARD should never let this happen. Does that mean that CT cannot be used where CARD is not available ? I hope not! In any case, I don't know of a protocol that does not have failure modes. We need a notification message in CT to inform when such a thing happens. Regards, -Rajeev Gary Kenward wrote: > > > Well yes and no. > > First, CT is required to do everything it can to get the > context across intact, as fast as possible, which, it was decided, > meant > that there was realistically only one opportunity to attempt to > transfer > the context. The emphasis was placed on requiring that a given > transfer of > context would not fail (e.g. the context integrity should be preserved > through > error control, etc.). Then, if the transfer failed it was because of > something > other then the transfer process itself. > > If CT fails, it is more likely then not that handover will not be > seamless > anyways, and there is nothing that CT can do, per se, to recover. > Having said this, CT can be re-invoked by another entity, perhaps the > handover > control function, for recovery purposes. > > I'm trying to be brief, so I hope this captures what was a looooong > discussion. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 5, 2002 13:22 > > To: Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 17:09: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 RAA00810 for ; Fri, 5 Apr 2002 17:09: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 RAA01955; Fri, 5 Apr 2002 17:00: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 RAA01891 for ; Fri, 5 Apr 2002 17:00:39 -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 RAA20384; Fri, 5 Apr 2002 17:00:33 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA08119; Fri, 5 Apr 2002 14:49:10 -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 PAA11013; Fri, 5 Apr 2002 15:00:36 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 16:00:36 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Rajeev Koodli Cc: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 16:00:32 -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, you are opening a can of worm that took seamoby 3 months to close without any results. People could not agree on the reliability needs of CT. We added a reliability mechanism to our CT proposal that covered both retransmission and updates. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, April 05, 2002 12:22 PM To: Rajeev Koodli Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Agree. But I don't see anything in the CT requirements about handling CT failure. ??? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 10:02 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the best > > link > > > > > > layer to handover over to when inter-technology handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > > choice of channels available; for intra-technology handovers, > > there > > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover decision > > (it > > > > > > is not clear to me how this happens, but it seems clear > > that > > > > > > for a more "seamless" handover, the MN should chose an AR > > > > that > > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 Fri Apr 5 17: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 RAA00874 for ; Fri, 5 Apr 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 QAA01426; Fri, 5 Apr 2002 16:58: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 QAA01309 for ; Fri, 5 Apr 2002 16:58:07 -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 QAA20192; Fri, 5 Apr 2002 16:58:02 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA26028; Fri, 5 Apr 2002 14:58:06 -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 OAA08156; Fri, 5 Apr 2002 14:58:06 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 15:58:06 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , James Kempf Cc: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 15:57:42 -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 Agreed. I don't think reliability in signaling, which by the way neither CT requirements, nor nsis requirements are covering, has to do with failure in QoS negotiation. I don't think you can count the case, where the QoS information that CT has given the AR is not applicable, as a CT failure. Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 12:03 PM To: James Kempf Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. James Kempf wrote: > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > This notification should be covered by CT. We should offer seamless handover to NSIS :-) Seriously, this concerns robustness of CT protocol. -Rajeev > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > may > > > be useful for finding a new wireless medium. I also see it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should chose an AR > > > that > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing 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 Fri Apr 5 17:09: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 RAA00890 for ; Fri, 5 Apr 2002 17:09:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02632 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 17: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 QAA01426; Fri, 5 Apr 2002 16:58: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 QAA01309 for ; Fri, 5 Apr 2002 16:58:07 -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 QAA20192; Fri, 5 Apr 2002 16:58:02 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA26028; Fri, 5 Apr 2002 14:58:06 -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 OAA08156; Fri, 5 Apr 2002 14:58:06 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 15:58:06 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , James Kempf Cc: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 15:57:42 -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 Agreed. I don't think reliability in signaling, which by the way neither CT requirements, nor nsis requirements are covering, has to do with failure in QoS negotiation. I don't think you can count the case, where the QoS information that CT has given the AR is not applicable, as a CT failure. Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 12:03 PM To: James Kempf Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. James Kempf wrote: > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > This notification should be covered by CT. We should offer seamless handover to NSIS :-) Seriously, this concerns robustness of CT protocol. -Rajeev > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > may > > > be useful for finding a new wireless medium. I also see it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should chose an AR > > > that > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing 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 Fri Apr 5 17:09: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 RAA01024 for ; Fri, 5 Apr 2002 17:09:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02648 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 17:10: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 QAA01178; Fri, 5 Apr 2002 16: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 QAA01047 for ; Fri, 5 Apr 2002 16:54:19 -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 QAA20017; Fri, 5 Apr 2002 16:54:13 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA16179; Fri, 5 Apr 2002 14:54:12 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA16869; Fri, 5 Apr 2002 14:54:12 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 15:54:12 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Gary Kenward Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 15:54:04 -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 Rajeev, I agreed with everything you say below, except one thing: CT can only transfer whatever QoS state that is usable at the newAR. If the new network is using a different QoS technology with different QoS parameters, then I am not sure if CT by itself can do the job, unless you add your own mapping functionality. BR, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 11:01 AM To: Gary Kenward Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hello, well, if the issue is QoS establishment after handover, - CT is applicable for establishing QoS state at the AR - if further signaling is desired beyond the AR, NSIS may consider it. I don't see how _signaling_ for QoS establishment beyond AR is relevant for seamoby. CAR _discovery_ could exchange QoS capability as one of the parameters that might then be fed to a selection algorithm. Any signaling for actually establishing QoS itself beyond the AR should be outside the scope of seamoby.. Regards, -Rajeev Gary Kenward wrote: > > > Hemant: > > Just a point of clarification, but as I understand CARD (and > I don't understand it well), it is not a QoS negotiation > protocol. The main application that you are referring to primarily > arises out of a perceived need to determine at the MN the best link > layer to handover over to when inter-technology handovers are > involved. > It can be applied to intra-technology handovers, but the value in > that situation is highly questionable (e.g. since it is a discovery > protocol, the implication is that the purpose is to determine the > choice of channels available; for intra-technology handovers, there > are many, many reasons why this "choice" may not be available). > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > during/after a handover. John has stated that this is not the > intention > (please correct me if I have this wrong John), in which case I think > 5.1.2 needs to be clarified. > > Specifically, is NSIS to be used to negotiated new QoS for an > existing flow after a handover, or is it specifically for establishing > > QoS for a new flow? I don't think the answer is boolean: the role > of NSIS in QoS re-negotiation is still open, I believe, and clearly > handover is a dynamic situation that could cause the QoS provided to > change. > > I have been told there is no issue, but here's a frightening > scenario: > > - a handover takes place, and context transfer has been used > to > move the QoS context to the new routers (by the requirements > for > CT this could be intra-, or inter- technology. Some of us > believe > that for "seamless" handovers, the context will be available at > > routers before the first packets need to be forwarded. This > implies > that there is a relationship, probabilistic perhaps, between > the handover process and the target ARs for CT. > > - CARD is used by the MN to influence the handover decision (it > is not clear to me how this happens, but it seems clear that > for a more "seamless" handover, the MN should chose an AR that > has received the appropriate context; if not, then what? > > - NSIS kicks in and starts re-negotiating QoS because of changes > introduced by the handover; > > How do these three protocols interact to produce predictable > outcomes? > Or, perhaps, the question is, how do the functional entities > associated > with the three protocols interact before, during and after a handover? > > If it the interaction is within the functional entities, the > respective > wg's could declare the issue out of scope, but this approach does not > sit well with me, for it seems to defer the problem to the people who > have to implement this "stuff". > > Am I imagining things? > > Cheers, > Gary > > > -----Original Message----- > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > Sent: April 4, 2002 22:33 > > To: nsis@ietf.org > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > Hi Sharif: > > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > > > Br, > > Hemant > > > > -----Original Message----- > > From: ext Shahrier, Sharif M. > > [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Thursday, April 04, 2002 3:35 PM > > To: Shahrier, Sharif M. > > Cc: 'nsis@ietf.org' > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > I have a question for clarification. > > > > I think it was stated that NSIS should only be concerned with the > > establishment of QoS after handoff. > > > > This is inconvienent with respect to IP-level QoS > > negotiation, which ideally > > should be done before handoff has taken place. > > > > QoS negotiation is in the current requirements draft. > > > > So, NSIS signaling protocol development should be concerned > > with activity > > before handoff occurs. > > > > Sharif. > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ Seamoby mailing 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 Apr 5 17:45: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 RAA03863 for ; Fri, 5 Apr 2002 17: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 QAA01178; Fri, 5 Apr 2002 16: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 QAA01047 for ; Fri, 5 Apr 2002 16:54:19 -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 QAA20017; Fri, 5 Apr 2002 16:54:13 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA16179; Fri, 5 Apr 2002 14:54:12 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA16869; Fri, 5 Apr 2002 14:54:12 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 15:54:12 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Gary Kenward Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 15:54:04 -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 Rajeev, I agreed with everything you say below, except one thing: CT can only transfer whatever QoS state that is usable at the newAR. If the new network is using a different QoS technology with different QoS parameters, then I am not sure if CT by itself can do the job, unless you add your own mapping functionality. BR, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 11:01 AM To: Gary Kenward Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hello, well, if the issue is QoS establishment after handover, - CT is applicable for establishing QoS state at the AR - if further signaling is desired beyond the AR, NSIS may consider it. I don't see how _signaling_ for QoS establishment beyond AR is relevant for seamoby. CAR _discovery_ could exchange QoS capability as one of the parameters that might then be fed to a selection algorithm. Any signaling for actually establishing QoS itself beyond the AR should be outside the scope of seamoby.. Regards, -Rajeev Gary Kenward wrote: > > > Hemant: > > Just a point of clarification, but as I understand CARD (and > I don't understand it well), it is not a QoS negotiation > protocol. The main application that you are referring to primarily > arises out of a perceived need to determine at the MN the best link > layer to handover over to when inter-technology handovers are > involved. > It can be applied to intra-technology handovers, but the value in > that situation is highly questionable (e.g. since it is a discovery > protocol, the implication is that the purpose is to determine the > choice of channels available; for intra-technology handovers, there > are many, many reasons why this "choice" may not be available). > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > during/after a handover. John has stated that this is not the > intention > (please correct me if I have this wrong John), in which case I think > 5.1.2 needs to be clarified. > > Specifically, is NSIS to be used to negotiated new QoS for an > existing flow after a handover, or is it specifically for establishing > > QoS for a new flow? I don't think the answer is boolean: the role > of NSIS in QoS re-negotiation is still open, I believe, and clearly > handover is a dynamic situation that could cause the QoS provided to > change. > > I have been told there is no issue, but here's a frightening > scenario: > > - a handover takes place, and context transfer has been used > to > move the QoS context to the new routers (by the requirements > for > CT this could be intra-, or inter- technology. Some of us > believe > that for "seamless" handovers, the context will be available at > > routers before the first packets need to be forwarded. This > implies > that there is a relationship, probabilistic perhaps, between > the handover process and the target ARs for CT. > > - CARD is used by the MN to influence the handover decision (it > is not clear to me how this happens, but it seems clear that > for a more "seamless" handover, the MN should chose an AR that > has received the appropriate context; if not, then what? > > - NSIS kicks in and starts re-negotiating QoS because of changes > introduced by the handover; > > How do these three protocols interact to produce predictable > outcomes? > Or, perhaps, the question is, how do the functional entities > associated > with the three protocols interact before, during and after a handover? > > If it the interaction is within the functional entities, the > respective > wg's could declare the issue out of scope, but this approach does not > sit well with me, for it seems to defer the problem to the people who > have to implement this "stuff". > > Am I imagining things? > > Cheers, > Gary > > > -----Original Message----- > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > Sent: April 4, 2002 22:33 > > To: nsis@ietf.org > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > Hi Sharif: > > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > > > Br, > > Hemant > > > > -----Original Message----- > > From: ext Shahrier, Sharif M. > > [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Thursday, April 04, 2002 3:35 PM > > To: Shahrier, Sharif M. > > Cc: 'nsis@ietf.org' > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > I have a question for clarification. > > > > I think it was stated that NSIS should only be concerned with the > > establishment of QoS after handoff. > > > > This is inconvienent with respect to IP-level QoS > > negotiation, which ideally > > should be done before handoff has taken place. > > > > QoS negotiation is in the current requirements draft. > > > > So, NSIS signaling protocol development should be concerned > > with activity > > before handoff occurs. > > > > Sharif. > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ Seamoby mailing 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 Apr 5 18:08: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 RAA00818 for ; Fri, 5 Apr 2002 17:09:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02530 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 17: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 RAA01955; Fri, 5 Apr 2002 17:00: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 RAA01891 for ; Fri, 5 Apr 2002 17:00:39 -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 RAA20384; Fri, 5 Apr 2002 17:00:33 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA08119; Fri, 5 Apr 2002 14:49:10 -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 PAA11013; Fri, 5 Apr 2002 15:00:36 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 16:00:36 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Rajeev Koodli Cc: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 16:00:32 -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, you are opening a can of worm that took seamoby 3 months to close without any results. People could not agree on the reliability needs of CT. We added a reliability mechanism to our CT proposal that covered both retransmission and updates. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, April 05, 2002 12:22 PM To: Rajeev Koodli Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Agree. But I don't see anything in the CT requirements about handling CT failure. ??? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 10:02 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the best > > link > > > > > > layer to handover over to when inter-technology handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > > choice of channels available; for intra-technology handovers, > > there > > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover decision > > (it > > > > > > is not clear to me how this happens, but it seems clear > > that > > > > > > for a more "seamless" handover, the MN should chose an AR > > > > that > > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 Fri Apr 5 18:20: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 SAA07299 for ; Fri, 5 Apr 2002 18:20: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 SAA05586; Fri, 5 Apr 2002 18:12: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 SAA05503 for ; Fri, 5 Apr 2002 18:12:16 -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 SAA06457; Fri, 5 Apr 2002 18:12:10 -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 PAA04485; Fri, 5 Apr 2002 15:11:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35NBgx24333; Fri, 5 Apr 2002 15:11:42 -0800 X-mProtect: <200204052311> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJlETm4; Fri, 05 Apr 2002 14:45:57 PST Message-ID: <3CAE2925.16FCCD2A@iprg.nokia.com> Date: Fri, 05 Apr 2002 14:45:57 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465003C@IL27EXM10.cig.mot.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 Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > Hello Rajeev, > > I agreed with everything you say below, except one thing: > CT can only transfer whatever QoS state that is usable at the newAR. > If the new network is using a different QoS technology with different > QoS parameters, then I am not sure if CT by itself can do the job, unless > you add your own mapping functionality. > This would be an example where the new AR sends a notification to the MN so that the MN can take appropriate action (for instance, attempt to re-create the context). Regards, -Rajeev > > BR, > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 11:01 AM > To: Gary Kenward > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello, > > well, if the issue is QoS establishment after handover, > > - CT is applicable for establishing QoS state at the AR > - if further signaling is desired beyond the AR, NSIS may > consider it. I don't see how _signaling_ for QoS establishment > beyond AR is relevant for seamoby. > > CAR _discovery_ could exchange QoS capability as one of the > parameters that might then be fed to a selection algorithm. Any > signaling for actually establishing QoS itself beyond the AR > should be outside the scope of seamoby.. > > Regards, > > -Rajeev > > Gary Kenward wrote: > > > > > > > Hemant: > > > > Just a point of clarification, but as I understand CARD (and > > I don't understand it well), it is not a QoS negotiation > > protocol. The main application that you are referring to primarily > > arises out of a perceived need to determine at the MN the best link > > layer to handover over to when inter-technology handovers are > > involved. > > It can be applied to intra-technology handovers, but the value in > > that situation is highly questionable (e.g. since it is a discovery > > protocol, the implication is that the purpose is to determine the > > choice of channels available; for intra-technology handovers, there > > are many, many reasons why this "choice" may not be available). > > > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > > > during/after a handover. John has stated that this is not the > > intention > > (please correct me if I have this wrong John), in which case I think > > 5.1.2 needs to be clarified. > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > existing flow after a handover, or is it specifically for establishing > > > > QoS for a new flow? I don't think the answer is boolean: the role > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > handover is a dynamic situation that could cause the QoS provided to > > change. > > > > I have been told there is no issue, but here's a frightening > > scenario: > > > > - a handover takes place, and context transfer has been used > > to > > move the QoS context to the new routers (by the requirements > > for > > CT this could be intra-, or inter- technology. Some of us > > believe > > that for "seamless" handovers, the context will be available at > > > > routers before the first packets need to be forwarded. This > > implies > > that there is a relationship, probabilistic perhaps, between > > the handover process and the target ARs for CT. > > > > - CARD is used by the MN to influence the handover decision (it > > is not clear to me how this happens, but it seems clear that > > for a more "seamless" handover, the MN should chose an AR that > > has received the appropriate context; if not, then what? > > > > - NSIS kicks in and starts re-negotiating QoS because of changes > > introduced by the handover; > > > > How do these three protocols interact to produce predictable > > outcomes? > > Or, perhaps, the question is, how do the functional entities > > associated > > with the three protocols interact before, during and after a handover? > > > > If it the interaction is within the functional entities, the > > respective > > wg's could declare the issue out of scope, but this approach does not > > sit well with me, for it seems to defer the problem to the people who > > have to implement this "stuff". > > > > Am I imagining things? > > > > Cheers, > > Gary > > > > > -----Original Message----- > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > Sent: April 4, 2002 22:33 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Hi Sharif: > > > > > > There is currently a debate going on in Seamoby as to whether > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > discovery protocol). > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > discovery is supposed to identify candidate access routers > > > for handoff and QoS is an important property for candidacy. > > > > > > Br, > > > Hemant > > > > > > -----Original Message----- > > > From: ext Shahrier, Sharif M. > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > Sent: Thursday, April 04, 2002 3:35 PM > > > To: Shahrier, Sharif M. > > > Cc: 'nsis@ietf.org' > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > I have a question for clarification. > > > > > > I think it was stated that NSIS should only be concerned with the > > > establishment of QoS after handoff. > > > > > > This is inconvienent with respect to IP-level QoS > > > negotiation, which ideally > > > should be done before handoff has taken place. > > > > > > QoS negotiation is in the current requirements draft. > > > > > > So, NSIS signaling protocol development should be concerned > > > with activity > > > before handoff occurs. > > > > > > Sharif. > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > Seamoby mailing 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 Apr 5 18:20: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 SAA07319 for ; Fri, 5 Apr 2002 18:20:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA06026 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 18:20: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 SAA05586; Fri, 5 Apr 2002 18:12: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 SAA05503 for ; Fri, 5 Apr 2002 18:12:16 -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 SAA06457; Fri, 5 Apr 2002 18:12:10 -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 PAA04485; Fri, 5 Apr 2002 15:11:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35NBgx24333; Fri, 5 Apr 2002 15:11:42 -0800 X-mProtect: <200204052311> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJlETm4; Fri, 05 Apr 2002 14:45:57 PST Message-ID: <3CAE2925.16FCCD2A@iprg.nokia.com> Date: Fri, 05 Apr 2002 14:45:57 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465003C@IL27EXM10.cig.mot.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 Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > Hello Rajeev, > > I agreed with everything you say below, except one thing: > CT can only transfer whatever QoS state that is usable at the newAR. > If the new network is using a different QoS technology with different > QoS parameters, then I am not sure if CT by itself can do the job, unless > you add your own mapping functionality. > This would be an example where the new AR sends a notification to the MN so that the MN can take appropriate action (for instance, attempt to re-create the context). Regards, -Rajeev > > BR, > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 11:01 AM > To: Gary Kenward > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello, > > well, if the issue is QoS establishment after handover, > > - CT is applicable for establishing QoS state at the AR > - if further signaling is desired beyond the AR, NSIS may > consider it. I don't see how _signaling_ for QoS establishment > beyond AR is relevant for seamoby. > > CAR _discovery_ could exchange QoS capability as one of the > parameters that might then be fed to a selection algorithm. Any > signaling for actually establishing QoS itself beyond the AR > should be outside the scope of seamoby.. > > Regards, > > -Rajeev > > Gary Kenward wrote: > > > > > > > Hemant: > > > > Just a point of clarification, but as I understand CARD (and > > I don't understand it well), it is not a QoS negotiation > > protocol. The main application that you are referring to primarily > > arises out of a perceived need to determine at the MN the best link > > layer to handover over to when inter-technology handovers are > > involved. > > It can be applied to intra-technology handovers, but the value in > > that situation is highly questionable (e.g. since it is a discovery > > protocol, the implication is that the purpose is to determine the > > choice of channels available; for intra-technology handovers, there > > are many, many reasons why this "choice" may not be available). > > > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > > > during/after a handover. John has stated that this is not the > > intention > > (please correct me if I have this wrong John), in which case I think > > 5.1.2 needs to be clarified. > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > existing flow after a handover, or is it specifically for establishing > > > > QoS for a new flow? I don't think the answer is boolean: the role > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > handover is a dynamic situation that could cause the QoS provided to > > change. > > > > I have been told there is no issue, but here's a frightening > > scenario: > > > > - a handover takes place, and context transfer has been used > > to > > move the QoS context to the new routers (by the requirements > > for > > CT this could be intra-, or inter- technology. Some of us > > believe > > that for "seamless" handovers, the context will be available at > > > > routers before the first packets need to be forwarded. This > > implies > > that there is a relationship, probabilistic perhaps, between > > the handover process and the target ARs for CT. > > > > - CARD is used by the MN to influence the handover decision (it > > is not clear to me how this happens, but it seems clear that > > for a more "seamless" handover, the MN should chose an AR that > > has received the appropriate context; if not, then what? > > > > - NSIS kicks in and starts re-negotiating QoS because of changes > > introduced by the handover; > > > > How do these three protocols interact to produce predictable > > outcomes? > > Or, perhaps, the question is, how do the functional entities > > associated > > with the three protocols interact before, during and after a handover? > > > > If it the interaction is within the functional entities, the > > respective > > wg's could declare the issue out of scope, but this approach does not > > sit well with me, for it seems to defer the problem to the people who > > have to implement this "stuff". > > > > Am I imagining things? > > > > Cheers, > > Gary > > > > > -----Original Message----- > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > Sent: April 4, 2002 22:33 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Hi Sharif: > > > > > > There is currently a debate going on in Seamoby as to whether > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > discovery protocol). > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > discovery is supposed to identify candidate access routers > > > for handoff and QoS is an important property for candidacy. > > > > > > Br, > > > Hemant > > > > > > -----Original Message----- > > > From: ext Shahrier, Sharif M. > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > Sent: Thursday, April 04, 2002 3:35 PM > > > To: Shahrier, Sharif M. > > > Cc: 'nsis@ietf.org' > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > I have a question for clarification. > > > > > > I think it was stated that NSIS should only be concerned with the > > > establishment of QoS after handoff. > > > > > > This is inconvienent with respect to IP-level QoS > > > negotiation, which ideally > > > should be done before handoff has taken place. > > > > > > QoS negotiation is in the current requirements draft. > > > > > > So, NSIS signaling protocol development should be concerned > > > with activity > > > before handoff occurs. > > > > > > Sharif. > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > Seamoby mailing 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 Apr 5 18:26: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 SAA08065 for ; Fri, 5 Apr 2002 18:26: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 SAA05813; Fri, 5 Apr 2002 18:15: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 SAA05779 for ; Fri, 5 Apr 2002 18:15:12 -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 SAA06732 for ; Fri, 5 Apr 2002 18:15:06 -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 PAA05336; Fri, 5 Apr 2002 15:14:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35NEbp19839; Fri, 5 Apr 2002 15:14:37 -0800 X-mProtect: <200204052314> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Z1uA2; Fri, 05 Apr 2002 15:08:21 PST Message-ID: <3CAE2E66.8E793B32@iprg.nokia.com> Date: Fri, 05 Apr 2002 15:08:22 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.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 (I trimmed the mailing lists and some of the trailing messages) Hello Madjid, The problem is that the reliability needs depend on the context feature type. Some contexts should be transferred reliably, and some are not so crucial. Reliable transfer for header compression context is not as crucial as, say, security context -- for various reasons, but at least because retransmission for the header compression state would take too long. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 5 18:26: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 SAA08074 for ; Fri, 5 Apr 2002 18:26:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA06280 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 18:26: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 SAA05813; Fri, 5 Apr 2002 18:15: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 SAA05779 for ; Fri, 5 Apr 2002 18:15:12 -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 SAA06732 for ; Fri, 5 Apr 2002 18:15:06 -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 PAA05336; Fri, 5 Apr 2002 15:14:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35NEbp19839; Fri, 5 Apr 2002 15:14:37 -0800 X-mProtect: <200204052314> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8Z1uA2; Fri, 05 Apr 2002 15:08:21 PST Message-ID: <3CAE2E66.8E793B32@iprg.nokia.com> Date: Fri, 05 Apr 2002 15:08:22 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.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 (I trimmed the mailing lists and some of the trailing messages) Hello Madjid, The problem is that the reliability needs depend on the context feature type. Some contexts should be transferred reliably, and some are not so crucial. Reliable transfer for header compression context is not as crucial as, say, security context -- for various reasons, but at least because retransmission for the header compression state would take too long. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 5 19:15: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 TAA13046 for ; Fri, 5 Apr 2002 19:15: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 TAA08238; Fri, 5 Apr 2002 19:07: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 TAA08211 for ; Fri, 5 Apr 2002 19:07: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 TAA11942 for ; Fri, 5 Apr 2002 19:07:03 -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 QAA08149; Fri, 5 Apr 2002 16:06:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3606Zo03280; Fri, 5 Apr 2002 16:06:35 -0800 X-mProtect: <200204060006> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhc6VBf; Fri, 05 Apr 2002 16:06:33 PST Message-ID: <3CAE3C0A.872BFC2E@iprg.nokia.com> Date: Fri, 05 Apr 2002 16:06:34 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> <3CAE2E66.8E793B32@iprg.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 Hello Madjid, a clarification: I don't think that Jim and I were trying to reformulate reliability requirements. They are, as Charlie points out, feature-specific. We were trying to say that the CT protocol must have a hook to inform the MN when there is an error condition (including when it is not possible to support the feature). So, I am only trying to indicate that there needs to be a notification message, since like any other protocol, CT would have error cases and failure modes. Regards, -Rajeev "Charles E. Perkins" wrote: > (I trimmed the mailing lists and some of the trailing messages) > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > > _______________________________________________ > Seamoby mailing 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 Apr 5 19:16: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 TAA13059 for ; Fri, 5 Apr 2002 19:15:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA08422 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 19: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 TAA08238; Fri, 5 Apr 2002 19:07: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 TAA08211 for ; Fri, 5 Apr 2002 19:07: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 TAA11942 for ; Fri, 5 Apr 2002 19:07:03 -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 QAA08149; Fri, 5 Apr 2002 16:06:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3606Zo03280; Fri, 5 Apr 2002 16:06:35 -0800 X-mProtect: <200204060006> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhc6VBf; Fri, 05 Apr 2002 16:06:33 PST Message-ID: <3CAE3C0A.872BFC2E@iprg.nokia.com> Date: Fri, 05 Apr 2002 16:06:34 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> <3CAE2E66.8E793B32@iprg.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 Hello Madjid, a clarification: I don't think that Jim and I were trying to reformulate reliability requirements. They are, as Charlie points out, feature-specific. We were trying to say that the CT protocol must have a hook to inform the MN when there is an error condition (including when it is not possible to support the feature). So, I am only trying to indicate that there needs to be a notification message, since like any other protocol, CT would have error cases and failure modes. Regards, -Rajeev "Charles E. Perkins" wrote: > (I trimmed the mailing lists and some of the trailing messages) > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > > _______________________________________________ > Seamoby mailing 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 Apr 5 20: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 UAA16595 for ; Fri, 5 Apr 2002 20: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 UAA10516; Fri, 5 Apr 2002 20:14: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 UAA10485 for ; Fri, 5 Apr 2002 20:14:25 -0500 (EST) Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16354 for ; Fri, 5 Apr 2002 20:14:18 -0500 (EST) Received: (cpmta 12925 invoked from network); 5 Apr 2002 17:13:52 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.214) with SMTP; 5 Apr 2002 17:13:52 -0800 X-Sent: 6 Apr 2002 01:13:52 GMT Message-ID: <001801c1dd08$50aa75f0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> <00b801c1da65$6f3ec020$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Re: NSIS was:Examples of CAR discovery Date: Fri, 5 Apr 2002 20:13:51 -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 I hate to rear my "ugly head" again. ..... but here goes..... Soft handover can work for packet networks!!!! The idea of adding a "leg" can work for IP networks!!!! The idea that we are stuck with HARD handovers is a legacy concept..... I think I have been trying to say this for about 3 years in the IETF..... Frank Zappa once wrote a song "Shut up and play your Guitar". That is the stage I am at with the IETF.... I just want to go build stuff rather than talk about it or try and convince others of the potential merrit. :-) Phil ----- Original Message ----- From: "James Kempf" To: ; Cc: Sent: Tuesday, April 02, 2002 11:42 AM Subject: [Seamoby] Re: NSIS was:Examples of CAR discovery > > What NSIS will be working on is a generalized framework, to enable > > end to edge signaling, end to end signaling and perhaps edge to edge > > signaling. > > > > For the end-to-edge signaling, the access network (maybe even the > access > > router) would/could be proxying QoS for network towards the end node. > > > > So it sounds to me the only issue is that NSIS would look at prehandoff > or posthandoff > end to edge (host to network?) signaling rather than at the time of > handoff, is that > right? > > 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 Apr 5 20: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 UAA16606 for ; Fri, 5 Apr 2002 20:26:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA10748 for seamoby-archive@odin.ietf.org; Fri, 5 Apr 2002 20:26: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 UAA10516; Fri, 5 Apr 2002 20:14: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 UAA10485 for ; Fri, 5 Apr 2002 20:14:25 -0500 (EST) Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16354 for ; Fri, 5 Apr 2002 20:14:18 -0500 (EST) Received: (cpmta 12925 invoked from network); 5 Apr 2002 17:13:52 -0800 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.214) with SMTP; 5 Apr 2002 17:13:52 -0800 X-Sent: 6 Apr 2002 01:13:52 GMT Message-ID: <001801c1dd08$50aa75f0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , , Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D7D@esebe004.NOE.Nokia.com> <00b801c1da65$6f3ec020$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] Re: NSIS was:Examples of CAR discovery Date: Fri, 5 Apr 2002 20:13:51 -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 I hate to rear my "ugly head" again. ..... but here goes..... Soft handover can work for packet networks!!!! The idea of adding a "leg" can work for IP networks!!!! The idea that we are stuck with HARD handovers is a legacy concept..... I think I have been trying to say this for about 3 years in the IETF..... Frank Zappa once wrote a song "Shut up and play your Guitar". That is the stage I am at with the IETF.... I just want to go build stuff rather than talk about it or try and convince others of the potential merrit. :-) Phil ----- Original Message ----- From: "James Kempf" To: ; Cc: Sent: Tuesday, April 02, 2002 11:42 AM Subject: [Seamoby] Re: NSIS was:Examples of CAR discovery > > What NSIS will be working on is a generalized framework, to enable > > end to edge signaling, end to end signaling and perhaps edge to edge > > signaling. > > > > For the end-to-edge signaling, the access network (maybe even the > access > > router) would/could be proxying QoS for network towards the end node. > > > > So it sounds to me the only issue is that NSIS would look at prehandoff > or posthandoff > end to edge (host to network?) signaling rather than at the time of > handoff, is that > right? > > 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 Apr 8 12: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 MAA28411 for ; Mon, 8 Apr 2002 12:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16909; Mon, 8 Apr 2002 11:57:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16838 for ; Mon, 8 Apr 2002 11:57:45 -0400 (EDT) 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 LAA27928; Mon, 8 Apr 2002 11:57:41 -0400 (EDT) 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 g38FhFI18742; Mon, 8 Apr 2002 08:43:15 -0700 (PDT) Message-ID: <001a01c1df13$dfe0aa20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 08:41:39 -0700 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 Madjid, The issue isn't reliability, it is whether the target AR can interpret the context intelligably. If not, the MN may need to recover by actually re-initializing whatever feature the context was being transfered for. But it cannot do this unless it knows that the CT has failed. For some feature contexts, like header compression, this isn't a problem because it will re-initialize automatically, but for AAA or QoS it clearly will be. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 3:00 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev > > > > > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 9:19 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello Jim, > > > > > > > > James Kempf wrote: > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > negotiation > > > > > after handover would be required. > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > notify the MN to engage in context re-creation. > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > signaling) > > > > independent of failure/success of CT. > > > > > > > > Hope this is clearer.. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > though it > > > may > > > > > be useful for finding a new wireless medium. I also see it > primarily > > > for > > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > > > jak > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "Gary Kenward" > > > > > Cc: ; ; > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > protocol. The main application that you are referring to > > > primarily > > > > > > > arises out of a perceived need to determine at the MN the > best > > > link > > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > > involved. > > > > > > > It can be applied to intra-technology handovers, but the > value > > > in > > > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > > > protocol, the implication is that the purpose is to > determine > > > the > > > > > > > choice of channels available; for intra-technology > handovers, > > > there > > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > > involvement > > > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > > intention > > > > > > > (please correct me if I have this wrong John), in which case > I > > > think > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for > an > > > > > > > existing flow after a handover, or is it specifically for > > > > > establishing > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > > clearly > > > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > > > change. > > > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > > scenario: > > > > > > > > > > > > > > - a handover takes place, and context transfer has > been > > > used > > > > > > > to > > > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > > > for > > > > > > > CT this could be intra-, or inter- technology. Some > of us > > > > > > > believe > > > > > > > that for "seamless" handovers, the context will be > > > available > > > > > at > > > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > > This > > > > > > > implies > > > > > > > that there is a relationship, probabilistic perhaps, > > > between > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > decision > > > (it > > > > > > > is not clear to me how this happens, but it seems > clear > > > that > > > > > > > for a more "seamless" handover, the MN should chose > an AR > > > > > that > > > > > > > has received the appropriate context; if not, then > what? > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because > of > > > > > changes > > > > > > > introduced by the handover; > > > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > > outcomes? > > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > > with the three protocols interact before, during and after a > > > > > handover? > > > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > > wg's could declare the issue out of scope, but this approach > > > does > > > > > not > > > > > > > sit well with me, for it seems to defer the problem to the > > > people > > > > > who > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > Cheers, > > > > > > > Gary > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hemant.Chaskar@nokia.com > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > To: nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > whether > > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > > > Br, > > > > > > > > Hemant > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned > with > > > the > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > negotiation, which ideally > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > > with activity > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing 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 > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 12: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 MAA28421 for ; Mon, 8 Apr 2002 12:08:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18902 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 12:08:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16909; Mon, 8 Apr 2002 11:57:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16838 for ; Mon, 8 Apr 2002 11:57:45 -0400 (EDT) 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 LAA27928; Mon, 8 Apr 2002 11:57:41 -0400 (EDT) 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 g38FhFI18742; Mon, 8 Apr 2002 08:43:15 -0700 (PDT) Message-ID: <001a01c1df13$dfe0aa20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 08:41:39 -0700 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 Madjid, The issue isn't reliability, it is whether the target AR can interpret the context intelligably. If not, the MN may need to recover by actually re-initializing whatever feature the context was being transfered for. But it cannot do this unless it knows that the CT has failed. For some feature contexts, like header compression, this isn't a problem because it will re-initialize automatically, but for AAA or QoS it clearly will be. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 3:00 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev > > > > > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 9:19 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello Jim, > > > > > > > > James Kempf wrote: > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > negotiation > > > > > after handover would be required. > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > notify the MN to engage in context re-creation. > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > signaling) > > > > independent of failure/success of CT. > > > > > > > > Hope this is clearer.. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > though it > > > may > > > > > be useful for finding a new wireless medium. I also see it > primarily > > > for > > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > > > jak > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "Gary Kenward" > > > > > Cc: ; ; > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > protocol. The main application that you are referring to > > > primarily > > > > > > > arises out of a perceived need to determine at the MN the > best > > > link > > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > > involved. > > > > > > > It can be applied to intra-technology handovers, but the > value > > > in > > > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > > > protocol, the implication is that the purpose is to > determine > > > the > > > > > > > choice of channels available; for intra-technology > handovers, > > > there > > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > > involvement > > > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > > intention > > > > > > > (please correct me if I have this wrong John), in which case > I > > > think > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for > an > > > > > > > existing flow after a handover, or is it specifically for > > > > > establishing > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > > clearly > > > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > > > change. > > > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > > scenario: > > > > > > > > > > > > > > - a handover takes place, and context transfer has > been > > > used > > > > > > > to > > > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > > > for > > > > > > > CT this could be intra-, or inter- technology. Some > of us > > > > > > > believe > > > > > > > that for "seamless" handovers, the context will be > > > available > > > > > at > > > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > > This > > > > > > > implies > > > > > > > that there is a relationship, probabilistic perhaps, > > > between > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > decision > > > (it > > > > > > > is not clear to me how this happens, but it seems > clear > > > that > > > > > > > for a more "seamless" handover, the MN should chose > an AR > > > > > that > > > > > > > has received the appropriate context; if not, then > what? > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because > of > > > > > changes > > > > > > > introduced by the handover; > > > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > > outcomes? > > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > > with the three protocols interact before, during and after a > > > > > handover? > > > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > > wg's could declare the issue out of scope, but this approach > > > does > > > > > not > > > > > > > sit well with me, for it seems to defer the problem to the > > > people > > > > > who > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > Cheers, > > > > > > > Gary > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hemant.Chaskar@nokia.com > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > To: nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > whether > > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > > > Br, > > > > > > > > Hemant > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned > with > > > the > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > negotiation, which ideally > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > > with activity > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing 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 > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 12:16: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 MAA28689 for ; Mon, 8 Apr 2002 12:16:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18967; Mon, 8 Apr 2002 12:09:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18937 for ; Mon, 8 Apr 2002 12:09:56 -0400 (EDT) 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 MAA28462 for ; Mon, 8 Apr 2002 12:09:52 -0400 (EDT) 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 g38G9EI19566; Mon, 8 Apr 2002 09:09:14 -0700 (PDT) Message-ID: <009101c1df17$81038d20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" , "Nakhjiri Madjid-MNAKHJI1" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> <3CAE2E66.8E793B32@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 09:07:38 -0700 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 Charlie, The other part of this is that header compression context can get re-initialized automatically if it is lost, whereas security context, for example, would require the participation of the MN. Thus, the consequences of losing the header compression context are not as severe. jak ----- Original Message ----- From: "Charles E. Perkins" To: "Nakhjiri Madjid-MNAKHJI1" Cc: "'James Kempf'" ; Sent: Friday, April 05, 2002 4:08 PM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > (I trimmed the mailing lists and some of the trailing messages) > > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 12:16: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 MAA28698 for ; Mon, 8 Apr 2002 12:16:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19476 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 12:16:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18967; Mon, 8 Apr 2002 12:09:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18937 for ; Mon, 8 Apr 2002 12:09:56 -0400 (EDT) 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 MAA28462 for ; Mon, 8 Apr 2002 12:09:52 -0400 (EDT) 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 g38G9EI19566; Mon, 8 Apr 2002 09:09:14 -0700 (PDT) Message-ID: <009101c1df17$81038d20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" , "Nakhjiri Madjid-MNAKHJI1" Cc: References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> <3CAE2E66.8E793B32@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 09:07:38 -0700 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 Charlie, The other part of this is that header compression context can get re-initialized automatically if it is lost, whereas security context, for example, would require the participation of the MN. Thus, the consequences of losing the header compression context are not as severe. jak ----- Original Message ----- From: "Charles E. Perkins" To: "Nakhjiri Madjid-MNAKHJI1" Cc: "'James Kempf'" ; Sent: Friday, April 05, 2002 4:08 PM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > (I trimmed the mailing lists and some of the trailing messages) > > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 12:33: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 MAA29189 for ; Mon, 8 Apr 2002 12:33:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19719; Mon, 8 Apr 2002 12:24:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19690 for ; Mon, 8 Apr 2002 12:24:07 -0400 (EDT) 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 MAA28885 for ; Mon, 8 Apr 2002 12:24:01 -0400 (EDT) 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 g38GAEI19592; Mon, 8 Apr 2002 09:10:15 -0700 (PDT) Message-ID: <00a101c1df17$a50c8eb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Charles E. Perkins" Cc: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> <3CAE2E66.8E793B32@iprg.nokia.com> <3CAE3C0A.872BFC2E@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 09:08:37 -0700 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 Yes, exactly. jak ----- Original Message ----- From: "Rajeev Koodli" To: "Charles E. Perkins" Cc: "Nakhjiri Madjid-MNAKHJI1" ; "'James Kempf'" ; Sent: Friday, April 05, 2002 5:06 PM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello Madjid, > > a clarification: I don't think that Jim and I were trying to > reformulate reliability requirements. They are, as Charlie > points out, feature-specific. We were trying to say that > the CT protocol must have a hook to inform the MN > when there is an error condition (including when it > is not possible to support the feature). > So, I am only trying to indicate that there needs > to be a notification message, since like any other > protocol, CT would have error cases and failure > modes. > > Regards, > > -Rajeev > > > > "Charles E. Perkins" wrote: > > > (I trimmed the mailing lists and some of the trailing messages) > > > > Hello Madjid, > > > > The problem is that the reliability needs depend on the context > > feature type. Some contexts should be transferred reliably, and > > some are not so crucial. Reliable transfer for header compression > > context is not as crucial as, say, security context -- for > > various reasons, but at least because retransmission for the > > header compression state would take too long. > > > > Regards, > > Charlie P. > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > _______________________________________________ > > Seamoby mailing 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 Apr 8 12:33: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 MAA29199 for ; Mon, 8 Apr 2002 12:33:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20587 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 12:33:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19719; Mon, 8 Apr 2002 12:24:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19690 for ; Mon, 8 Apr 2002 12:24:07 -0400 (EDT) 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 MAA28885 for ; Mon, 8 Apr 2002 12:24:01 -0400 (EDT) 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 g38GAEI19592; Mon, 8 Apr 2002 09:10:15 -0700 (PDT) Message-ID: <00a101c1df17$a50c8eb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Charles E. Perkins" Cc: "Nakhjiri Madjid-MNAKHJI1" , References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> <3CAE2E66.8E793B32@iprg.nokia.com> <3CAE3C0A.872BFC2E@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 09:08:37 -0700 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 Yes, exactly. jak ----- Original Message ----- From: "Rajeev Koodli" To: "Charles E. Perkins" Cc: "Nakhjiri Madjid-MNAKHJI1" ; "'James Kempf'" ; Sent: Friday, April 05, 2002 5:06 PM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello Madjid, > > a clarification: I don't think that Jim and I were trying to > reformulate reliability requirements. They are, as Charlie > points out, feature-specific. We were trying to say that > the CT protocol must have a hook to inform the MN > when there is an error condition (including when it > is not possible to support the feature). > So, I am only trying to indicate that there needs > to be a notification message, since like any other > protocol, CT would have error cases and failure > modes. > > Regards, > > -Rajeev > > > > "Charles E. Perkins" wrote: > > > (I trimmed the mailing lists and some of the trailing messages) > > > > Hello Madjid, > > > > The problem is that the reliability needs depend on the context > > feature type. Some contexts should be transferred reliably, and > > some are not so crucial. Reliable transfer for header compression > > context is not as crucial as, say, security context -- for > > various reasons, but at least because retransmission for the > > header compression state would take too long. > > > > Regards, > > Charlie P. > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > _______________________________________________ > > Seamoby mailing 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 Apr 8 14:07: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 OAA01449 for ; Mon, 8 Apr 2002 14:07:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24556; Mon, 8 Apr 2002 13:44:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24490 for ; Mon, 8 Apr 2002 13:44:26 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00824; Mon, 8 Apr 2002 13:44:23 -0400 (EDT) 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 g38HdSt01176; Mon, 8 Apr 2002 13:39:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 13:39:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "'James Kempf'" , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 13:39:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF23.E02FD9AA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF23.E02FD9AA Content-Type: text/plain; charset="iso-8859-1" Rajeev: This was discussed extensively within the design team, and, I believe, also in the working group. CT is a transfer protocol. If the target AR is able to detect that the transfer has failed (e.g a CRC error, a timeout), then the target AR simply decides if it still wants to transfer context from the source, and, if it does, it issues a new request for context transfer. No special message is required. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 5, 2002 16:44 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'James Kempf'; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Gary, > > CT is a protocol, and as such would have failure > modes. For instance, transferred context is not > useful at the target router. You could say that CARD > should never let this happen. Does that mean that > CT cannot be used where CARD is not available ? > I hope not! > > In any case, I don't know of a protocol that does not > have failure modes. We need a notification > message in CT to inform when such a thing happens. > > Regards, > > -Rajeev > > > Gary Kenward wrote: > > > > > > > Well yes and no. > > > > First, CT is required to do everything it can to get the > > context across intact, as fast as possible, which, it was decided, > > meant > > that there was realistically only one opportunity to attempt to > > transfer > > the context. The emphasis was placed on requiring that a given > > transfer of > > context would not fail (e.g. the context integrity should > be preserved > > through > > error control, etc.). Then, if the transfer failed it was because of > > something > > other then the transfer process itself. > > > > If CT fails, it is more likely then not that handover will not be > > seamless > > anyways, and there is nothing that CT can do, per se, to recover. > > Having said this, CT can be re-invoked by another entity, > perhaps the > > handover > > control function, for recovery purposes. > > > > I'm trying to be brief, so I hope this captures what was a looooong > > discussion. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 5, 2002 13:22 > > > To: Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > > > > > > > > > ------_=_NextPart_001_01C1DF23.E02FD9AA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

This was discussed extensively within the design team, and,
I believe, also in the working group.

CT is a transfer protocol. If the target AR is able to detect
that the transfer has failed (e.g a CRC error, a timeout), then
the target AR simply decides if it still wants to transfer
context from the source, and, if it does, it issues a new request
for context transfer.

No special message is required.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 5, 2002 16:44
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'James Kempf'; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Gary,
>
> CT is a protocol, and as such would have failure
> modes. For instance, transferred context is not
> useful at the target router. You could say that CARD
> should never let this happen. Does that mean that
> CT cannot be used where CARD is not available ?
> I hope not!
>
> In any case, I don't know of a protocol that does not
> have failure modes. We need a notification
> message in CT to inform when such a thing happens.
>
> Regards,
>
> -Rajeev
>
>
> Gary Kenward wrote:
>
> >
> >
> > Well yes and no.
> >
> > First, CT is required to do everything it can to get the
> > context across intact, as fast as possible, which, it was decided,
> > meant
> > that there was realistically only one opportunity to attempt to
> > transfer
> > the context. The emphasis was placed on requiring that a given
> > transfer of
> > context would not fail (e.g. the context integrity should
> be preserved
> > through
> > error control, etc.). Then, if the transfer failed it was because of
> > something
> > other then the transfer process itself.
> >
> > If CT fails, it is more likely then not that handover will not be
> > seamless
> > anyways, and there is nothing that CT can do, per se, to recover.
> > Having said this, CT can be re-invoked by another entity,
> perhaps the
> > handover
> > control function, for recovery purposes.
> >
> > I'm trying to be brief, so I hope this captures what was a looooong
> > discussion.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 5, 2002 13:22
> > > To: Rajeev Koodli
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > > Agree.
> > >
> > > But I don't see anything in the CT requirements about handling CT
> > > failure.
> > >
> > > ???
> > >
> > >             jak
> > >
> >  >
> > >
> > >
>
>

------_=_NextPart_001_01C1DF23.E02FD9AA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 14: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 OAA01468 for ; Mon, 8 Apr 2002 14:07:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26406 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 14:07:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24556; Mon, 8 Apr 2002 13:44:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24490 for ; Mon, 8 Apr 2002 13:44:26 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00824; Mon, 8 Apr 2002 13:44:23 -0400 (EDT) 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 g38HdSt01176; Mon, 8 Apr 2002 13:39:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 13:39:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "'James Kempf'" , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 13:39:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF23.E02FD9AA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF23.E02FD9AA Content-Type: text/plain; charset="iso-8859-1" Rajeev: This was discussed extensively within the design team, and, I believe, also in the working group. CT is a transfer protocol. If the target AR is able to detect that the transfer has failed (e.g a CRC error, a timeout), then the target AR simply decides if it still wants to transfer context from the source, and, if it does, it issues a new request for context transfer. No special message is required. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 5, 2002 16:44 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'James Kempf'; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Gary, > > CT is a protocol, and as such would have failure > modes. For instance, transferred context is not > useful at the target router. You could say that CARD > should never let this happen. Does that mean that > CT cannot be used where CARD is not available ? > I hope not! > > In any case, I don't know of a protocol that does not > have failure modes. We need a notification > message in CT to inform when such a thing happens. > > Regards, > > -Rajeev > > > Gary Kenward wrote: > > > > > > > Well yes and no. > > > > First, CT is required to do everything it can to get the > > context across intact, as fast as possible, which, it was decided, > > meant > > that there was realistically only one opportunity to attempt to > > transfer > > the context. The emphasis was placed on requiring that a given > > transfer of > > context would not fail (e.g. the context integrity should > be preserved > > through > > error control, etc.). Then, if the transfer failed it was because of > > something > > other then the transfer process itself. > > > > If CT fails, it is more likely then not that handover will not be > > seamless > > anyways, and there is nothing that CT can do, per se, to recover. > > Having said this, CT can be re-invoked by another entity, > perhaps the > > handover > > control function, for recovery purposes. > > > > I'm trying to be brief, so I hope this captures what was a looooong > > discussion. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 5, 2002 13:22 > > > To: Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > > > > > > > > > ------_=_NextPart_001_01C1DF23.E02FD9AA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

This was discussed extensively within the design team, and,
I believe, also in the working group.

CT is a transfer protocol. If the target AR is able to detect
that the transfer has failed (e.g a CRC error, a timeout), then
the target AR simply decides if it still wants to transfer
context from the source, and, if it does, it issues a new request
for context transfer.

No special message is required.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 5, 2002 16:44
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'James Kempf'; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Gary,
>
> CT is a protocol, and as such would have failure
> modes. For instance, transferred context is not
> useful at the target router. You could say that CARD
> should never let this happen. Does that mean that
> CT cannot be used where CARD is not available ?
> I hope not!
>
> In any case, I don't know of a protocol that does not
> have failure modes. We need a notification
> message in CT to inform when such a thing happens.
>
> Regards,
>
> -Rajeev
>
>
> Gary Kenward wrote:
>
> >
> >
> > Well yes and no.
> >
> > First, CT is required to do everything it can to get the
> > context across intact, as fast as possible, which, it was decided,
> > meant
> > that there was realistically only one opportunity to attempt to
> > transfer
> > the context. The emphasis was placed on requiring that a given
> > transfer of
> > context would not fail (e.g. the context integrity should
> be preserved
> > through
> > error control, etc.). Then, if the transfer failed it was because of
> > something
> > other then the transfer process itself.
> >
> > If CT fails, it is more likely then not that handover will not be
> > seamless
> > anyways, and there is nothing that CT can do, per se, to recover.
> > Having said this, CT can be re-invoked by another entity,
> perhaps the
> > handover
> > control function, for recovery purposes.
> >
> > I'm trying to be brief, so I hope this captures what was a looooong
> > discussion.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 5, 2002 13:22
> > > To: Rajeev Koodli
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > > Agree.
> > >
> > > But I don't see anything in the CT requirements about handling CT
> > > failure.
> > >
> > > ???
> > >
> > >             jak
> > >
> >  >
> > >
> > >
>
>

------_=_NextPart_001_01C1DF23.E02FD9AA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 14:09: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 OAA01551 for ; Mon, 8 Apr 2002 14:09:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25402; Mon, 8 Apr 2002 13:59:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25251 for ; Mon, 8 Apr 2002 13:58:56 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01294; Mon, 8 Apr 2002 13:58:53 -0400 (EDT) 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 g38HsMt02099; Mon, 8 Apr 2002 13:54:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 13:54:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 13:54:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF26.68AF79AA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF26.68AF79AA Content-Type: text/plain; charset="iso-8859-1" Rajeev: In order for the MN to "recreate the context", the MN would have to understand the semantics of Context transfer, etc., and, more important, there would have to be a protocol or protocols that would allow the MN to recreate contexts at an AR. I doubt that the latter is going to happen (e.g. authentication). IF and when a CT fails, the easiest way to "recreate" context is for the sessions to be dropped. This may seem drastic, but in reality, what is going to cause CT to fail and how often will this happen? There may be mitigating actions that could be taken to re-establish certain sessions. But these decisions are must be driven by the policy of the network administration (explicit or implicity), and comply with the security, resource management and accounting requirements for the network. Hopefully, none of these mitigating actions requires more over-the-air signalling. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 5, 2002 17:46 > To: Nakhjiri Madjid-MNAKHJI1 > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > Hello Rajeev, > > > > I agreed with everything you say below, except one thing: > > CT can only transfer whatever QoS state that is usable at the newAR. > > If the new network is using a different QoS technology with > different > > QoS parameters, then I am not sure if CT by itself can do > the job, unless > > you add your own mapping functionality. > > > > This would be an example where the new AR sends a > notification to the MN so that the MN can take > appropriate action (for instance, attempt to > re-create the context). > > Regards, > > -Rajeev > > > > > > BR, > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Friday, April 05, 2002 11:01 AM > > To: Gary Kenward > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the > best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a > discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology > handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply > NSIS involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which > case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, > and clearly > > > handover is a dynamic situation that could cause the QoS > provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer > has been used > > > to > > > move the QoS context to the new routers (by the > requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be > available at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic > perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover > decision (it > > > is not clear to me how this happens, but it seems > clear that > > > for a more "seamless" handover, the MN should > chose an AR that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS > because of changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and > after a handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this > approach does not > > > sit well with me, for it seems to defer the problem to > the people who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be > concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > ------_=_NextPart_001_01C1DF26.68AF79AA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

In order for the MN to "recreate the context", the MN would
have to understand the semantics of Context transfer, etc.,
and, more important, there would have to be a protocol or
protocols that would allow the MN to recreate contexts at an AR.
I doubt that the latter is going to happen (e.g. authentication).

IF and when a CT fails, the easiest way to "recreate" context
is for the sessions to be dropped. This may seem drastic,
but in reality, what is going to cause CT to fail and
how often will this happen?

There may be mitigating actions that could be taken to re-establish
certain sessions. But these decisions are must be driven by the policy
of the network administration (explicit or implicity), and comply
with the security, resource management and accounting requirements
for the network. Hopefully, none of these mitigating actions requires
more over-the-air signalling.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 5, 2002 17:46
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Hello Madjid,
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
>
> > Hello Rajeev,
> >
> > I agreed with everything you say below, except one thing:
> > CT can only transfer whatever QoS state that is usable at the newAR.
> > If the new network is using a different QoS technology with
> different
> > QoS parameters, then I am not sure if CT by itself can do
> the job, unless
> > you add your own mapping functionality.
> >
>
> This would be an example where the new AR sends a
> notification to the MN so that the MN can take
> appropriate action (for instance, attempt to
> re-create the context).
>
> Regards,
>
> -Rajeev
>
>
> >
> > BR,
> > Madjid
> >
> > -----Original Message-----
> > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > Sent: Friday, April 05, 2002 11:01 AM
> > To: Gary Kenward
> > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> > Hello,
> >
> > well, if the issue is QoS establishment after handover,
> >
> > - CT is applicable for establishing QoS state at the AR
> > - if further signaling is desired beyond the AR, NSIS may
> >     consider it. I don't see how _signaling_ for QoS establishment
> >     beyond AR is relevant for seamoby.
> >
> > CAR _discovery_ could exchange QoS capability as one of the
> > parameters that might then be fed to a selection algorithm. Any
> > signaling for actually establishing QoS itself beyond the AR
> > should be outside the scope of seamoby..
> >
> > Regards,
> >
> > -Rajeev
> >
> > Gary Kenward wrote:
> >
> > >
> > >
> > > Hemant:
> > >
> > >   Just a point of clarification, but as I understand CARD (and
> > > I don't understand it well), it is not a QoS negotiation
> > > protocol. The main application that you are referring to primarily
> > > arises out of a perceived need to determine at the MN the
> best link
> > > layer to handover over to when inter-technology handovers are
> > > involved.
> > > It can be applied to intra-technology handovers, but the value in
> > > that situation is highly questionable (e.g. since it is a
> discovery
> > > protocol, the implication is that the purpose is to determine the
> > > choice of channels available; for intra-technology
> handovers, there
> > > are many, many reasons why this "choice" may not be available).
> > >
> > >   There is a requirement, 5.1.2, which seems to imply
> NSIS involvement
> > >
> > > during/after a handover. John has stated that this is not the
> > > intention
> > > (please correct me if I have this wrong John), in which
> case I think
> > > 5.1.2 needs to be clarified.
> > >
> > >   Specifically, is NSIS to be used to negotiated new QoS for an
> > > existing flow after a handover, or is it specifically for
> establishing
> > >
> > > QoS for a new flow? I don't think the answer is boolean: the role
> > > of NSIS in QoS re-negotiation is still open, I believe,
> and clearly
> > > handover is a dynamic situation that could cause the QoS
> provided to
> > > change.
> > >
> > >   I have been told there is no issue, but here's a frightening
> > > scenario:
> > >
> > >         - a handover takes place, and context transfer
> has been used
> > > to
> > >        move the QoS context to the new routers (by the
> requirements
> > > for
> > >        CT this could be intra-, or inter- technology. Some of us
> > > believe
> > >        that for "seamless" handovers, the context will be
> available at
> > >
> > >        routers before the first packets need to be forwarded. This
> > > implies
> > >        that there is a relationship, probabilistic
> perhaps, between
> > >        the handover process and the target ARs for CT.
> > >
> > >      - CARD is used by the MN to influence the handover
> decision (it
> > >        is not clear to me how this happens, but it seems
> clear that
> > >        for a more "seamless" handover, the MN should
> chose an AR that
> > >        has received the appropriate context; if not, then what?
> > >
> > >      - NSIS kicks in and starts re-negotiating QoS
> because of changes
> > >        introduced by the handover;
> > >
> > >   How do these three protocols interact to produce predictable
> > > outcomes?
> > > Or, perhaps, the question is, how do the functional entities
> > > associated
> > > with the three protocols interact before, during and
> after a handover?
> > >
> > > If it the interaction is within the functional entities, the
> > > respective
> > > wg's could declare the issue out of scope, but this
> approach does not
> > > sit well with me, for it seems to defer the problem to
> the people who
> > > have to implement this "stuff".
> > >
> > >   Am I imagining things?
> > >
> > > Cheers,
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> > > > Sent: April 4, 2002 22:33
> > > > To: nsis@ietf.org
> > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > > Hi Sharif:
> > > >
> > > > There is currently a debate going on in Seamoby as to whether
> > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > discovery protocol).
> > > >
> > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > discovery is supposed to identify candidate access routers
> > > > for handoff and QoS is an important property for candidacy.
> > > >
> > > > Br,
> > > > Hemant
> > > >
> > > > -----Original Message-----
> > > > From: ext Shahrier, Sharif M.
> > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > To: Shahrier, Sharif M.
> > > > Cc: 'nsis@ietf.org'
> > > > Subject: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > >
> > > > I have a question for clarification.
> > > >
> > > > I think it was stated that NSIS should only be
> concerned with the
> > > > establishment of QoS after handoff.
> > > >
> > > > This is inconvienent with respect to IP-level QoS
> > > > negotiation, which ideally
> > > > should be done before handoff has taken place.
> > > >
> > > > QoS negotiation is in the current requirements draft.
> > > >
> > > > So, NSIS signaling protocol development should be concerned
> > > > with activity
> > > > before handoff occurs.
> > > >
> > > > Sharif.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
>
>

------_=_NextPart_001_01C1DF26.68AF79AA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 14:09: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 OAA01565 for ; Mon, 8 Apr 2002 14:09:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26549 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 14:09:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25402; Mon, 8 Apr 2002 13:59:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25251 for ; Mon, 8 Apr 2002 13:58:56 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01294; Mon, 8 Apr 2002 13:58:53 -0400 (EDT) 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 g38HsMt02099; Mon, 8 Apr 2002 13:54:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 13:54:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 13:54:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF26.68AF79AA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF26.68AF79AA Content-Type: text/plain; charset="iso-8859-1" Rajeev: In order for the MN to "recreate the context", the MN would have to understand the semantics of Context transfer, etc., and, more important, there would have to be a protocol or protocols that would allow the MN to recreate contexts at an AR. I doubt that the latter is going to happen (e.g. authentication). IF and when a CT fails, the easiest way to "recreate" context is for the sessions to be dropped. This may seem drastic, but in reality, what is going to cause CT to fail and how often will this happen? There may be mitigating actions that could be taken to re-establish certain sessions. But these decisions are must be driven by the policy of the network administration (explicit or implicity), and comply with the security, resource management and accounting requirements for the network. Hopefully, none of these mitigating actions requires more over-the-air signalling. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 5, 2002 17:46 > To: Nakhjiri Madjid-MNAKHJI1 > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > Hello Rajeev, > > > > I agreed with everything you say below, except one thing: > > CT can only transfer whatever QoS state that is usable at the newAR. > > If the new network is using a different QoS technology with > different > > QoS parameters, then I am not sure if CT by itself can do > the job, unless > > you add your own mapping functionality. > > > > This would be an example where the new AR sends a > notification to the MN so that the MN can take > appropriate action (for instance, attempt to > re-create the context). > > Regards, > > -Rajeev > > > > > > BR, > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Friday, April 05, 2002 11:01 AM > > To: Gary Kenward > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the > best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a > discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology > handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply > NSIS involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which > case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, > and clearly > > > handover is a dynamic situation that could cause the QoS > provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer > has been used > > > to > > > move the QoS context to the new routers (by the > requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be > available at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic > perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover > decision (it > > > is not clear to me how this happens, but it seems > clear that > > > for a more "seamless" handover, the MN should > chose an AR that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS > because of changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and > after a handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this > approach does not > > > sit well with me, for it seems to defer the problem to > the people who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be > concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > ------_=_NextPart_001_01C1DF26.68AF79AA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

In order for the MN to "recreate the context", the MN would
have to understand the semantics of Context transfer, etc.,
and, more important, there would have to be a protocol or
protocols that would allow the MN to recreate contexts at an AR.
I doubt that the latter is going to happen (e.g. authentication).

IF and when a CT fails, the easiest way to "recreate" context
is for the sessions to be dropped. This may seem drastic,
but in reality, what is going to cause CT to fail and
how often will this happen?

There may be mitigating actions that could be taken to re-establish
certain sessions. But these decisions are must be driven by the policy
of the network administration (explicit or implicity), and comply
with the security, resource management and accounting requirements
for the network. Hopefully, none of these mitigating actions requires
more over-the-air signalling.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 5, 2002 17:46
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Hello Madjid,
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
>
> > Hello Rajeev,
> >
> > I agreed with everything you say below, except one thing:
> > CT can only transfer whatever QoS state that is usable at the newAR.
> > If the new network is using a different QoS technology with
> different
> > QoS parameters, then I am not sure if CT by itself can do
> the job, unless
> > you add your own mapping functionality.
> >
>
> This would be an example where the new AR sends a
> notification to the MN so that the MN can take
> appropriate action (for instance, attempt to
> re-create the context).
>
> Regards,
>
> -Rajeev
>
>
> >
> > BR,
> > Madjid
> >
> > -----Original Message-----
> > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > Sent: Friday, April 05, 2002 11:01 AM
> > To: Gary Kenward
> > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> > Hello,
> >
> > well, if the issue is QoS establishment after handover,
> >
> > - CT is applicable for establishing QoS state at the AR
> > - if further signaling is desired beyond the AR, NSIS may
> >     consider it. I don't see how _signaling_ for QoS establishment
> >     beyond AR is relevant for seamoby.
> >
> > CAR _discovery_ could exchange QoS capability as one of the
> > parameters that might then be fed to a selection algorithm. Any
> > signaling for actually establishing QoS itself beyond the AR
> > should be outside the scope of seamoby..
> >
> > Regards,
> >
> > -Rajeev
> >
> > Gary Kenward wrote:
> >
> > >
> > >
> > > Hemant:
> > >
> > >   Just a point of clarification, but as I understand CARD (and
> > > I don't understand it well), it is not a QoS negotiation
> > > protocol. The main application that you are referring to primarily
> > > arises out of a perceived need to determine at the MN the
> best link
> > > layer to handover over to when inter-technology handovers are
> > > involved.
> > > It can be applied to intra-technology handovers, but the value in
> > > that situation is highly questionable (e.g. since it is a
> discovery
> > > protocol, the implication is that the purpose is to determine the
> > > choice of channels available; for intra-technology
> handovers, there
> > > are many, many reasons why this "choice" may not be available).
> > >
> > >   There is a requirement, 5.1.2, which seems to imply
> NSIS involvement
> > >
> > > during/after a handover. John has stated that this is not the
> > > intention
> > > (please correct me if I have this wrong John), in which
> case I think
> > > 5.1.2 needs to be clarified.
> > >
> > >   Specifically, is NSIS to be used to negotiated new QoS for an
> > > existing flow after a handover, or is it specifically for
> establishing
> > >
> > > QoS for a new flow? I don't think the answer is boolean: the role
> > > of NSIS in QoS re-negotiation is still open, I believe,
> and clearly
> > > handover is a dynamic situation that could cause the QoS
> provided to
> > > change.
> > >
> > >   I have been told there is no issue, but here's a frightening
> > > scenario:
> > >
> > >         - a handover takes place, and context transfer
> has been used
> > > to
> > >        move the QoS context to the new routers (by the
> requirements
> > > for
> > >        CT this could be intra-, or inter- technology. Some of us
> > > believe
> > >        that for "seamless" handovers, the context will be
> available at
> > >
> > >        routers before the first packets need to be forwarded. This
> > > implies
> > >        that there is a relationship, probabilistic
> perhaps, between
> > >        the handover process and the target ARs for CT.
> > >
> > >      - CARD is used by the MN to influence the handover
> decision (it
> > >        is not clear to me how this happens, but it seems
> clear that
> > >        for a more "seamless" handover, the MN should
> chose an AR that
> > >        has received the appropriate context; if not, then what?
> > >
> > >      - NSIS kicks in and starts re-negotiating QoS
> because of changes
> > >        introduced by the handover;
> > >
> > >   How do these three protocols interact to produce predictable
> > > outcomes?
> > > Or, perhaps, the question is, how do the functional entities
> > > associated
> > > with the three protocols interact before, during and
> after a handover?
> > >
> > > If it the interaction is within the functional entities, the
> > > respective
> > > wg's could declare the issue out of scope, but this
> approach does not
> > > sit well with me, for it seems to defer the problem to
> the people who
> > > have to implement this "stuff".
> > >
> > >   Am I imagining things?
> > >
> > > Cheers,
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> > > > Sent: April 4, 2002 22:33
> > > > To: nsis@ietf.org
> > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > > Hi Sharif:
> > > >
> > > > There is currently a debate going on in Seamoby as to whether
> > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > discovery protocol).
> > > >
> > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > discovery is supposed to identify candidate access routers
> > > > for handoff and QoS is an important property for candidacy.
> > > >
> > > > Br,
> > > > Hemant
> > > >
> > > > -----Original Message-----
> > > > From: ext Shahrier, Sharif M.
> > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > To: Shahrier, Sharif M.
> > > > Cc: 'nsis@ietf.org'
> > > > Subject: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > >
> > > > I have a question for clarification.
> > > >
> > > > I think it was stated that NSIS should only be
> concerned with the
> > > > establishment of QoS after handoff.
> > > >
> > > > This is inconvienent with respect to IP-level QoS
> > > > negotiation, which ideally
> > > > should be done before handoff has taken place.
> > > >
> > > > QoS negotiation is in the current requirements draft.
> > > >
> > > > So, NSIS signaling protocol development should be concerned
> > > > with activity
> > > > before handoff occurs.
> > > >
> > > > Sharif.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
>
>

------_=_NextPart_001_01C1DF26.68AF79AA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 14:17: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 OAA01758 for ; Mon, 8 Apr 2002 14:17:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26176; Mon, 8 Apr 2002 14:03:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26145 for ; Mon, 8 Apr 2002 14:03:17 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01388 for ; Mon, 8 Apr 2002 14:03:14 -0400 (EDT) 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 g38I2Fi29871; Mon, 8 Apr 2002 14:02:15 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 14:02:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E7@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 14:02:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF27.83FC05D8" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF27.83FC05D8 Content-Type: text/plain; charset="iso-8859-1" Charlie: Agreed. But, as was discuss at length over the last year, the actual failure points and their frequency are very limited, and there are reasonable and not-so-reasonable mitigating responses. If someone really wants to provide CT over an all wireless ad hoc network, for example, then, yes, additional reliability will probably be required. In most wired infrastructure scenarios, the link reliability is more then sufficient. To allow for this flexibility in reliability, this type of reliability needs to be provided in the transport layer, not with CT. Specific reasons for building additional reliability into the CT protocol that are generally applicable to a majority of scenarios, and cannot be resolved by substituting a more robust transport protocol, have yet to be offered. Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 5, 2002 18:08 > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > (I trimmed the mailing lists and some of the trailing messages) > > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR > would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DF27.83FC05D8 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Charlie:

  Agreed. But, as was discuss at length over the last year,
the actual failure points and their frequency are very limited,
and there are reasonable and not-so-reasonable mitigating responses.

  If someone really wants to provide CT over an all wireless
ad hoc network, for example, then, yes, additional reliability
will probably be required. In most wired infrastructure scenarios,
the link reliability is more then sufficient.

To allow for this flexibility in reliability, this type of
reliability needs to be provided in the transport layer, not
with CT. Specific reasons for building additional reliability
into the CT protocol that are generally applicable to a majority
of scenarios, and cannot be resolved by substituting a more
robust transport protocol, have yet to be offered.

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 5, 2002 18:08
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'James Kempf'; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> (I trimmed the mailing lists and some of the trailing messages)
>
>
> Hello Madjid,
>
> The problem is that the reliability needs depend on the context
> feature type.   Some contexts should be transferred reliably, and
> some are not so crucial.  Reliable transfer for header compression
> context is not as crucial as, say, security context -- for
> various reasons, but at least because retransmission for the
> header compression state would take too long.
>
> Regards,
> Charlie P.
>
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
> >
> > Well, you are opening a can of worm that took seamoby 3 months
> > to close without any results. People could not agree on the
> > reliability needs of CT. We added a reliability mechanism to our
> > CT proposal that covered both retransmission and updates.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: Friday, April 05, 2002 12:22 PM
> > To: Rajeev Koodli
> > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> > seamoby@ietf.org
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> > Agree.
> >
> > But I don't see anything in the CT requirements about handling CT
> > failure.
> >
> > ???
> >
> >             jak
> >
> > ----- Original Message -----
> > From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> > To: "James Kempf" <kempf@docomolabs-usa.com>
> > Cc: "Gary Kenward" <gkenward@nortelnetworks.com>;
> > <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> > Sent: Friday, April 05, 2002 10:02 AM
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> > > James Kempf wrote:
> > >
> > > > Rajeev,
> > > >
> > > > I agree, but there is still an issue of how the AR
> would notify the
> > MN
> > > > if CT fails. Is this covered by CT or not?
> > > >
> > >
> > > This notification should be covered by CT.  We should offer
> > > seamless handover to NSIS :-) Seriously, this concerns
> > > robustness of CT protocol.
> > >
> > > -Rajeev
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DF27.83FC05D8-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 14: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 OAA01772 for ; Mon, 8 Apr 2002 14:17:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26994 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 14:17:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26176; Mon, 8 Apr 2002 14:03:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26145 for ; Mon, 8 Apr 2002 14:03:17 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01388 for ; Mon, 8 Apr 2002 14:03:14 -0400 (EDT) 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 g38I2Fi29871; Mon, 8 Apr 2002 14:02:15 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 14:02:15 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E7@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 14:02:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF27.83FC05D8" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF27.83FC05D8 Content-Type: text/plain; charset="iso-8859-1" Charlie: Agreed. But, as was discuss at length over the last year, the actual failure points and their frequency are very limited, and there are reasonable and not-so-reasonable mitigating responses. If someone really wants to provide CT over an all wireless ad hoc network, for example, then, yes, additional reliability will probably be required. In most wired infrastructure scenarios, the link reliability is more then sufficient. To allow for this flexibility in reliability, this type of reliability needs to be provided in the transport layer, not with CT. Specific reasons for building additional reliability into the CT protocol that are generally applicable to a majority of scenarios, and cannot be resolved by substituting a more robust transport protocol, have yet to be offered. Gary > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 5, 2002 18:08 > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > (I trimmed the mailing lists and some of the trailing messages) > > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR > would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DF27.83FC05D8 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Charlie:

  Agreed. But, as was discuss at length over the last year,
the actual failure points and their frequency are very limited,
and there are reasonable and not-so-reasonable mitigating responses.

  If someone really wants to provide CT over an all wireless
ad hoc network, for example, then, yes, additional reliability
will probably be required. In most wired infrastructure scenarios,
the link reliability is more then sufficient.

To allow for this flexibility in reliability, this type of
reliability needs to be provided in the transport layer, not
with CT. Specific reasons for building additional reliability
into the CT protocol that are generally applicable to a majority
of scenarios, and cannot be resolved by substituting a more
robust transport protocol, have yet to be offered.

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 5, 2002 18:08
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'James Kempf'; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> (I trimmed the mailing lists and some of the trailing messages)
>
>
> Hello Madjid,
>
> The problem is that the reliability needs depend on the context
> feature type.   Some contexts should be transferred reliably, and
> some are not so crucial.  Reliable transfer for header compression
> context is not as crucial as, say, security context -- for
> various reasons, but at least because retransmission for the
> header compression state would take too long.
>
> Regards,
> Charlie P.
>
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
> >
> > Well, you are opening a can of worm that took seamoby 3 months
> > to close without any results. People could not agree on the
> > reliability needs of CT. We added a reliability mechanism to our
> > CT proposal that covered both retransmission and updates.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: Friday, April 05, 2002 12:22 PM
> > To: Rajeev Koodli
> > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> > seamoby@ietf.org
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> > Agree.
> >
> > But I don't see anything in the CT requirements about handling CT
> > failure.
> >
> > ???
> >
> >             jak
> >
> > ----- Original Message -----
> > From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> > To: "James Kempf" <kempf@docomolabs-usa.com>
> > Cc: "Gary Kenward" <gkenward@nortelnetworks.com>;
> > <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> > Sent: Friday, April 05, 2002 10:02 AM
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> > > James Kempf wrote:
> > >
> > > > Rajeev,
> > > >
> > > > I agree, but there is still an issue of how the AR
> would notify the
> > MN
> > > > if CT fails. Is this covered by CT or not?
> > > >
> > >
> > > This notification should be covered by CT.  We should offer
> > > seamless handover to NSIS :-) Seriously, this concerns
> > > robustness of CT protocol.
> > >
> > > -Rajeev
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DF27.83FC05D8-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 14:52: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 OAA02580 for ; Mon, 8 Apr 2002 14:52:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28618; Mon, 8 Apr 2002 14:36:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28552 for ; Mon, 8 Apr 2002 14:35:59 -0400 (EDT) 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 OAA02158; Mon, 8 Apr 2002 14:35:55 -0400 (EDT) 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 g38IRLI24985; Mon, 8 Apr 2002 11:27:21 -0700 (PDT) Message-ID: <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 11:25:45 -0700 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 Gary, I don't think the issue is having the MN re-create the context. Is is allowing the MN to recover by re-running the actions that were necessary to create the context in the first place, in the event the AR was unable to interpret it. Thus, for example, suppose that QoS context is transferred from old to new AR, but new AR for some reason can't interpret it, perhaps there is no bandwidth left or perhaps the new AR uses a different representation for QoS context. The MN would need to be informed somehow so that it could re-do its QoS signaling. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 10:54 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Apr 8 14:52: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 OAA02590 for ; Mon, 8 Apr 2002 14:52:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29606 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 14:52:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28618; Mon, 8 Apr 2002 14:36:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28552 for ; Mon, 8 Apr 2002 14:35:59 -0400 (EDT) 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 OAA02158; Mon, 8 Apr 2002 14:35:55 -0400 (EDT) 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 g38IRLI24985; Mon, 8 Apr 2002 11:27:21 -0700 (PDT) Message-ID: <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 11:25:45 -0700 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 Gary, I don't think the issue is having the MN re-create the context. Is is allowing the MN to recover by re-running the actions that were necessary to create the context in the first place, in the event the AR was unable to interpret it. Thus, for example, suppose that QoS context is transferred from old to new AR, but new AR for some reason can't interpret it, perhaps there is no bandwidth left or perhaps the new AR uses a different representation for QoS context. The MN would need to be informed somehow so that it could re-do its QoS signaling. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 10:54 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Apr 8 14: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 OAA02703 for ; Mon, 8 Apr 2002 14:54:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29080; Mon, 8 Apr 2002 14:43:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28975 for ; Mon, 8 Apr 2002 14:43:22 -0400 (EDT) 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 OAA02298; Mon, 8 Apr 2002 14:42:48 -0400 (EDT) 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 LAA26810; Mon, 8 Apr 2002 11:42:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38IgHD04032; Mon, 8 Apr 2002 11:42:17 -0700 X-mProtect: <200204081842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ3sGfB; Mon, 08 Apr 2002 11:42:15 PDT Message-ID: <3CB1E487.5D2B7B37@iprg.nokia.com> Date: Mon, 08 Apr 2002 11:42:16 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.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 Gary Kenward wrote: > > > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., The MN does not have to know the CT semantics. It only needs to understand a notification message that provides the error condition related to its context. > > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > Well, the MN should use whatever protocol was used that established the context in the first place, including for authentication. > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > This is a drastic idea! I think we can do better. For one thing, you still have connectivity which you could use to notify the MN so that the MN can resort to re-establishing contexts (or not). Besides, CT is a protocol, and like any other protocol has error cases and failure modes. There must be a notification message that provides protocol robustness. An example that has been brought up is where the transferred context is not useful, either partially or entirely. You would like to notify the MN when this happens. > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > And, why are these any better when CT fails compared to notifying a MN ? Seems to me that a notification message would not encumber any of the above overheads. You leave it up to the MN. -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the > newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to > primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value > in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine > the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. > This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Apr 8 14:54: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 OAA02713 for ; Mon, 8 Apr 2002 14:54:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29706 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 14:54:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29080; Mon, 8 Apr 2002 14:43:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28975 for ; Mon, 8 Apr 2002 14:43:22 -0400 (EDT) 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 OAA02298; Mon, 8 Apr 2002 14:42:48 -0400 (EDT) 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 LAA26810; Mon, 8 Apr 2002 11:42:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38IgHD04032; Mon, 8 Apr 2002 11:42:17 -0700 X-mProtect: <200204081842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ3sGfB; Mon, 08 Apr 2002 11:42:15 PDT Message-ID: <3CB1E487.5D2B7B37@iprg.nokia.com> Date: Mon, 08 Apr 2002 11:42:16 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.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 Gary Kenward wrote: > > > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., The MN does not have to know the CT semantics. It only needs to understand a notification message that provides the error condition related to its context. > > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > Well, the MN should use whatever protocol was used that established the context in the first place, including for authentication. > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > This is a drastic idea! I think we can do better. For one thing, you still have connectivity which you could use to notify the MN so that the MN can resort to re-establishing contexts (or not). Besides, CT is a protocol, and like any other protocol has error cases and failure modes. There must be a notification message that provides protocol robustness. An example that has been brought up is where the transferred context is not useful, either partially or entirely. You would like to notify the MN when this happens. > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > And, why are these any better when CT fails compared to notifying a MN ? Seems to me that a notification message would not encumber any of the above overheads. You leave it up to the MN. -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the > newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to > primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value > in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine > the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. > This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Apr 8 15:02: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 PAA02910 for ; Mon, 8 Apr 2002 15:02:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29531; Mon, 8 Apr 2002 14:50:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29432 for ; Mon, 8 Apr 2002 14:50:49 -0400 (EDT) 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 OAA02539; Mon, 8 Apr 2002 14:50:45 -0400 (EDT) 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 g38IXiI25249; Mon, 8 Apr 2002 11:33:44 -0700 (PDT) Message-ID: <02ab01c1df2b$b0512420$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E8@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 11:32:07 -0700 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 Gary, I agree about session establishment, but the fact remains that if failure of a context transfer for some reason leaves the MN without any indication that it should proceed to re-establish the feature, then the MN can't know when it should redo signaling to set up its new state. We faced this issue with BETH/FMIPv6 and the solution we found there was to have routers on the border of a fast handover coverage area inform the MN what handover algorithm was supported by routers in the other coverage area. While I think this could be done for the cases involving router configuration, such as where the next access router can't interpret the context, I am not so sure about failure due to dynamic conditions, such as that the router currently has all its Gold Class service bandwidth allocated (a QoS failure). In any event, I think there is need for some kind of signaling to indicate to the MN that context transfer has failed and that the MN needs to redo signaling to re-establish feature contexts. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 11:08 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > My main problem with the theme in this discussion is that > CT is a context transfer protocol, not a session management protocol. > In particular, when there are feature context specific issues, it is > best to handle session re-establishment/re-negotiation/maintenance using > the protocol(s) that were designed to set up the services in the first > place. CT should not be stretched into being a general signalling protocol. > > In addition, there is the perhaps greater argument that the most > effective method of correcting handover issues is not through over > the air signalling exchanges. Given the nature of the wireless link, > it will almost always be faster and always be more cost effective, to > correct any problems with signalling within the infrastructure (if it is > needed). > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 11:42 > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Madjid, > > > > The issue isn't reliability, it is whether the target AR can interpret > > the context intelligably. If not, the MN may need to recover > > by actually > > re-initializing whatever feature the context was being transfered for. > > But it cannot do this unless it knows that the CT has failed. > > > > For some feature contexts, like header compression, this > > isn't a problem > > because it will re-initialize automatically, but for AAA or QoS it > > clearly will be. > > > > jak > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 3:00 PM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify > > the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > negotiation > > > > > > > after handover would be required. > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > > > signaling) > > > > > > independent of failure/success of CT. > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > though it > > > > > may > > > > > > > be useful for finding a new wireless medium. I also see it > > > primarily > > > > > for > > > > > > > intertechnology handover, or, at best, > > interprovider handover. > > > > > > > > > > > > > > jak > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "Gary Kenward" > > > > > > > Cc: ; ; > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > establishment > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > one of the > > > > > > > > parameters that might then be fed to a selection > > algorithm. > > > Any > > > > > > > > signaling for actually establishing QoS itself > > beyond the AR > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > understand CARD > > > (and > > > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > > > protocol. The main application that you are referring to > > > > > primarily > > > > > > > > > arises out of a perceived need to determine at > > the MN the > > > best > > > > > link > > > > > > > > > layer to handover over to when inter-technology > > handovers > > > are > > > > > > > > > involved. > > > > > > > > > It can be applied to intra-technology handovers, but the > > > value > > > > > in > > > > > > > > > that situation is highly questionable (e.g. > > since it is a > > > > > discovery > > > > > > > > > protocol, the implication is that the purpose is to > > > determine > > > > > the > > > > > > > > > choice of channels available; for intra-technology > > > handovers, > > > > > there > > > > > > > > > are many, many reasons why this "choice" may not be > > > available). > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > imply NSIS > > > > > > > involvement > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > this is not > > > the > > > > > > > > > intention > > > > > > > > > (please correct me if I have this wrong John), in which > > case > > > I > > > > > think > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS > > for > > > an > > > > > > > > > existing flow after a handover, or is it > > specifically for > > > > > > > establishing > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: > > the > > > > > role > > > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and > > > > > clearly > > > > > > > > > handover is a dynamic situation that could cause the QoS > > > > > provided to > > > > > > > > > change. > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > frightening > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > transfer has > > > been > > > > > used > > > > > > > > > to > > > > > > > > > move the QoS context to the new routers (by the > > > > > requirements > > > > > > > > > for > > > > > > > > > CT this could be intra-, or inter- > > technology. Some > > > of us > > > > > > > > > believe > > > > > > > > > that for "seamless" handovers, the > > context will be > > > > > available > > > > > > > at > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > forwarded. > > > > > This > > > > > > > > > implies > > > > > > > > > that there is a relationship, probabilistic > > perhaps, > > > > > between > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision > > > > > (it > > > > > > > > > is not clear to me how this happens, but it seems > > > clear > > > > > that > > > > > > > > > for a more "seamless" handover, the MN > > should chose > > > an AR > > > > > > > that > > > > > > > > > has received the appropriate context; if > > not, then > > > what? > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > QoS because > > > of > > > > > > > changes > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > predictable > > > > > > > > > outcomes? > > > > > > > > > Or, perhaps, the question is, how do the functional > > entities > > > > > > > > > associated > > > > > > > > > with the three protocols interact before, > > during and after > > a > > > > > > > handover? > > > > > > > > > > > > > > > > > > If it the interaction is within the functional entities, > > the > > > > > > > > > respective > > > > > > > > > wg's could declare the issue out of scope, but this > > approach > > > > > does > > > > > > > not > > > > > > > > > sit well with me, for it seems to defer the > > problem to the > > > > > people > > > > > > > who > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > > > whether > > > > > > > > > > this QoS negotiation be covered by NSIS or > > Seamoby (CAR > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > and not NSIS. > > > CAR > > > > > > > > > > discovery is supposed to identify candidate access > > routers > > > > > > > > > > for handoff and QoS is an important property for > > > candidacy. > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > be concerned > > > with > > > > > the > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > negotiation, which ideally > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > concerned > > > > > > > > > > with activity > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Seamoby mailing 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 > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 15:02: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 PAA02920 for ; Mon, 8 Apr 2002 15:02:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00545 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 15:02:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29531; Mon, 8 Apr 2002 14:50:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29432 for ; Mon, 8 Apr 2002 14:50:49 -0400 (EDT) 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 OAA02539; Mon, 8 Apr 2002 14:50:45 -0400 (EDT) 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 g38IXiI25249; Mon, 8 Apr 2002 11:33:44 -0700 (PDT) Message-ID: <02ab01c1df2b$b0512420$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E8@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 11:32:07 -0700 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 Gary, I agree about session establishment, but the fact remains that if failure of a context transfer for some reason leaves the MN without any indication that it should proceed to re-establish the feature, then the MN can't know when it should redo signaling to set up its new state. We faced this issue with BETH/FMIPv6 and the solution we found there was to have routers on the border of a fast handover coverage area inform the MN what handover algorithm was supported by routers in the other coverage area. While I think this could be done for the cases involving router configuration, such as where the next access router can't interpret the context, I am not so sure about failure due to dynamic conditions, such as that the router currently has all its Gold Class service bandwidth allocated (a QoS failure). In any event, I think there is need for some kind of signaling to indicate to the MN that context transfer has failed and that the MN needs to redo signaling to re-establish feature contexts. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 11:08 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > My main problem with the theme in this discussion is that > CT is a context transfer protocol, not a session management protocol. > In particular, when there are feature context specific issues, it is > best to handle session re-establishment/re-negotiation/maintenance using > the protocol(s) that were designed to set up the services in the first > place. CT should not be stretched into being a general signalling protocol. > > In addition, there is the perhaps greater argument that the most > effective method of correcting handover issues is not through over > the air signalling exchanges. Given the nature of the wireless link, > it will almost always be faster and always be more cost effective, to > correct any problems with signalling within the infrastructure (if it is > needed). > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 11:42 > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Madjid, > > > > The issue isn't reliability, it is whether the target AR can interpret > > the context intelligably. If not, the MN may need to recover > > by actually > > re-initializing whatever feature the context was being transfered for. > > But it cannot do this unless it knows that the CT has failed. > > > > For some feature contexts, like header compression, this > > isn't a problem > > because it will re-initialize automatically, but for AAA or QoS it > > clearly will be. > > > > jak > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 3:00 PM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify > > the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > negotiation > > > > > > > after handover would be required. > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > > > signaling) > > > > > > independent of failure/success of CT. > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > though it > > > > > may > > > > > > > be useful for finding a new wireless medium. I also see it > > > primarily > > > > > for > > > > > > > intertechnology handover, or, at best, > > interprovider handover. > > > > > > > > > > > > > > jak > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "Gary Kenward" > > > > > > > Cc: ; ; > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > establishment > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > one of the > > > > > > > > parameters that might then be fed to a selection > > algorithm. > > > Any > > > > > > > > signaling for actually establishing QoS itself > > beyond the AR > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > understand CARD > > > (and > > > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > > > protocol. The main application that you are referring to > > > > > primarily > > > > > > > > > arises out of a perceived need to determine at > > the MN the > > > best > > > > > link > > > > > > > > > layer to handover over to when inter-technology > > handovers > > > are > > > > > > > > > involved. > > > > > > > > > It can be applied to intra-technology handovers, but the > > > value > > > > > in > > > > > > > > > that situation is highly questionable (e.g. > > since it is a > > > > > discovery > > > > > > > > > protocol, the implication is that the purpose is to > > > determine > > > > > the > > > > > > > > > choice of channels available; for intra-technology > > > handovers, > > > > > there > > > > > > > > > are many, many reasons why this "choice" may not be > > > available). > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > imply NSIS > > > > > > > involvement > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > this is not > > > the > > > > > > > > > intention > > > > > > > > > (please correct me if I have this wrong John), in which > > case > > > I > > > > > think > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS > > for > > > an > > > > > > > > > existing flow after a handover, or is it > > specifically for > > > > > > > establishing > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: > > the > > > > > role > > > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and > > > > > clearly > > > > > > > > > handover is a dynamic situation that could cause the QoS > > > > > provided to > > > > > > > > > change. > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > frightening > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > transfer has > > > been > > > > > used > > > > > > > > > to > > > > > > > > > move the QoS context to the new routers (by the > > > > > requirements > > > > > > > > > for > > > > > > > > > CT this could be intra-, or inter- > > technology. Some > > > of us > > > > > > > > > believe > > > > > > > > > that for "seamless" handovers, the > > context will be > > > > > available > > > > > > > at > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > forwarded. > > > > > This > > > > > > > > > implies > > > > > > > > > that there is a relationship, probabilistic > > perhaps, > > > > > between > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision > > > > > (it > > > > > > > > > is not clear to me how this happens, but it seems > > > clear > > > > > that > > > > > > > > > for a more "seamless" handover, the MN > > should chose > > > an AR > > > > > > > that > > > > > > > > > has received the appropriate context; if > > not, then > > > what? > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > QoS because > > > of > > > > > > > changes > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > predictable > > > > > > > > > outcomes? > > > > > > > > > Or, perhaps, the question is, how do the functional > > entities > > > > > > > > > associated > > > > > > > > > with the three protocols interact before, > > during and after > > a > > > > > > > handover? > > > > > > > > > > > > > > > > > > If it the interaction is within the functional entities, > > the > > > > > > > > > respective > > > > > > > > > wg's could declare the issue out of scope, but this > > approach > > > > > does > > > > > > > not > > > > > > > > > sit well with me, for it seems to defer the > > problem to the > > > > > people > > > > > > > who > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > > > whether > > > > > > > > > > this QoS negotiation be covered by NSIS or > > Seamoby (CAR > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > and not NSIS. > > > CAR > > > > > > > > > > discovery is supposed to identify candidate access > > routers > > > > > > > > > > for handoff and QoS is an important property for > > > candidacy. > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > be concerned > > > with > > > > > the > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > negotiation, which ideally > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > concerned > > > > > > > > > > with activity > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Seamoby mailing 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 > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 16:07: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 QAA04710 for ; Mon, 8 Apr 2002 16:07:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05795; Mon, 8 Apr 2002 16:01:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05732 for ; Mon, 8 Apr 2002 16:01:15 -0400 (EDT) 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 QAA04595; Mon, 8 Apr 2002 16:01:11 -0400 (EDT) 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 g38JufI28657; Mon, 8 Apr 2002 12:56:41 -0700 (PDT) Message-ID: <036801c1df37$46aa3640$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 12:55:04 -0700 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 I outlined in one of my other posts, why would you perform CT to an > AR that did not have the necessary capabilities. Is this actually about > CAR failure?? > Yes and no. Suppose the MN is expecting CT to be performed and it is not because the new AR can't interpret the context. The old AR may discover this via CAR, but if there is no way to communicate it to the MN, then the MN can't know to perform the signaling from scratch on the new AR. One could either inform the MN beforehand to do the signaling, as is done with FMIPv6/BETH, or signal the MN on the new AR. For dynamic failures, such as when the AR runs out of Gold Class service, the signaling could only be done afterwards. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 16:07: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 QAA04721 for ; Mon, 8 Apr 2002 16:07:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06376 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 16:07:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05795; Mon, 8 Apr 2002 16:01:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05732 for ; Mon, 8 Apr 2002 16:01:15 -0400 (EDT) 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 QAA04595; Mon, 8 Apr 2002 16:01:11 -0400 (EDT) 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 g38JufI28657; Mon, 8 Apr 2002 12:56:41 -0700 (PDT) Message-ID: <036801c1df37$46aa3640$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 12:55:04 -0700 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 I outlined in one of my other posts, why would you perform CT to an > AR that did not have the necessary capabilities. Is this actually about > CAR failure?? > Yes and no. Suppose the MN is expecting CT to be performed and it is not because the new AR can't interpret the context. The old AR may discover this via CAR, but if there is no way to communicate it to the MN, then the MN can't know to perform the signaling from scratch on the new AR. One could either inform the MN beforehand to do the signaling, as is done with FMIPv6/BETH, or signal the MN on the new AR. For dynamic failures, such as when the AR runs out of Gold Class service, the signaling could only be done afterwards. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 16:08: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 QAA04761 for ; Mon, 8 Apr 2002 16:08:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04404; Mon, 8 Apr 2002 15:51:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04248 for ; Mon, 8 Apr 2002 15:51:10 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04269; Mon, 8 Apr 2002 15:51:06 -0400 (EDT) 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 g38JkYt15797; Mon, 8 Apr 2002 15:46:34 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:46:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49EC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Rajeev Koodli'" , James Kempf Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 15:46:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF36.15A485BA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF36.15A485BA Content-Type: text/plain; charset="iso-8859-1" Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS > negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see > it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection > algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I > understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the > MN the best > > link > > > > > > layer to handover over to when inter-technology > handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, > but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to > determine > > the > > > > > > choice of channels available; for intra-technology > handovers, > > there > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this > is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in > which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated > new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context > transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- > technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the > handover decision > > (it > > > > > > is not clear to me how this happens, but it > seems clear > > that > > > > > > for a more "seamless" handover, the MN > should chose an AR > > > > that > > > > > > has received the appropriate context; if > not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby > as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and > not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be > concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 > ------_=_NextPart_001_01C1DF36.15A485BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Can anyone offer an explaining of how or why CT would = add significantly
to the already unreliable physics of = handover?

What failure modes for CT would be noticeable above = the unavoidable
rate of handover failures due the vagaries of = wireless coverage and
wireless link layer performance????

If CT fails, then the handover fails. It is that = simple. If CT were
to fail with every 2nd handover attempt, then there = would be a problem.
But, I cannot seriously see CT failing more then = every one in a million
handover attempts, or less.

CT should not be attempted if there is an = incompatibility between source
and destination ARs. And, I HAD thought that it was = the purpose of CAR
to identify those incompatibilities and thus avoid = doing CT when it is
clear it would fail. How to mitigate those = incompatibles is not a
CT issue, it is a service adaptation issue, which = can be resolved in
a number of ways, some of which would imply = signalled negotiation either
between the ARs or between the ARs and the MN. =

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, = which by the way
> neither CT requirements, nor nsis requirements = are covering, has to
> do with failure in QoS negotiation. I don't = think you can count
> the case, where the QoS information that CT has = given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]<= /FONT>
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; = nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of = how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or = not?
> >
>
> This notification should be covered by = CT.  We should offer
> seamless handover to NSIS :-) Seriously, this = concerns
> robustness of CT protocol.
>
> -Rajeev
>
>
> >
> = >           &n= bsp; jak
> >
> > ----- Original Message -----
> > From: "Rajeev Koodli" = <rajeev@iprg.nokia.com>
> > To: "James Kempf" = <kempf@docomolabs-usa.com>
> > Cc: "Gary Kenward" = <gkenward@nortelnetworks.com>;
> > <Hemant.Chaskar@nokia.com>; = <nsis@ietf.org>; <seamoby@ietf.org>
> > Sent: Friday, April 05, 2002 9:19 = AM
> > Subject: Re: [Seamoby] RE: [NSIS] = Establishing QoS after handoff.
> >
> > >
> > > Hello Jim,
> > >
> > > James Kempf wrote:
> > >
> > > > There is an issue if CT fails. = In that case, some kind of
> > negotiation
> > > > after handover would be = required.
> > > >
> > > > So, I'd say that some indication = of CT failure is needed.
> > > >
> > >
> > > Yes, but this is between AR and MN. = If CT fails, the AR should
> > > notify the MN to engage in context = re-creation.
> > >
> > > My point was specific to signaling = _beyond_ AR (i.e., upstream
> > signaling)
> > > independent of failure/success of = CT.
> > >
> > > Hope this is clearer..
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > As for CAR, I don't see the = relevance for QoS
> negotiation, though it
> > may
> > > > be useful for finding a new = wireless medium. I also see
> it primarily
> > for
> > > > intertechnology handover, or, at = best, interprovider handover.
> > > >
> > > = >           &n= bsp; jak
> > > > ----- Original Message = -----
> > > > From: "Rajeev Koodli" = <rajeev@iprg.nokia.com>
> > > > To: "Gary Kenward" = <gkenward@nortelnetworks.com>
> > > > Cc: = <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>;
> <seamoby@ietf.org>
> > > > Sent: Friday, April 05, 2002 = 9:01 AM
> > > > Subject: Re: [Seamoby] RE: = [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > well, if the issue is QoS = establishment after handover,
> > > > >
> > > > > - CT is applicable for = establishing QoS state at the AR
> > > > > - if further signaling is = desired beyond the AR, NSIS may
> > > > >     = consider it. I don't see how _signaling_ for QoS
> establishment
> > > > >     = beyond AR is relevant for seamoby.
> > > > >
> > > > > CAR _discovery_ could = exchange QoS capability as one of the
> > > > > parameters that might then = be fed to a selection
> algorithm. Any
> > > > > signaling for actually = establishing QoS itself beyond the AR
> > > > > should be outside the scope = of seamoby..
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > Gary Kenward wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hemant:
> > > > > >
> > > > > >   Just a = point of clarification, but as I
> understand CARD (and
> > > > > > I don't understand it = well), it is not a QoS negotiation
> > > > > > protocol. The main = application that you are referring to
> > primarily
> > > > > > arises out of a = perceived need to determine at the
> MN the best
> > link
> > > > > > layer to handover over = to when inter-technology
> handovers are
> > > > > > involved.
> > > > > > It can be applied to = intra-technology handovers,
> but the value
> > in
> > > > > > that situation is = highly questionable (e.g. since it is a
> > discovery
> > > > > > protocol, the = implication is that the purpose is to
> determine
> > the
> > > > > > choice of channels = available; for intra-technology
> handovers,
> > there
> > > > > > are many, many reasons = why this "choice" may not be
> available).
> > > > > >
> > > > > >   There is a = requirement, 5.1.2, which seems to imply NSIS
> > > > involvement
> > > > > >
> > > > > > during/after a = handover. John has stated that this
> is not the
> > > > > > intention
> > > > > > (please correct me if = I have this wrong John), in
> which case I
> > think
> > > > > > 5.1.2 needs to be = clarified.
> > > > > >
> > > > > >   = Specifically, is NSIS to be used to negotiated
> new QoS for an
> > > > > > existing flow after a = handover, or is it specifically for
> > > > establishing
> > > > > >
> > > > > > QoS for a new flow? I = don't think the answer is boolean: the
> > role
> > > > > > of NSIS in QoS = re-negotiation is still open, I believe, and
> > clearly
> > > > > > handover is a dynamic = situation that could cause the QoS
> > provided to
> > > > > > change.
> > > > > >
> > > > > >   I have = been told there is no issue, but here's a
> frightening
> > > > > > scenario:
> > > > > >
> > > > > = >         - a handover takes = place, and context
> transfer has been
> > used
> > > > > > to
> > > > > = >        move the QoS context to = the new routers (by the
> > requirements
> > > > > > for
> > > > > = >        CT this could be intra-, = or inter-
> technology. Some of us
> > > > > > believe
> > > > > = >        that for = "seamless" handovers, the context will be
> > available
> > > > at
> > > > > >
> > > > > = >        routers before the first = packets need to be
> forwarded.
> > This
> > > > > > implies
> > > > > = >        that there is a = relationship, probabilistic perhaps,
> > between
> > > > > = >        the handover process and = the target ARs for CT.
> > > > > >
> > > > > = >      - CARD is used by the MN to = influence the
> handover decision
> > (it
> > > > > = >        is not clear to me how = this happens, but it
> seems clear
> > that
> > > > > = >        for a more = "seamless" handover, the MN
> should chose an AR
> > > > that
> > > > > = >        has received the = appropriate context; if
> not, then what?
> > > > > >
> > > > > = >      - NSIS kicks in and starts = re-negotiating QoS
> because of
> > > > changes
> > > > > = >        introduced by the = handover;
> > > > > >
> > > > > >   How do = these three protocols interact to produce
> predictable
> > > > > > outcomes?
> > > > > > Or, perhaps, the = question is, how do the functional entities
> > > > > > associated
> > > > > > with the three = protocols interact before, during and after a
> > > > handover?
> > > > > >
> > > > > > If it the interaction = is within the functional entities, the
> > > > > > respective
> > > > > > wg's could declare the = issue out of scope, but this approach
> > does
> > > > not
> > > > > > sit well with me, for = it seems to defer the problem to the
> > people
> > > > who
> > > > > > have to implement this = "stuff".
> > > > > >
> > > > > >   Am I = imagining things?
> > > > > >
> > > > > > Cheers,
> > > > > > Gary
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: = Hemant.Chaskar@nokia.com
> > [mailto:Hemant.Chaskar@nokia.com= ]
> > > > > > > Sent: April 4, = 2002 22:33
> > > > > > > To: = nsis@ietf.org
> > > > > > > Subject: RE: = [NSIS] Establishing QoS after handoff.
> > > > > > >
> > > > > > >
> > > > > > > Hi Sharif:
> > > > > > >
> > > > > > > There is = currently a debate going on in Seamoby
> as to whether
> > > > > > > this QoS = negotiation be covered by NSIS or Seamoby (CAR
> > > > > > > discovery = protocol).
> > > > > > >
> > > > > > > IMHO it should be = covered by CAR discovery and
> not NSIS. CAR
> > > > > > > discovery is = supposed to identify candidate access routers
> > > > > > > for handoff and = QoS is an important property for
> candidacy.
> > > > > > >
> > > > > > > Br,
> > > > > > > Hemant
> > > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: ext = Shahrier, Sharif M.
> > > > > > > [mailto:Sharif.Shahrier@= InterDigital.com]
> > > > > > > Sent: Thursday, = April 04, 2002 3:35 PM
> > > > > > > To: Shahrier, = Sharif M.
> > > > > > > Cc: = 'nsis@ietf.org'
> > > > > > > Subject: [NSIS] = Establishing QoS after handoff.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I have a question = for clarification.
> > > > > > >
> > > > > > > I think it was = stated that NSIS should only be
> concerned with
> > the
> > > > > > > establishment of = QoS after handoff.
> > > > > > >
> > > > > > > This is = inconvienent with respect to IP-level QoS
> > > > > > > negotiation, = which ideally
> > > > > > > should be done = before handoff has taken place.
> > > > > > >
> > > > > > > QoS negotiation = is in the current requirements draft.
> > > > > > >
> > > > > > > So, NSIS = signaling protocol development should be
> concerned
> > > > > > > with = activity
> > > > > > > before handoff = occurs.
> > > > > > >
> > > > > > > Sharif.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > = _______________________________________________
> > > > > > > nsis mailing = list
> > > > > > > = nsis@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/nsis=
> > > > > > >
> > > > > > > = _______________________________________________
> > > > > > > nsis mailing = list
> > > > > > > = nsis@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/nsis=
> > > > > > >
> > > > >
> > > > >
> > > > > = _______________________________________________
> > > > > Seamoby mailing 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
>

------_=_NextPart_001_01C1DF36.15A485BA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 16:08: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 QAA04773 for ; Mon, 8 Apr 2002 16:08:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06512 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 16:08:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04404; Mon, 8 Apr 2002 15:51:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04248 for ; Mon, 8 Apr 2002 15:51:10 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04269; Mon, 8 Apr 2002 15:51:06 -0400 (EDT) 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 g38JkYt15797; Mon, 8 Apr 2002 15:46:34 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:46:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49EC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Rajeev Koodli'" , James Kempf Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 15:46:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF36.15A485BA" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF36.15A485BA Content-Type: text/plain; charset="iso-8859-1" Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS > negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see > it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection > algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I > understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the > MN the best > > link > > > > > > layer to handover over to when inter-technology > handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, > but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to > determine > > the > > > > > > choice of channels available; for intra-technology > handovers, > > there > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this > is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in > which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated > new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context > transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- > technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the > handover decision > > (it > > > > > > is not clear to me how this happens, but it > seems clear > > that > > > > > > for a more "seamless" handover, the MN > should chose an AR > > > > that > > > > > > has received the appropriate context; if > not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby > as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and > not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be > concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 > ------_=_NextPart_001_01C1DF36.15A485BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Can anyone offer an explaining of how or why CT would = add significantly
to the already unreliable physics of = handover?

What failure modes for CT would be noticeable above = the unavoidable
rate of handover failures due the vagaries of = wireless coverage and
wireless link layer performance????

If CT fails, then the handover fails. It is that = simple. If CT were
to fail with every 2nd handover attempt, then there = would be a problem.
But, I cannot seriously see CT failing more then = every one in a million
handover attempts, or less.

CT should not be attempted if there is an = incompatibility between source
and destination ARs. And, I HAD thought that it was = the purpose of CAR
to identify those incompatibilities and thus avoid = doing CT when it is
clear it would fail. How to mitigate those = incompatibles is not a
CT issue, it is a service adaptation issue, which = can be resolved in
a number of ways, some of which would imply = signalled negotiation either
between the ARs or between the ARs and the MN. =

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, = which by the way
> neither CT requirements, nor nsis requirements = are covering, has to
> do with failure in QoS negotiation. I don't = think you can count
> the case, where the QoS information that CT has = given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]<= /FONT>
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; = nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of = how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or = not?
> >
>
> This notification should be covered by = CT.  We should offer
> seamless handover to NSIS :-) Seriously, this = concerns
> robustness of CT protocol.
>
> -Rajeev
>
>
> >
> = >           &n= bsp; jak
> >
> > ----- Original Message -----
> > From: "Rajeev Koodli" = <rajeev@iprg.nokia.com>
> > To: "James Kempf" = <kempf@docomolabs-usa.com>
> > Cc: "Gary Kenward" = <gkenward@nortelnetworks.com>;
> > <Hemant.Chaskar@nokia.com>; = <nsis@ietf.org>; <seamoby@ietf.org>
> > Sent: Friday, April 05, 2002 9:19 = AM
> > Subject: Re: [Seamoby] RE: [NSIS] = Establishing QoS after handoff.
> >
> > >
> > > Hello Jim,
> > >
> > > James Kempf wrote:
> > >
> > > > There is an issue if CT fails. = In that case, some kind of
> > negotiation
> > > > after handover would be = required.
> > > >
> > > > So, I'd say that some indication = of CT failure is needed.
> > > >
> > >
> > > Yes, but this is between AR and MN. = If CT fails, the AR should
> > > notify the MN to engage in context = re-creation.
> > >
> > > My point was specific to signaling = _beyond_ AR (i.e., upstream
> > signaling)
> > > independent of failure/success of = CT.
> > >
> > > Hope this is clearer..
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > As for CAR, I don't see the = relevance for QoS
> negotiation, though it
> > may
> > > > be useful for finding a new = wireless medium. I also see
> it primarily
> > for
> > > > intertechnology handover, or, at = best, interprovider handover.
> > > >
> > > = >           &n= bsp; jak
> > > > ----- Original Message = -----
> > > > From: "Rajeev Koodli" = <rajeev@iprg.nokia.com>
> > > > To: "Gary Kenward" = <gkenward@nortelnetworks.com>
> > > > Cc: = <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>;
> <seamoby@ietf.org>
> > > > Sent: Friday, April 05, 2002 = 9:01 AM
> > > > Subject: Re: [Seamoby] RE: = [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > well, if the issue is QoS = establishment after handover,
> > > > >
> > > > > - CT is applicable for = establishing QoS state at the AR
> > > > > - if further signaling is = desired beyond the AR, NSIS may
> > > > >     = consider it. I don't see how _signaling_ for QoS
> establishment
> > > > >     = beyond AR is relevant for seamoby.
> > > > >
> > > > > CAR _discovery_ could = exchange QoS capability as one of the
> > > > > parameters that might then = be fed to a selection
> algorithm. Any
> > > > > signaling for actually = establishing QoS itself beyond the AR
> > > > > should be outside the scope = of seamoby..
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > Gary Kenward wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hemant:
> > > > > >
> > > > > >   Just a = point of clarification, but as I
> understand CARD (and
> > > > > > I don't understand it = well), it is not a QoS negotiation
> > > > > > protocol. The main = application that you are referring to
> > primarily
> > > > > > arises out of a = perceived need to determine at the
> MN the best
> > link
> > > > > > layer to handover over = to when inter-technology
> handovers are
> > > > > > involved.
> > > > > > It can be applied to = intra-technology handovers,
> but the value
> > in
> > > > > > that situation is = highly questionable (e.g. since it is a
> > discovery
> > > > > > protocol, the = implication is that the purpose is to
> determine
> > the
> > > > > > choice of channels = available; for intra-technology
> handovers,
> > there
> > > > > > are many, many reasons = why this "choice" may not be
> available).
> > > > > >
> > > > > >   There is a = requirement, 5.1.2, which seems to imply NSIS
> > > > involvement
> > > > > >
> > > > > > during/after a = handover. John has stated that this
> is not the
> > > > > > intention
> > > > > > (please correct me if = I have this wrong John), in
> which case I
> > think
> > > > > > 5.1.2 needs to be = clarified.
> > > > > >
> > > > > >   = Specifically, is NSIS to be used to negotiated
> new QoS for an
> > > > > > existing flow after a = handover, or is it specifically for
> > > > establishing
> > > > > >
> > > > > > QoS for a new flow? I = don't think the answer is boolean: the
> > role
> > > > > > of NSIS in QoS = re-negotiation is still open, I believe, and
> > clearly
> > > > > > handover is a dynamic = situation that could cause the QoS
> > provided to
> > > > > > change.
> > > > > >
> > > > > >   I have = been told there is no issue, but here's a
> frightening
> > > > > > scenario:
> > > > > >
> > > > > = >         - a handover takes = place, and context
> transfer has been
> > used
> > > > > > to
> > > > > = >        move the QoS context to = the new routers (by the
> > requirements
> > > > > > for
> > > > > = >        CT this could be intra-, = or inter-
> technology. Some of us
> > > > > > believe
> > > > > = >        that for = "seamless" handovers, the context will be
> > available
> > > > at
> > > > > >
> > > > > = >        routers before the first = packets need to be
> forwarded.
> > This
> > > > > > implies
> > > > > = >        that there is a = relationship, probabilistic perhaps,
> > between
> > > > > = >        the handover process and = the target ARs for CT.
> > > > > >
> > > > > = >      - CARD is used by the MN to = influence the
> handover decision
> > (it
> > > > > = >        is not clear to me how = this happens, but it
> seems clear
> > that
> > > > > = >        for a more = "seamless" handover, the MN
> should chose an AR
> > > > that
> > > > > = >        has received the = appropriate context; if
> not, then what?
> > > > > >
> > > > > = >      - NSIS kicks in and starts = re-negotiating QoS
> because of
> > > > changes
> > > > > = >        introduced by the = handover;
> > > > > >
> > > > > >   How do = these three protocols interact to produce
> predictable
> > > > > > outcomes?
> > > > > > Or, perhaps, the = question is, how do the functional entities
> > > > > > associated
> > > > > > with the three = protocols interact before, during and after a
> > > > handover?
> > > > > >
> > > > > > If it the interaction = is within the functional entities, the
> > > > > > respective
> > > > > > wg's could declare the = issue out of scope, but this approach
> > does
> > > > not
> > > > > > sit well with me, for = it seems to defer the problem to the
> > people
> > > > who
> > > > > > have to implement this = "stuff".
> > > > > >
> > > > > >   Am I = imagining things?
> > > > > >
> > > > > > Cheers,
> > > > > > Gary
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: = Hemant.Chaskar@nokia.com
> > [mailto:Hemant.Chaskar@nokia.com= ]
> > > > > > > Sent: April 4, = 2002 22:33
> > > > > > > To: = nsis@ietf.org
> > > > > > > Subject: RE: = [NSIS] Establishing QoS after handoff.
> > > > > > >
> > > > > > >
> > > > > > > Hi Sharif:
> > > > > > >
> > > > > > > There is = currently a debate going on in Seamoby
> as to whether
> > > > > > > this QoS = negotiation be covered by NSIS or Seamoby (CAR
> > > > > > > discovery = protocol).
> > > > > > >
> > > > > > > IMHO it should be = covered by CAR discovery and
> not NSIS. CAR
> > > > > > > discovery is = supposed to identify candidate access routers
> > > > > > > for handoff and = QoS is an important property for
> candidacy.
> > > > > > >
> > > > > > > Br,
> > > > > > > Hemant
> > > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: ext = Shahrier, Sharif M.
> > > > > > > [mailto:Sharif.Shahrier@= InterDigital.com]
> > > > > > > Sent: Thursday, = April 04, 2002 3:35 PM
> > > > > > > To: Shahrier, = Sharif M.
> > > > > > > Cc: = 'nsis@ietf.org'
> > > > > > > Subject: [NSIS] = Establishing QoS after handoff.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I have a question = for clarification.
> > > > > > >
> > > > > > > I think it was = stated that NSIS should only be
> concerned with
> > the
> > > > > > > establishment of = QoS after handoff.
> > > > > > >
> > > > > > > This is = inconvienent with respect to IP-level QoS
> > > > > > > negotiation, = which ideally
> > > > > > > should be done = before handoff has taken place.
> > > > > > >
> > > > > > > QoS negotiation = is in the current requirements draft.
> > > > > > >
> > > > > > > So, NSIS = signaling protocol development should be
> concerned
> > > > > > > with = activity
> > > > > > > before handoff = occurs.
> > > > > > >
> > > > > > > Sharif.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > = _______________________________________________
> > > > > > > nsis mailing = list
> > > > > > > = nsis@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/nsis=
> > > > > > >
> > > > > > > = _______________________________________________
> > > > > > > nsis mailing = list
> > > > > > > = nsis@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/nsis=
> > > > > > >
> > > > >
> > > > >
> > > > > = _______________________________________________
> > > > > Seamoby mailing 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
>

------_=_NextPart_001_01C1DF36.15A485BA-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 16:08: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 QAA04786 for ; Mon, 8 Apr 2002 16:08:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04788; Mon, 8 Apr 2002 15:54:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04659 for ; Mon, 8 Apr 2002 15:53:53 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04360; Mon, 8 Apr 2002 15:53:48 -0400 (EDT) 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 g38JnGt15942; Mon, 8 Apr 2002 15:49:16 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:49:16 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 15:49:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF36.311DDED6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF36.311DDED6 Content-Type: text/plain; charset="iso-8859-1" "Re-create" was Rajeev's term, not mine. I think that it is an appropriate term if one considers other mechanisms besides session setup signalling. Either way, it is not a CT function. As I outlined in one of my other posts, why would you perform CT to an AR that did not have the necessary capabilities. Is this actually about CAR failure?? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 14:26 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > I don't think the issue is having the MN re-create the context. Is is > allowing the MN to recover by re-running the actions that > were necessary > to create the context in the first place, in the event the AR > was unable > to interpret it. > Thus, for example, suppose that QoS context is transferred from old to > new AR, but new AR for some reason can't interpret it, > perhaps there is > no bandwidth left or perhaps the new AR uses a different > representation > for QoS context. The MN would need to be informed somehow so that it > could re-do its QoS signaling. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'Rajeev Koodli'" ; "Nakhjiri > Madjid-MNAKHJI1" > Cc: ; ; > Sent: Monday, April 08, 2002 10:54 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Rajeev: > > > > In order for the MN to "recreate the context", the MN would > > have to understand the semantics of Context transfer, etc., > > and, more important, there would have to be a protocol or > > protocols that would allow the MN to recreate contexts at an AR. > > I doubt that the latter is going to happen (e.g. authentication). > > > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > There may be mitigating actions that could be taken to re-establish > > certain sessions. But these decisions are must be driven by > the policy > > of the network administration (explicit or implicity), and comply > > with the security, resource management and accounting requirements > > for the network. Hopefully, none of these mitigating > actions requires > > more over-the-air signalling. > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: April 5, 2002 17:46 > > > To: Nakhjiri Madjid-MNAKHJI1 > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hello Madjid, > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > Hello Rajeev, > > > > > > > > I agreed with everything you say below, except one thing: > > > > CT can only transfer whatever QoS state that is usable at the > newAR. > > > > If the new network is using a different QoS technology with > > > different > > > > QoS parameters, then I am not sure if CT by itself can do > > > the job, unless > > > > you add your own mapping functionality. > > > > > > > > > > This would be an example where the new AR sends a > > > notification to the MN so that the MN can take > > > appropriate action (for instance, attempt to > > > re-create the context). > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > BR, > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > To: Gary Kenward > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the > > > best link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology > > > handovers, there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > NSIS involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which > > > case I think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > and clearly > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer > > > has been used > > > > > to > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > > > available at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic > > > perhaps, between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision (it > > > > > is not clear to me how this happens, but it seems > > > clear that > > > > > for a more "seamless" handover, the MN should > > > chose an AR that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > because of changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and > > > after a handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this > > > approach does not > > > > > sit well with me, for it seems to defer the problem to > > > the people who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > > > concerned with the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > ------_=_NextPart_001_01C1DF36.311DDED6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

"Re-create" was Rajeev's term, not mine. I think that it is an appropriate
term if one considers other mechanisms besides session setup signalling.
Either way, it is not a CT function.

As I outlined in one of my other posts, why would you perform CT to an
AR that did not have the necessary capabilities. Is this actually about
CAR failure??

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 14:26
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> I don't think the issue is having the MN re-create the context. Is is
> allowing the MN to recover by re-running the actions that
> were necessary
> to create the context in the first place, in the event the AR
> was unable
> to interpret it.
> Thus, for example, suppose that QoS context is transferred from old to
> new AR, but new AR for some reason can't interpret it,
> perhaps there is
> no bandwidth left or perhaps the new AR uses a different
> representation
> for QoS context. The MN would need to be informed somehow so that it
> could re-do its QoS signaling.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'Rajeev Koodli'" <rajeev@iprg.nokia.com>; "Nakhjiri
> Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Monday, April 08, 2002 10:54 AM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > have to understand the semantics of Context transfer, etc.,
> > and, more important, there would have to be a protocol or
> > protocols that would allow the MN to recreate contexts at an AR.
> > I doubt that the latter is going to happen (e.g. authentication).
> >
> > IF and when a CT fails, the easiest way to "recreate" context
> > is for the sessions to be dropped. This may seem drastic,
> > but in reality, what is going to cause CT to fail and
> > how often will this happen?
> >
> > There may be mitigating actions that could be taken to re-establish
> > certain sessions. But these decisions are must be driven by
> the policy
> > of the network administration (explicit or implicity), and comply
> > with the security, resource management and accounting requirements
> > for the network. Hopefully, none of these mitigating
> actions requires
> > more over-the-air signalling.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > Sent: April 5, 2002 17:46
> > > To: Nakhjiri Madjid-MNAKHJI1
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > Hello Madjid,
> > >
> > > Nakhjiri Madjid-MNAKHJI1 wrote:
> > >
> > > > Hello Rajeev,
> > > >
> > > > I agreed with everything you say below, except one thing:
> > > > CT can only transfer whatever QoS state that is usable at the
> newAR.
> > > > If the new network is using a different QoS technology with
> > > different
> > > > QoS parameters, then I am not sure if CT by itself can do
> > > the job, unless
> > > > you add your own mapping functionality.
> > > >
> > >
> > > This would be an example where the new AR sends a
> > > notification to the MN so that the MN can take
> > > appropriate action (for instance, attempt to
> > > re-create the context).
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR,
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > > Sent: Friday, April 05, 2002 11:01 AM
> > > > To: Gary Kenward
> > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> primarily
> > > > > arises out of a perceived need to determine at the MN the
> > > best link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> in
> > > > > that situation is highly questionable (e.g. since it is a
> > > discovery
> > > > > protocol, the implication is that the purpose is to determine
> the
> > > > > choice of channels available; for intra-technology
> > > handovers, there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply
> > > NSIS involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which
> > > case I think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> role
> > > > > of NSIS in QoS re-negotiation is still open, I believe,
> > > and clearly
> > > > > handover is a dynamic situation that could cause the QoS
> > > provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context transfer
> > > has been used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> > > requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> > > available at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> This
> > > > > implies
> > > > >        that there is a relationship, probabilistic
> > > perhaps, between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the handover
> > > decision (it
> > > > >        is not clear to me how this happens, but it seems
> > > clear that
> > > > >        for a more "seamless" handover, the MN should
> > > chose an AR that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS
> > > because of changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and
> > > after a handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this
> > > approach does not
> > > > > sit well with me, for it seems to defer the problem to
> > > the people who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> > > concerned with the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
> >
>
>

------_=_NextPart_001_01C1DF36.311DDED6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 16:08: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 QAA04802 for ; Mon, 8 Apr 2002 16:08:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06526 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 16:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04788; Mon, 8 Apr 2002 15:54:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04659 for ; Mon, 8 Apr 2002 15:53:53 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04360; Mon, 8 Apr 2002 15:53:48 -0400 (EDT) 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 g38JnGt15942; Mon, 8 Apr 2002 15:49:16 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:49:16 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 15:49:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF36.311DDED6" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF36.311DDED6 Content-Type: text/plain; charset="iso-8859-1" "Re-create" was Rajeev's term, not mine. I think that it is an appropriate term if one considers other mechanisms besides session setup signalling. Either way, it is not a CT function. As I outlined in one of my other posts, why would you perform CT to an AR that did not have the necessary capabilities. Is this actually about CAR failure?? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 14:26 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > I don't think the issue is having the MN re-create the context. Is is > allowing the MN to recover by re-running the actions that > were necessary > to create the context in the first place, in the event the AR > was unable > to interpret it. > Thus, for example, suppose that QoS context is transferred from old to > new AR, but new AR for some reason can't interpret it, > perhaps there is > no bandwidth left or perhaps the new AR uses a different > representation > for QoS context. The MN would need to be informed somehow so that it > could re-do its QoS signaling. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'Rajeev Koodli'" ; "Nakhjiri > Madjid-MNAKHJI1" > Cc: ; ; > Sent: Monday, April 08, 2002 10:54 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Rajeev: > > > > In order for the MN to "recreate the context", the MN would > > have to understand the semantics of Context transfer, etc., > > and, more important, there would have to be a protocol or > > protocols that would allow the MN to recreate contexts at an AR. > > I doubt that the latter is going to happen (e.g. authentication). > > > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > There may be mitigating actions that could be taken to re-establish > > certain sessions. But these decisions are must be driven by > the policy > > of the network administration (explicit or implicity), and comply > > with the security, resource management and accounting requirements > > for the network. Hopefully, none of these mitigating > actions requires > > more over-the-air signalling. > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: April 5, 2002 17:46 > > > To: Nakhjiri Madjid-MNAKHJI1 > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hello Madjid, > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > Hello Rajeev, > > > > > > > > I agreed with everything you say below, except one thing: > > > > CT can only transfer whatever QoS state that is usable at the > newAR. > > > > If the new network is using a different QoS technology with > > > different > > > > QoS parameters, then I am not sure if CT by itself can do > > > the job, unless > > > > you add your own mapping functionality. > > > > > > > > > > This would be an example where the new AR sends a > > > notification to the MN so that the MN can take > > > appropriate action (for instance, attempt to > > > re-create the context). > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > BR, > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > To: Gary Kenward > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the > > > best link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology > > > handovers, there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > NSIS involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which > > > case I think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > and clearly > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer > > > has been used > > > > > to > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > > > available at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic > > > perhaps, between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision (it > > > > > is not clear to me how this happens, but it seems > > > clear that > > > > > for a more "seamless" handover, the MN should > > > chose an AR that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > because of changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and > > > after a handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this > > > approach does not > > > > > sit well with me, for it seems to defer the problem to > > > the people who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > > > concerned with the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > ------_=_NextPart_001_01C1DF36.311DDED6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

"Re-create" was Rajeev's term, not mine. I think that it is an appropriate
term if one considers other mechanisms besides session setup signalling.
Either way, it is not a CT function.

As I outlined in one of my other posts, why would you perform CT to an
AR that did not have the necessary capabilities. Is this actually about
CAR failure??

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 14:26
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> I don't think the issue is having the MN re-create the context. Is is
> allowing the MN to recover by re-running the actions that
> were necessary
> to create the context in the first place, in the event the AR
> was unable
> to interpret it.
> Thus, for example, suppose that QoS context is transferred from old to
> new AR, but new AR for some reason can't interpret it,
> perhaps there is
> no bandwidth left or perhaps the new AR uses a different
> representation
> for QoS context. The MN would need to be informed somehow so that it
> could re-do its QoS signaling.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'Rajeev Koodli'" <rajeev@iprg.nokia.com>; "Nakhjiri
> Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Monday, April 08, 2002 10:54 AM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > have to understand the semantics of Context transfer, etc.,
> > and, more important, there would have to be a protocol or
> > protocols that would allow the MN to recreate contexts at an AR.
> > I doubt that the latter is going to happen (e.g. authentication).
> >
> > IF and when a CT fails, the easiest way to "recreate" context
> > is for the sessions to be dropped. This may seem drastic,
> > but in reality, what is going to cause CT to fail and
> > how often will this happen?
> >
> > There may be mitigating actions that could be taken to re-establish
> > certain sessions. But these decisions are must be driven by
> the policy
> > of the network administration (explicit or implicity), and comply
> > with the security, resource management and accounting requirements
> > for the network. Hopefully, none of these mitigating
> actions requires
> > more over-the-air signalling.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > Sent: April 5, 2002 17:46
> > > To: Nakhjiri Madjid-MNAKHJI1
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > Hello Madjid,
> > >
> > > Nakhjiri Madjid-MNAKHJI1 wrote:
> > >
> > > > Hello Rajeev,
> > > >
> > > > I agreed with everything you say below, except one thing:
> > > > CT can only transfer whatever QoS state that is usable at the
> newAR.
> > > > If the new network is using a different QoS technology with
> > > different
> > > > QoS parameters, then I am not sure if CT by itself can do
> > > the job, unless
> > > > you add your own mapping functionality.
> > > >
> > >
> > > This would be an example where the new AR sends a
> > > notification to the MN so that the MN can take
> > > appropriate action (for instance, attempt to
> > > re-create the context).
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR,
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > > Sent: Friday, April 05, 2002 11:01 AM
> > > > To: Gary Kenward
> > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> primarily
> > > > > arises out of a perceived need to determine at the MN the
> > > best link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> in
> > > > > that situation is highly questionable (e.g. since it is a
> > > discovery
> > > > > protocol, the implication is that the purpose is to determine
> the
> > > > > choice of channels available; for intra-technology
> > > handovers, there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply
> > > NSIS involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which
> > > case I think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> role
> > > > > of NSIS in QoS re-negotiation is still open, I believe,
> > > and clearly
> > > > > handover is a dynamic situation that could cause the QoS
> > > provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context transfer
> > > has been used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> > > requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> > > available at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> This
> > > > > implies
> > > > >        that there is a relationship, probabilistic
> > > perhaps, between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the handover
> > > decision (it
> > > > >        is not clear to me how this happens, but it seems
> > > clear that
> > > > >        for a more "seamless" handover, the MN should
> > > chose an AR that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS
> > > because of changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and
> > > after a handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this
> > > approach does not
> > > > > sit well with me, for it seems to defer the problem to
> > > the people who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> > > concerned with the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
> >
>
>

------_=_NextPart_001_01C1DF36.311DDED6-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 16:24: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 QAA05209 for ; Mon, 8 Apr 2002 16:24:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07031; Mon, 8 Apr 2002 16:13:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06898 for ; Mon, 8 Apr 2002 16:13:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941; Mon, 8 Apr 2002 16:13:34 -0400 (EDT) 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 g38K8ji09475; Mon, 8 Apr 2002 16:08:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:08:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49EF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:08:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF39.2E13BD20" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF39.2E13BD20 Content-Type: text/plain; charset="iso-8859-1" Rajeev: A user starts up an application that requests a "gold service". The protocol stack (perhaps an NSIS protocol stack) sends in a request from MN to AN for gold service". A handover occurs, and (according to your scenario), the QoS context transfer fails (for some inexplicable reason). Some entity (the CT protocol stack according to your proposal) sends an indication to the MN that the QoS context transfer has failed (according to your proposal). How does the MN know what to do with this notice? The MN has to understand: - what a handover is at the IP level - what an IP context transfer is - that QoS context is (sometimes) transferred separately from other context - what the nature of the failure was, and thus, what action to take. - how and with what entity to initiate QoS re-negotiation. The knowledge for all of the above is either explicitly or implicitly built into the MN. If the intent were for the MN to receive back a message that indicating "Gold service not available" then this is simply a session disconnect. If the intent is for the MN to be told that "the QoS associated with Gold service" has failed, then the MN has to know that Gold service is actually a combination of features (AAA, security, HC), and to initiate negotiation, it has to be able to talk to the individual network entities - entities which may not even exist within a given network (e.g. a provision model). So, how is the MN ignorant of CT? Service models? Keep in mind, according to the CT requirements, CT does not know what is contained in the data chunks it transports. Thus, at best, it can only forward to the MN that data chunk or another, opaque data chunk. Even this capability is a major modification to what should be a simple state machine for the CT protocol. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 8, 2002 14:42 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Nakhjiri Madjid-MNAKHJI1; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary Kenward wrote: > > > > > > > Rajeev: > > > > In order for the MN to "recreate the context", the MN would > > have to understand the semantics of Context transfer, etc., > > The MN does not have to know the CT semantics. > It only needs to understand a notification message > that provides the error condition related to its > context. > > > > > and, more important, there would have to be a protocol or > > protocols that would allow the MN to recreate contexts at an AR. > > I doubt that the latter is going to happen (e.g. authentication). > > > > Well, the MN should use whatever protocol was > used that established the context in the first place, > including for authentication. > > > > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > This is a drastic idea! I think we can do better. > For one thing, you still have connectivity which > you could use to notify the MN so that the MN > can resort to re-establishing contexts (or not). Besides, > CT is a protocol, and like any other protocol has > error cases and failure modes. There must be a > notification message that provides protocol > robustness. > An example that has been brought up is where > the transferred context is not useful, either > partially or entirely. You would like to notify > the MN when this happens. > > > > > > There may be mitigating actions that could be taken to re-establish > > certain sessions. But these decisions are must be driven by > the policy > > > > of the network administration (explicit or implicity), and comply > > with the security, resource management and accounting requirements > > for the network. Hopefully, none of these mitigating > actions requires > > more over-the-air signalling. > > > > And, why are these any better when CT fails compared > to notifying a MN ? Seems to me that a notification message > would not encumber any of the above overheads. You > leave it up to the MN. > > -Rajeev > > > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: April 5, 2002 17:46 > > > To: Nakhjiri Madjid-MNAKHJI1 > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hello Madjid, > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > Hello Rajeev, > > > > > > > > I agreed with everything you say below, except one thing: > > > > CT can only transfer whatever QoS state that is usable at the > > newAR. > > > > If the new network is using a different QoS technology with > > > different > > > > QoS parameters, then I am not sure if CT by itself can do > > > the job, unless > > > > you add your own mapping functionality. > > > > > > > > > > This would be an example where the new AR sends a > > > notification to the MN so that the MN can take > > > appropriate action (for instance, attempt to > > > re-create the context). > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > BR, > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > To: Gary Kenward > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > > primarily > > > > > arises out of a perceived need to determine at the MN the > > > best link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > choice of channels available; for intra-technology > > > handovers, there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > NSIS involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which > > > case I think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > and clearly > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer > > > has been used > > > > > to > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > > > believe > > > > > that for "seamless" handovers, the context will be > > > available at > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > implies > > > > > that there is a relationship, probabilistic > > > perhaps, between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision (it > > > > > is not clear to me how this happens, but it seems > > > clear that > > > > > for a more "seamless" handover, the MN should > > > chose an AR that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > because of changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and > > > after a handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this > > > approach does not > > > > > sit well with me, for it seems to defer the problem to > > > the people who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > > > concerned with the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DF39.2E13BD20 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and
(according to your scenario), the QoS context transfer fails (for some
inexplicable reason). Some entity (the CT protocol stack according to
your proposal) sends an indication to the MN that the QoS context transfer
has failed (according to your proposal). How does the MN know what to do
with this notice? The MN has to understand:
   
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary


> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 8, 2002 14:42
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Nakhjiri Madjid-MNAKHJI1; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary Kenward wrote:
>
> >
> >
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > have to understand the semantics of Context transfer, etc.,
>
> The MN does not have to know the CT semantics.
> It only needs to understand a notification message
> that provides the error condition related to its
> context.
>
> >
> > and, more important, there would have to be a protocol or
> > protocols that would allow the MN to recreate contexts at an AR.
> > I doubt that the latter is going to happen (e.g. authentication).
> >
>
> Well, the MN should use whatever protocol was
> used that established the context in the first place,
> including for authentication.
>
> >
> > IF and when a CT fails, the easiest way to "recreate" context
> > is for the sessions to be dropped. This may seem drastic,
> > but in reality, what is going to cause CT to fail and
> > how often will this happen?
> >
>
> This is a drastic idea! I think we can do better.
> For one thing, you still have connectivity which
> you could use to notify the MN so that the MN
> can resort to re-establishing contexts (or not). Besides,
> CT is a protocol, and like any other protocol has
> error cases and failure modes. There must be a
> notification message that provides protocol
> robustness.
> An example that has been brought up is where
> the transferred context is not useful, either
> partially or entirely. You would like to notify
> the MN when this happens.
>
>
> >
> > There may be mitigating actions that could be taken to re-establish
> > certain sessions. But these decisions are must be driven by
> the policy
> >
> > of the network administration (explicit or implicity), and comply
> > with the security, resource management and accounting requirements
> > for the network. Hopefully, none of these mitigating
> actions requires
> > more over-the-air signalling.
> >
>
> And, why are these any better when CT fails compared
> to notifying a MN ? Seems to me that a notification message
> would not encumber any of the above overheads. You
> leave it up to the MN.
>
> -Rajeev
>
>
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > Sent: April 5, 2002 17:46
> > > To: Nakhjiri Madjid-MNAKHJI1
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > Hello Madjid,
> > >
> > > Nakhjiri Madjid-MNAKHJI1 wrote:
> > >
> > > > Hello Rajeev,
> > > >
> > > > I agreed with everything you say below, except one thing:
> > > > CT can only transfer whatever QoS state that is usable at the
> > newAR.
> > > > If the new network is using a different QoS technology with
> > > different
> > > > QoS parameters, then I am not sure if CT by itself can do
> > > the job, unless
> > > > you add your own mapping functionality.
> > > >
> > >
> > > This would be an example where the new AR sends a
> > > notification to the MN so that the MN can take
> > > appropriate action (for instance, attempt to
> > > re-create the context).
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR,
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > > Sent: Friday, April 05, 2002 11:01 AM
> > > > To: Gary Kenward
> > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> >
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> > primarily
> > > > > arises out of a perceived need to determine at the MN the
> > > best link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> > in
> > > > > that situation is highly questionable (e.g. since it is a
> > > discovery
> > > > > protocol, the implication is that the purpose is to determine
> > the
> > > > > choice of channels available; for intra-technology
> > > handovers, there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply
> > > NSIS involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which
> > > case I think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> > role
> > > > > of NSIS in QoS re-negotiation is still open, I believe,
> > > and clearly
> > > > > handover is a dynamic situation that could cause the QoS
> > > provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context transfer
> > > has been used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> > > requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> >
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> > > available at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> > This
> > > > > implies
> > > > >        that there is a relationship, probabilistic
> > > perhaps, between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the handover
> > > decision (it
> > > > >        is not clear to me how this happens, but it seems
> > > clear that
> > > > >        for a more "seamless" handover, the MN should
> > > chose an AR that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS
> > > because of changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and
> > > after a handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this
> > > approach does not
> > > > > sit well with me, for it seems to defer the problem to
> > > the people who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> > [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> > > concerned with the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DF39.2E13BD20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 16:24: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 QAA05221 for ; Mon, 8 Apr 2002 16:24:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07843 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 16:24:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07031; Mon, 8 Apr 2002 16:13:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06898 for ; Mon, 8 Apr 2002 16:13:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941; Mon, 8 Apr 2002 16:13:34 -0400 (EDT) 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 g38K8ji09475; Mon, 8 Apr 2002 16:08:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:08:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49EF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:08:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF39.2E13BD20" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF39.2E13BD20 Content-Type: text/plain; charset="iso-8859-1" Rajeev: A user starts up an application that requests a "gold service". The protocol stack (perhaps an NSIS protocol stack) sends in a request from MN to AN for gold service". A handover occurs, and (according to your scenario), the QoS context transfer fails (for some inexplicable reason). Some entity (the CT protocol stack according to your proposal) sends an indication to the MN that the QoS context transfer has failed (according to your proposal). How does the MN know what to do with this notice? The MN has to understand: - what a handover is at the IP level - what an IP context transfer is - that QoS context is (sometimes) transferred separately from other context - what the nature of the failure was, and thus, what action to take. - how and with what entity to initiate QoS re-negotiation. The knowledge for all of the above is either explicitly or implicitly built into the MN. If the intent were for the MN to receive back a message that indicating "Gold service not available" then this is simply a session disconnect. If the intent is for the MN to be told that "the QoS associated with Gold service" has failed, then the MN has to know that Gold service is actually a combination of features (AAA, security, HC), and to initiate negotiation, it has to be able to talk to the individual network entities - entities which may not even exist within a given network (e.g. a provision model). So, how is the MN ignorant of CT? Service models? Keep in mind, according to the CT requirements, CT does not know what is contained in the data chunks it transports. Thus, at best, it can only forward to the MN that data chunk or another, opaque data chunk. Even this capability is a major modification to what should be a simple state machine for the CT protocol. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 8, 2002 14:42 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Nakhjiri Madjid-MNAKHJI1; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary Kenward wrote: > > > > > > > Rajeev: > > > > In order for the MN to "recreate the context", the MN would > > have to understand the semantics of Context transfer, etc., > > The MN does not have to know the CT semantics. > It only needs to understand a notification message > that provides the error condition related to its > context. > > > > > and, more important, there would have to be a protocol or > > protocols that would allow the MN to recreate contexts at an AR. > > I doubt that the latter is going to happen (e.g. authentication). > > > > Well, the MN should use whatever protocol was > used that established the context in the first place, > including for authentication. > > > > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > This is a drastic idea! I think we can do better. > For one thing, you still have connectivity which > you could use to notify the MN so that the MN > can resort to re-establishing contexts (or not). Besides, > CT is a protocol, and like any other protocol has > error cases and failure modes. There must be a > notification message that provides protocol > robustness. > An example that has been brought up is where > the transferred context is not useful, either > partially or entirely. You would like to notify > the MN when this happens. > > > > > > There may be mitigating actions that could be taken to re-establish > > certain sessions. But these decisions are must be driven by > the policy > > > > of the network administration (explicit or implicity), and comply > > with the security, resource management and accounting requirements > > for the network. Hopefully, none of these mitigating > actions requires > > more over-the-air signalling. > > > > And, why are these any better when CT fails compared > to notifying a MN ? Seems to me that a notification message > would not encumber any of the above overheads. You > leave it up to the MN. > > -Rajeev > > > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: April 5, 2002 17:46 > > > To: Nakhjiri Madjid-MNAKHJI1 > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hello Madjid, > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > Hello Rajeev, > > > > > > > > I agreed with everything you say below, except one thing: > > > > CT can only transfer whatever QoS state that is usable at the > > newAR. > > > > If the new network is using a different QoS technology with > > > different > > > > QoS parameters, then I am not sure if CT by itself can do > > > the job, unless > > > > you add your own mapping functionality. > > > > > > > > > > This would be an example where the new AR sends a > > > notification to the MN so that the MN can take > > > appropriate action (for instance, attempt to > > > re-create the context). > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > BR, > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > To: Gary Kenward > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > > primarily > > > > > arises out of a perceived need to determine at the MN the > > > best link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > choice of channels available; for intra-technology > > > handovers, there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > NSIS involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which > > > case I think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > and clearly > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer > > > has been used > > > > > to > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > > > believe > > > > > that for "seamless" handovers, the context will be > > > available at > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > implies > > > > > that there is a relationship, probabilistic > > > perhaps, between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision (it > > > > > is not clear to me how this happens, but it seems > > > clear that > > > > > for a more "seamless" handover, the MN should > > > chose an AR that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > because of changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and > > > after a handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this > > > approach does not > > > > > sit well with me, for it seems to defer the problem to > > > the people who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > > > concerned with the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DF39.2E13BD20 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and
(according to your scenario), the QoS context transfer fails (for some
inexplicable reason). Some entity (the CT protocol stack according to
your proposal) sends an indication to the MN that the QoS context transfer
has failed (according to your proposal). How does the MN know what to do
with this notice? The MN has to understand:
   
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary


> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 8, 2002 14:42
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Nakhjiri Madjid-MNAKHJI1; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary Kenward wrote:
>
> >
> >
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > have to understand the semantics of Context transfer, etc.,
>
> The MN does not have to know the CT semantics.
> It only needs to understand a notification message
> that provides the error condition related to its
> context.
>
> >
> > and, more important, there would have to be a protocol or
> > protocols that would allow the MN to recreate contexts at an AR.
> > I doubt that the latter is going to happen (e.g. authentication).
> >
>
> Well, the MN should use whatever protocol was
> used that established the context in the first place,
> including for authentication.
>
> >
> > IF and when a CT fails, the easiest way to "recreate" context
> > is for the sessions to be dropped. This may seem drastic,
> > but in reality, what is going to cause CT to fail and
> > how often will this happen?
> >
>
> This is a drastic idea! I think we can do better.
> For one thing, you still have connectivity which
> you could use to notify the MN so that the MN
> can resort to re-establishing contexts (or not). Besides,
> CT is a protocol, and like any other protocol has
> error cases and failure modes. There must be a
> notification message that provides protocol
> robustness.
> An example that has been brought up is where
> the transferred context is not useful, either
> partially or entirely. You would like to notify
> the MN when this happens.
>
>
> >
> > There may be mitigating actions that could be taken to re-establish
> > certain sessions. But these decisions are must be driven by
> the policy
> >
> > of the network administration (explicit or implicity), and comply
> > with the security, resource management and accounting requirements
> > for the network. Hopefully, none of these mitigating
> actions requires
> > more over-the-air signalling.
> >
>
> And, why are these any better when CT fails compared
> to notifying a MN ? Seems to me that a notification message
> would not encumber any of the above overheads. You
> leave it up to the MN.
>
> -Rajeev
>
>
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > Sent: April 5, 2002 17:46
> > > To: Nakhjiri Madjid-MNAKHJI1
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > Hello Madjid,
> > >
> > > Nakhjiri Madjid-MNAKHJI1 wrote:
> > >
> > > > Hello Rajeev,
> > > >
> > > > I agreed with everything you say below, except one thing:
> > > > CT can only transfer whatever QoS state that is usable at the
> > newAR.
> > > > If the new network is using a different QoS technology with
> > > different
> > > > QoS parameters, then I am not sure if CT by itself can do
> > > the job, unless
> > > > you add your own mapping functionality.
> > > >
> > >
> > > This would be an example where the new AR sends a
> > > notification to the MN so that the MN can take
> > > appropriate action (for instance, attempt to
> > > re-create the context).
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR,
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > > Sent: Friday, April 05, 2002 11:01 AM
> > > > To: Gary Kenward
> > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> >
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> > primarily
> > > > > arises out of a perceived need to determine at the MN the
> > > best link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> > in
> > > > > that situation is highly questionable (e.g. since it is a
> > > discovery
> > > > > protocol, the implication is that the purpose is to determine
> > the
> > > > > choice of channels available; for intra-technology
> > > handovers, there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply
> > > NSIS involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which
> > > case I think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> > role
> > > > > of NSIS in QoS re-negotiation is still open, I believe,
> > > and clearly
> > > > > handover is a dynamic situation that could cause the QoS
> > > provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context transfer
> > > has been used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> > > requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> >
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> > > available at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> > This
> > > > > implies
> > > > >        that there is a relationship, probabilistic
> > > perhaps, between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the handover
> > > decision (it
> > > > >        is not clear to me how this happens, but it seems
> > > clear that
> > > > >        for a more "seamless" handover, the MN should
> > > chose an AR that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS
> > > because of changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and
> > > after a handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this
> > > approach does not
> > > > > sit well with me, for it seems to defer the problem to
> > > the people who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> > [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> > > concerned with the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > > > > _______________________________________________
> > > > > > nsis mailing list
> > > > > > nsis@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DF39.2E13BD20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 16:33: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 QAA05496 for ; Mon, 8 Apr 2002 16:33:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07978; Mon, 8 Apr 2002 16:26:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07903 for ; Mon, 8 Apr 2002 16:26:01 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05274; Mon, 8 Apr 2002 16:25:57 -0400 (EDT) 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 g38KLQi10282; Mon, 8 Apr 2002 16:21:26 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:21:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49F0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:21:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF3A.F5479672" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF3A.F5479672 Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 15:55 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > As I outlined in one of my other posts, why would you > perform CT to an > > AR that did not have the necessary capabilities. Is this actually > about > > CAR failure?? > > > > Yes and no. > > Suppose the MN is expecting CT to be performed and it is not > because the A nit, but the MN does not expect CT. The MN expects continuous service (i.e. seamless service), and knows nothing about how it is supported (it could be provisioned). > new AR can't interpret the context. > The old AR may discover this via CAR, but if there is no way to > communicate it to the MN, then the MN can't know to perform the > signaling from scratch on the new AR. One could either inform the MN > beforehand to do the signaling, as is done with FMIPv6/BETH, or signal > the MN on the new AR. > > For dynamic failures, such as when the AR runs out of Gold Class > service, the signaling could only be done afterwards. I understand these scenarios, but I do not understand what they have to do with CT. CT has never intended to be an MN signalling protocol. Let me try a counter example: the service authorization fails. Would a CT message saying the AA context transfer failed be of much use to the MN? No, because the problem wasn't with the context, it was with a disconnect between the service request and authorization profile for that MN. There is a need for a "handover failure" indication message to the MN (indicating full or partial handover failure), but this message should be part of a different protocol from CT. Gary > > jak > ------_=_NextPart_001_01C1DF3A.F5479672 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 15:55
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> > As I outlined in one of my other posts, why would you
> perform CT to an
> > AR that did not have the necessary capabilities. Is this actually
> about
> > CAR failure??
> >
>
> Yes and no.
>
> Suppose the MN is expecting CT to be performed and it is not
> because the

A nit, but the MN does not expect CT. The MN expects continuous
service (i.e. seamless service), and knows nothing about how it is
supported (it could be provisioned).

> new AR can't interpret the context.
> The old AR may discover this via CAR, but if there is no way to
> communicate it to the MN, then the MN can't know to perform the
> signaling from scratch on the new AR.  One could either inform the MN
> beforehand to do the signaling, as is done with FMIPv6/BETH, or signal
> the MN on the new AR.
>
> For dynamic failures, such as when the AR runs out of Gold Class
> service, the signaling could only be done afterwards.

I understand these scenarios, but I do not understand what they have
to do with CT. CT has never intended to be an MN signalling protocol.
Let me try a counter example: the service authorization fails. Would
a CT message saying the AA context transfer failed be of much use
to the MN? No, because the problem wasn't with the context, it was with
a disconnect between the service request and authorization profile for
that MN.

There is a need for a "handover failure" indication message to the
MN (indicating full or partial handover failure), but this message should
be part of a different protocol from CT.

Gary

>
>             jak
>

------_=_NextPart_001_01C1DF3A.F5479672-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 16: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 QAA05507 for ; Mon, 8 Apr 2002 16:33:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08993 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 16:34:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07978; Mon, 8 Apr 2002 16:26:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07903 for ; Mon, 8 Apr 2002 16:26:01 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05274; Mon, 8 Apr 2002 16:25:57 -0400 (EDT) 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 g38KLQi10282; Mon, 8 Apr 2002 16:21:26 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:21:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49F0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:21:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF3A.F5479672" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF3A.F5479672 Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 15:55 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > As I outlined in one of my other posts, why would you > perform CT to an > > AR that did not have the necessary capabilities. Is this actually > about > > CAR failure?? > > > > Yes and no. > > Suppose the MN is expecting CT to be performed and it is not > because the A nit, but the MN does not expect CT. The MN expects continuous service (i.e. seamless service), and knows nothing about how it is supported (it could be provisioned). > new AR can't interpret the context. > The old AR may discover this via CAR, but if there is no way to > communicate it to the MN, then the MN can't know to perform the > signaling from scratch on the new AR. One could either inform the MN > beforehand to do the signaling, as is done with FMIPv6/BETH, or signal > the MN on the new AR. > > For dynamic failures, such as when the AR runs out of Gold Class > service, the signaling could only be done afterwards. I understand these scenarios, but I do not understand what they have to do with CT. CT has never intended to be an MN signalling protocol. Let me try a counter example: the service authorization fails. Would a CT message saying the AA context transfer failed be of much use to the MN? No, because the problem wasn't with the context, it was with a disconnect between the service request and authorization profile for that MN. There is a need for a "handover failure" indication message to the MN (indicating full or partial handover failure), but this message should be part of a different protocol from CT. Gary > > jak > ------_=_NextPart_001_01C1DF3A.F5479672 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 15:55
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> > As I outlined in one of my other posts, why would you
> perform CT to an
> > AR that did not have the necessary capabilities. Is this actually
> about
> > CAR failure??
> >
>
> Yes and no.
>
> Suppose the MN is expecting CT to be performed and it is not
> because the

A nit, but the MN does not expect CT. The MN expects continuous
service (i.e. seamless service), and knows nothing about how it is
supported (it could be provisioned).

> new AR can't interpret the context.
> The old AR may discover this via CAR, but if there is no way to
> communicate it to the MN, then the MN can't know to perform the
> signaling from scratch on the new AR.  One could either inform the MN
> beforehand to do the signaling, as is done with FMIPv6/BETH, or signal
> the MN on the new AR.
>
> For dynamic failures, such as when the AR runs out of Gold Class
> service, the signaling could only be done afterwards.

I understand these scenarios, but I do not understand what they have
to do with CT. CT has never intended to be an MN signalling protocol.
Let me try a counter example: the service authorization fails. Would
a CT message saying the AA context transfer failed be of much use
to the MN? No, because the problem wasn't with the context, it was with
a disconnect between the service request and authorization profile for
that MN.

There is a need for a "handover failure" indication message to the
MN (indicating full or partial handover failure), but this message should
be part of a different protocol from CT.

Gary

>
>             jak
>

------_=_NextPart_001_01C1DF3A.F5479672-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 16: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 QAA05761 for ; Mon, 8 Apr 2002 16:43:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09094; Mon, 8 Apr 2002 16:35:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09066 for ; Mon, 8 Apr 2002 16:34:58 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05556; Mon, 8 Apr 2002 16:34:54 -0400 (EDT) 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 g38KUMt21288; Mon, 8 Apr 2002 16:30:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:30:23 -0400 Received: from zrtps0km.us.nortel.com ([47.140.192.54]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P90FJ39; Mon, 8 Apr 2002 16:16:45 -0400 Received: from ertpsms3.internet.nortel.com (ertpsms3.internet.nortel.com [47.234.0.33] (may be forged)) by zrtps0km.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g38KGJ802708; Mon, 8 Apr 2002 16:16:19 -0400 (EDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by ertpsms3.internet.nortel.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 08 Apr 2002 16:21:40 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07021; Mon, 8 Apr 2002 16:13:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06898 for ; Mon, 8 Apr 2002 16:13:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941; Mon, 8 Apr 2002 16:13:34 -0400 (EDT) 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 g38K8ji09475; Mon, 8 Apr 2002 16:08:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:08:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:30:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF3C.25220886" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF3C.25220886 Content-Type: text/plain; charset="iso-8859-1" Rajeev: A user starts up an application that requests a "gold service". The protocol stack (perhaps an NSIS protocol stack) sends in a request from MN to AN for gold service". A handover occurs, and (according to your scenario), the QoS context transfer fails (for some inexplicable reason). Some entity (the CT protocol stack according to your proposal) sends an indication to the MN that the QoS context transfer has failed (according to your proposal). How does the MN know what to do with this notice? The MN has to understand: - what a handover is at the IP level - what an IP context transfer is - that QoS context is (sometimes) transferred separately from other context - what the nature of the failure was, and thus, what action to take. - how and with what entity to initiate QoS re-negotiation. The knowledge for all of the above is either explicitly or implicitly built into the MN. If the intent were for the MN to receive back a message that indicating "Gold service not available" then this is simply a session disconnect. If the intent is for the MN to be told that "the QoS associated with Gold service" has failed, then the MN has to know that Gold service is actually a combination of features (AAA, security, HC), and to initiate negotiation, it has to be able to talk to the individual network entities - entities which may not even exist within a given network (e.g. a provision model). So, how is the MN ignorant of CT? Service models? Keep in mind, according to the CT requirements, CT does not know what is contained in the data chunks it transports. Thus, at best, it can only forward to the MN that data chunk or another, opaque data chunk. Even this capability is a major modification to what should be a simple state machine for the CT protocol. Gary *snip* > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DF3C.25220886 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and
(according to your scenario), the QoS context transfer fails (for some
inexplicable reason). Some entity (the CT protocol stack according to
your proposal) sends an indication to the MN that the QoS context transfer
has failed (according to your proposal). How does the MN know what to do
with this notice? The MN has to understand:
   
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary

*snip*

 

>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DF3C.25220886-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 16:43: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 QAA05774 for ; Mon, 8 Apr 2002 16:43:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09805 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 16:43:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09094; Mon, 8 Apr 2002 16:35:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09066 for ; Mon, 8 Apr 2002 16:34:58 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05556; Mon, 8 Apr 2002 16:34:54 -0400 (EDT) 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 g38KUMt21288; Mon, 8 Apr 2002 16:30:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:30:23 -0400 Received: from zrtps0km.us.nortel.com ([47.140.192.54]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P90FJ39; Mon, 8 Apr 2002 16:16:45 -0400 Received: from ertpsms3.internet.nortel.com (ertpsms3.internet.nortel.com [47.234.0.33] (may be forged)) by zrtps0km.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g38KGJ802708; Mon, 8 Apr 2002 16:16:19 -0400 (EDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by ertpsms3.internet.nortel.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 08 Apr 2002 16:21:40 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07021; Mon, 8 Apr 2002 16:13:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06898 for ; Mon, 8 Apr 2002 16:13:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941; Mon, 8 Apr 2002 16:13:34 -0400 (EDT) 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 g38K8ji09475; Mon, 8 Apr 2002 16:08:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:08:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:30:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF3C.25220886" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF3C.25220886 Content-Type: text/plain; charset="iso-8859-1" Rajeev: A user starts up an application that requests a "gold service". The protocol stack (perhaps an NSIS protocol stack) sends in a request from MN to AN for gold service". A handover occurs, and (according to your scenario), the QoS context transfer fails (for some inexplicable reason). Some entity (the CT protocol stack according to your proposal) sends an indication to the MN that the QoS context transfer has failed (according to your proposal). How does the MN know what to do with this notice? The MN has to understand: - what a handover is at the IP level - what an IP context transfer is - that QoS context is (sometimes) transferred separately from other context - what the nature of the failure was, and thus, what action to take. - how and with what entity to initiate QoS re-negotiation. The knowledge for all of the above is either explicitly or implicitly built into the MN. If the intent were for the MN to receive back a message that indicating "Gold service not available" then this is simply a session disconnect. If the intent is for the MN to be told that "the QoS associated with Gold service" has failed, then the MN has to know that Gold service is actually a combination of features (AAA, security, HC), and to initiate negotiation, it has to be able to talk to the individual network entities - entities which may not even exist within a given network (e.g. a provision model). So, how is the MN ignorant of CT? Service models? Keep in mind, according to the CT requirements, CT does not know what is contained in the data chunks it transports. Thus, at best, it can only forward to the MN that data chunk or another, opaque data chunk. Even this capability is a major modification to what should be a simple state machine for the CT protocol. Gary *snip* > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DF3C.25220886 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and
(according to your scenario), the QoS context transfer fails (for some
inexplicable reason). Some entity (the CT protocol stack according to
your proposal) sends an indication to the MN that the QoS context transfer
has failed (according to your proposal). How does the MN know what to do
with this notice? The MN has to understand:
   
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary

*snip*

 

>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DF3C.25220886-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 16:55: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 QAA06209 for ; Mon, 8 Apr 2002 16:55:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09763; Mon, 8 Apr 2002 16:43:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09674 for ; Mon, 8 Apr 2002 16:43:02 -0400 (EDT) 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 QAA05748; Mon, 8 Apr 2002 16:42:57 -0400 (EDT) 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 NAA04565; Mon, 8 Apr 2002 13:42:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38KgS304947; Mon, 8 Apr 2002 13:42:28 -0700 X-mProtect: <200204082042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8vJw5Q; Mon, 08 Apr 2002 13:42:26 PDT Message-ID: <3CB200B2.7BFA438F@iprg.nokia.com> Date: Mon, 08 Apr 2002 13:42:26 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.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 Gary Kenward wrote: > > > "Re-create" was Rajeev's term, not mine. I think that it is an > appropriate > term if one considers other mechanisms besides session setup > signalling. > Either way, it is not a CT function. > By "re-create" I meant the MN establishes a context through feature-specific signaling, e.g., QoS signaling. I think I described this in the associated posting. > > As I outlined in one of my other posts, why would you perform CT to an > > AR that did not have the necessary capabilities. Is this actually > about > CAR failure?? you may have missed my response.. Anyway, you would like to be able to do CT without assuming CAR support. When you do CT and the target AR does not support the feature or only partially supports it (IPv6/UDP/RTP versus IPv6/UDP only header compression) , that's an example where you want the MN notified. -Rajeev > > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 14:26 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I don't think the issue is having the MN re-create the context. Is > is > > allowing the MN to recover by re-running the actions that > > were necessary > > to create the context in the first place, in the event the AR > > was unable > > to interpret it. > > Thus, for example, suppose that QoS context is transferred from old > to > > new AR, but new AR for some reason can't interpret it, > > perhaps there is > > no bandwidth left or perhaps the new AR uses a different > > representation > > for QoS context. The MN would need to be informed somehow so that it > > > could re-do its QoS signaling. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'Rajeev Koodli'" ; "Nakhjiri > > Madjid-MNAKHJI1" > > Cc: ; ; > > Sent: Monday, April 08, 2002 10:54 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Rajeev: > > > > > > In order for the MN to "recreate the context", the MN would > > > have to understand the semantics of Context transfer, etc., > > > and, more important, there would have to be a protocol or > > > protocols that would allow the MN to recreate contexts at an AR. > > > I doubt that the latter is going to happen (e.g. authentication). > > > > > > IF and when a CT fails, the easiest way to "recreate" context > > > is for the sessions to be dropped. This may seem drastic, > > > but in reality, what is going to cause CT to fail and > > > how often will this happen? > > > > > > There may be mitigating actions that could be taken to > re-establish > > > certain sessions. But these decisions are must be driven by > > the policy > > > of the network administration (explicit or implicity), and comply > > > with the security, resource management and accounting requirements > > > > for the network. Hopefully, none of these mitigating > > actions requires > > > more over-the-air signalling. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: April 5, 2002 17:46 > > > > To: Nakhjiri Madjid-MNAKHJI1 > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > Hello Madjid, > > > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > > > Hello Rajeev, > > > > > > > > > > I agreed with everything you say below, except one thing: > > > > > CT can only transfer whatever QoS state that is usable at the > > newAR. > > > > > If the new network is using a different QoS technology with > > > > different > > > > > QoS parameters, then I am not sure if CT by itself can do > > > > the job, unless > > > > > you add your own mapping functionality. > > > > > > > > > > > > > This would be an example where the new AR sends a > > > > notification to the MN so that the MN can take > > > > appropriate action (for instance, attempt to > > > > re-create the context). > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > BR, > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > > To: Gary Kenward > > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS > > establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the > > > > best link > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the > value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > > > discovery > > > > > > protocol, the implication is that the purpose is to > determine > > the > > > > > > choice of channels available; for intra-technology > > > > handovers, there > > > > > > are many, many reasons why this "choice" may not be > > available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > > NSIS involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which > > > > case I think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > > and clearly > > > > > > handover is a dynamic situation that could cause the QoS > > > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer > > > > has been used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. > > Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > > > available at > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic > > > > perhaps, between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > > decision (it > > > > > > is not clear to me how this happens, but it seems > > > > clear that > > > > > > for a more "seamless" handover, the MN should > > > > chose an AR that > > > > > > has received the appropriate context; if not, > > then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > > because of changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > with the three protocols interact before, during and > > > > after a handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this > > > > approach does not > > > > > > sit well with me, for it seems to defer the problem to > > > > the people who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be > > > > concerned with the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 Apr 8 16:55: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 QAA06224 for ; Mon, 8 Apr 2002 16:55:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10707 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 16:55:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09763; Mon, 8 Apr 2002 16:43:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09674 for ; Mon, 8 Apr 2002 16:43:02 -0400 (EDT) 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 QAA05748; Mon, 8 Apr 2002 16:42:57 -0400 (EDT) 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 NAA04565; Mon, 8 Apr 2002 13:42:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38KgS304947; Mon, 8 Apr 2002 13:42:28 -0700 X-mProtect: <200204082042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8vJw5Q; Mon, 08 Apr 2002 13:42:26 PDT Message-ID: <3CB200B2.7BFA438F@iprg.nokia.com> Date: Mon, 08 Apr 2002 13:42:26 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.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 Gary Kenward wrote: > > > "Re-create" was Rajeev's term, not mine. I think that it is an > appropriate > term if one considers other mechanisms besides session setup > signalling. > Either way, it is not a CT function. > By "re-create" I meant the MN establishes a context through feature-specific signaling, e.g., QoS signaling. I think I described this in the associated posting. > > As I outlined in one of my other posts, why would you perform CT to an > > AR that did not have the necessary capabilities. Is this actually > about > CAR failure?? you may have missed my response.. Anyway, you would like to be able to do CT without assuming CAR support. When you do CT and the target AR does not support the feature or only partially supports it (IPv6/UDP/RTP versus IPv6/UDP only header compression) , that's an example where you want the MN notified. -Rajeev > > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 14:26 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I don't think the issue is having the MN re-create the context. Is > is > > allowing the MN to recover by re-running the actions that > > were necessary > > to create the context in the first place, in the event the AR > > was unable > > to interpret it. > > Thus, for example, suppose that QoS context is transferred from old > to > > new AR, but new AR for some reason can't interpret it, > > perhaps there is > > no bandwidth left or perhaps the new AR uses a different > > representation > > for QoS context. The MN would need to be informed somehow so that it > > > could re-do its QoS signaling. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'Rajeev Koodli'" ; "Nakhjiri > > Madjid-MNAKHJI1" > > Cc: ; ; > > Sent: Monday, April 08, 2002 10:54 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Rajeev: > > > > > > In order for the MN to "recreate the context", the MN would > > > have to understand the semantics of Context transfer, etc., > > > and, more important, there would have to be a protocol or > > > protocols that would allow the MN to recreate contexts at an AR. > > > I doubt that the latter is going to happen (e.g. authentication). > > > > > > IF and when a CT fails, the easiest way to "recreate" context > > > is for the sessions to be dropped. This may seem drastic, > > > but in reality, what is going to cause CT to fail and > > > how often will this happen? > > > > > > There may be mitigating actions that could be taken to > re-establish > > > certain sessions. But these decisions are must be driven by > > the policy > > > of the network administration (explicit or implicity), and comply > > > with the security, resource management and accounting requirements > > > > for the network. Hopefully, none of these mitigating > > actions requires > > > more over-the-air signalling. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: April 5, 2002 17:46 > > > > To: Nakhjiri Madjid-MNAKHJI1 > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > Hello Madjid, > > > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > > > Hello Rajeev, > > > > > > > > > > I agreed with everything you say below, except one thing: > > > > > CT can only transfer whatever QoS state that is usable at the > > newAR. > > > > > If the new network is using a different QoS technology with > > > > different > > > > > QoS parameters, then I am not sure if CT by itself can do > > > > the job, unless > > > > > you add your own mapping functionality. > > > > > > > > > > > > > This would be an example where the new AR sends a > > > > notification to the MN so that the MN can take > > > > appropriate action (for instance, attempt to > > > > re-create the context). > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > BR, > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > > To: Gary Kenward > > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS > > establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the > > > > best link > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the > value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > > > discovery > > > > > > protocol, the implication is that the purpose is to > determine > > the > > > > > > choice of channels available; for intra-technology > > > > handovers, there > > > > > > are many, many reasons why this "choice" may not be > > available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > > NSIS involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which > > > > case I think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > > and clearly > > > > > > handover is a dynamic situation that could cause the QoS > > > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer > > > > has been used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. > > Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > > > available at > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic > > > > perhaps, between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > > decision (it > > > > > > is not clear to me how this happens, but it seems > > > > clear that > > > > > > for a more "seamless" handover, the MN should > > > > chose an AR that > > > > > > has received the appropriate context; if not, > > then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > > because of changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > with the three protocols interact before, during and > > > > after a handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this > > > > approach does not > > > > > > sit well with me, for it seems to defer the problem to > > > > the people who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be > > > > concerned with the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing 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 Apr 8 17: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 RAA07514 for ; Mon, 8 Apr 2002 17:51:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14873; Mon, 8 Apr 2002 17:39:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14749 for ; Mon, 8 Apr 2002 17:39:10 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07236; Mon, 8 Apr 2002 17:39:01 -0400 (EDT) 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 g38LYSi14243; Mon, 8 Apr 2002 17:34:29 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 17:34:28 -0400 Received: from zrtps0kk.us.nortel.com ([47.140.192.53]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HLDB9CTY; Mon, 8 Apr 2002 15:59:05 -0400 Received: from 47.234.0.34 ([47.234.0.34]) by zrtps0kk.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g38JwjD12889; Mon, 8 Apr 2002 15:58:45 -0400 (EDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 08 Apr 2002 15:55:23 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04370; Mon, 8 Apr 2002 15:51:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04250 for ; Mon, 8 Apr 2002 15:51:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04269; Mon, 8 Apr 2002 15:51:06 -0400 (EDT) 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 g38JkYt15797; Mon, 8 Apr 2002 15:46:34 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:46:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Rajeev Koodli'" , James Kempf Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 17:34:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF45.0A4CEAB8" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF45.0A4CEAB8 Content-Type: text/plain; charset="iso-8859-1" Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Regards, Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > *snip* > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DF45.0A4CEAB8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Can anyone offer an explaining of how or why CT would = add significantly
to the already unreliable physics of handover? =

What failure modes for CT would be noticeable above = the unavoidable
rate of handover failures due the vagaries of = wireless coverage and
wireless link layer performance????

If CT fails, then the handover fails. It is that = simple. If CT were
to fail with every 2nd handover attempt, then there = would be a problem.
But, I cannot seriously see CT failing more then = every one in a million
handover attempts, or less.

CT should not be attempted if there is an = incompatibility between source
and destination ARs. And, I HAD thought that it was = the purpose of CAR
to identify those incompatibilities and thus avoid = doing CT when it is
clear it would fail. How to mitigate those = incompatibles is not a
CT issue, it is a service adaptation issue, which = can be resolved in
a number of ways, some of which would imply = signalled negotiation either
between the ARs or between the ARs and the MN. =

Regards,
Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, = which by the way
> neither CT requirements, nor nsis requirements = are covering, has to
> do with failure in QoS negotiation. I don't = think you can count
> the case, where the QoS information that CT has = given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] =
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; = nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of = how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or not? =
> >
>
*snip*
> _______________________________________________ =
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby =
>

------_=_NextPart_001_01C1DF45.0A4CEAB8-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 17:51: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 RAA07525 for ; Mon, 8 Apr 2002 17:51:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15440 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 17:51:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14873; Mon, 8 Apr 2002 17:39:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14749 for ; Mon, 8 Apr 2002 17:39:10 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07236; Mon, 8 Apr 2002 17:39:01 -0400 (EDT) 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 g38LYSi14243; Mon, 8 Apr 2002 17:34:29 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 17:34:28 -0400 Received: from zrtps0kk.us.nortel.com ([47.140.192.53]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HLDB9CTY; Mon, 8 Apr 2002 15:59:05 -0400 Received: from 47.234.0.34 ([47.234.0.34]) by zrtps0kk.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g38JwjD12889; Mon, 8 Apr 2002 15:58:45 -0400 (EDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 08 Apr 2002 15:55:23 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04370; Mon, 8 Apr 2002 15:51:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04250 for ; Mon, 8 Apr 2002 15:51:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04269; Mon, 8 Apr 2002 15:51:06 -0400 (EDT) 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 g38JkYt15797; Mon, 8 Apr 2002 15:46:34 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:46:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Rajeev Koodli'" , James Kempf Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 17:34:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF45.0A4CEAB8" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DF45.0A4CEAB8 Content-Type: text/plain; charset="iso-8859-1" Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Regards, Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > *snip* > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DF45.0A4CEAB8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Can anyone offer an explaining of how or why CT would = add significantly
to the already unreliable physics of handover? =

What failure modes for CT would be noticeable above = the unavoidable
rate of handover failures due the vagaries of = wireless coverage and
wireless link layer performance????

If CT fails, then the handover fails. It is that = simple. If CT were
to fail with every 2nd handover attempt, then there = would be a problem.
But, I cannot seriously see CT failing more then = every one in a million
handover attempts, or less.

CT should not be attempted if there is an = incompatibility between source
and destination ARs. And, I HAD thought that it was = the purpose of CAR
to identify those incompatibilities and thus avoid = doing CT when it is
clear it would fail. How to mitigate those = incompatibles is not a
CT issue, it is a service adaptation issue, which = can be resolved in
a number of ways, some of which would imply = signalled negotiation either
between the ARs or between the ARs and the MN. =

Regards,
Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, = which by the way
> neither CT requirements, nor nsis requirements = are covering, has to
> do with failure in QoS negotiation. I don't = think you can count
> the case, where the QoS information that CT has = given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] =
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; = nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of = how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or not? =
> >
>
*snip*
> _______________________________________________ =
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby =
>

------_=_NextPart_001_01C1DF45.0A4CEAB8-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 18:07: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 SAA07920 for ; Mon, 8 Apr 2002 18:07:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16141; Mon, 8 Apr 2002 17:59:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16050 for ; Mon, 8 Apr 2002 17:58:59 -0400 (EDT) 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 RAA07784; Mon, 8 Apr 2002 17:58:53 -0400 (EDT) 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 OAA09738; Mon, 8 Apr 2002 14:58:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38LwO830511; Mon, 8 Apr 2002 14:58:24 -0700 X-mProtect: <200204082158> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiUEV7a; Mon, 08 Apr 2002 14:58:23 PDT Message-ID: <3CB2127F.A4E83662@iprg.nokia.com> Date: Mon, 08 Apr 2002 14:58:23 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.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 Hello Gary, I have $0.02 to add to the discussion: > Can anyone offer an explaining of how or why CT would add significantly > to the already unreliable physics of handover? Since I took physics in college, I can answer this. It would not add significantly to handover unreliability. > What failure modes for CT would be noticeable above the unavoidable > rate of handover failures due the vagaries of wireless coverage and > wireless link layer performance???? Congestion at intermediate routing points comes to mind. Just because two access points are both within range of a mobile node does not mean that they are neighbors to each other. They may even be attached to completely different physical media. > If CT fails, then the handover fails. It is that simple. If CT were > to fail with every 2nd handover attempt, then there would be a problem. I quite disagree with this statement. It depends on very many things. For instance, we have to be able to run CT without CARD. So, the destination access router might not offer header compression at all, for instance. Thus, the handover would succeed, but the context transfer (or, part of it) would fail. > But, I cannot seriously see CT failing more then every one in a million > handover attempts, or less. Cool! This could be good news. > CT should not be attempted if there is an incompatibility between source > and destination ARs. As noted above, I quite disagree with this statement. > And, I HAD thought that it was the purpose of CAR > to identify those incompatibilities and thus avoid doing CT when it is > clear it would fail. But, we have to be allowed to do CT without ever running CARD. For instance, we have reactive mode. > How to mitigate those incompatibles is not a > CT issue, it is a service adaptation issue, which can be resolved in > a number of ways, some of which would imply signalled negotiation either > between the ARs or between the ARs and the MN. Sometimes, the service cannot be adapted, and the feature context is just plain lost, because the feature is unavailable. Suppose, for example, that the contexts transferred include header compression, QoS, security, and other features. Now suppose that _only_ the security context can be transferred. That's still better than nothing! Maybe the QoS application will have to terminate, or go into degraded mode, but the other applications that need security will still be able to go on undisturbed. Why not? Regards, Charlie P. PS. I relucantly left NSIS on the CC: list, but shouldn't it be pruned? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 8 18:07: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 SAA07931 for ; Mon, 8 Apr 2002 18:07:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17011 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 18:07:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16141; Mon, 8 Apr 2002 17:59:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16050 for ; Mon, 8 Apr 2002 17:58:59 -0400 (EDT) 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 RAA07784; Mon, 8 Apr 2002 17:58:53 -0400 (EDT) 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 OAA09738; Mon, 8 Apr 2002 14:58:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38LwO830511; Mon, 8 Apr 2002 14:58:24 -0700 X-mProtect: <200204082158> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiUEV7a; Mon, 08 Apr 2002 14:58:23 PDT Message-ID: <3CB2127F.A4E83662@iprg.nokia.com> Date: Mon, 08 Apr 2002 14:58:23 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.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 Hello Gary, I have $0.02 to add to the discussion: > Can anyone offer an explaining of how or why CT would add significantly > to the already unreliable physics of handover? Since I took physics in college, I can answer this. It would not add significantly to handover unreliability. > What failure modes for CT would be noticeable above the unavoidable > rate of handover failures due the vagaries of wireless coverage and > wireless link layer performance???? Congestion at intermediate routing points comes to mind. Just because two access points are both within range of a mobile node does not mean that they are neighbors to each other. They may even be attached to completely different physical media. > If CT fails, then the handover fails. It is that simple. If CT were > to fail with every 2nd handover attempt, then there would be a problem. I quite disagree with this statement. It depends on very many things. For instance, we have to be able to run CT without CARD. So, the destination access router might not offer header compression at all, for instance. Thus, the handover would succeed, but the context transfer (or, part of it) would fail. > But, I cannot seriously see CT failing more then every one in a million > handover attempts, or less. Cool! This could be good news. > CT should not be attempted if there is an incompatibility between source > and destination ARs. As noted above, I quite disagree with this statement. > And, I HAD thought that it was the purpose of CAR > to identify those incompatibilities and thus avoid doing CT when it is > clear it would fail. But, we have to be allowed to do CT without ever running CARD. For instance, we have reactive mode. > How to mitigate those incompatibles is not a > CT issue, it is a service adaptation issue, which can be resolved in > a number of ways, some of which would imply signalled negotiation either > between the ARs or between the ARs and the MN. Sometimes, the service cannot be adapted, and the feature context is just plain lost, because the feature is unavailable. Suppose, for example, that the contexts transferred include header compression, QoS, security, and other features. Now suppose that _only_ the security context can be transferred. That's still better than nothing! Maybe the QoS application will have to terminate, or go into degraded mode, but the other applications that need security will still be able to go on undisturbed. Why not? Regards, Charlie P. PS. I relucantly left NSIS on the CC: list, but shouldn't it be pruned? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 20:49: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 UAA11541 for ; Mon, 8 Apr 2002 20:49:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25360; Mon, 8 Apr 2002 20:40:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25331 for ; Mon, 8 Apr 2002 20:40:24 -0400 (EDT) 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 UAA11457 for ; Mon, 8 Apr 2002 20:40:22 -0400 (EDT) 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 RAA20801; Mon, 8 Apr 2002 17:39:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g390dqx22628; Mon, 8 Apr 2002 17:39:52 -0700 X-mProtect: <200204090039> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGADx4X; Mon, 08 Apr 2002 17:39:50 PDT Message-ID: <3CB23857.D62CF3B1@iprg.nokia.com> Date: Mon, 08 Apr 2002 17:39:51 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.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 Gary Kenward wrote: > > > Rajeev: > > A user starts up an application that requests a "gold service". > The protocol stack (perhaps an NSIS protocol stack) sends in a > request from MN to AN for gold service". A handover occurs, and > (according to your scenario), the QoS context transfer fails (for some > > inexplicable reason). Some entity (the CT protocol stack according to Well, it is not so hard to imagine why CT might fail - transferred context is not useful; you don't want to CT to be applicable only where CARD is available, do you ? - transferred context is lost, and retransmission is not desirable > > your proposal) sends an indication to the MN that the QoS context > transfer > has failed (according to your proposal). How does the MN know what to > do > with this notice? The MN has to understand: > > - what a handover is at the IP level > It already knows, since it is on a new router! > - what an IP context transfer is to the same extent it has to know how to handle an error as a reply to feature (QoS) signaling. > > - that QoS context is (sometimes) transferred separately from other > > context I don't see why MN needs to know this.. > > - what the nature of the failure was, and thus, what action to > take. > What if this says initiate signaling to re-establish QoS. Until this signaling takes place, the MN's packets are still forwarded. That is, the session is _not_ disconnected. > - how and with what entity to initiate QoS re-negotiation. > the entity that sent the notification. > > The knowledge for all of the above is either explicitly or > implicitly > built into the MN. If the intent were for the MN to receive back a > message > that indicating "Gold service not available" then this is simply a > session > disconnect. If the intent is for the MN to be told that "the QoS > associated > I disagree with disconnecting a session because the support for received context is not available. > with Gold service" has failed, then the MN has to know that Gold > service > is actually a combination of features (AAA, security, HC), and to > initiate > negotiation, it has to be able to talk to the individual network > entities > - entities which may not even exist within a given network (e.g. a > provision > model). > "Gold Service" is a bundle you have conceived. I am only looking at the individual features. If QoS feature cannot be activated for whatever reason, the QoS feature uses a generic CT message to inform the MN. If multiple features cannot be instantiated, you would send a single message with multiple error codes. So, for a particular feature or an enumeration thereof, the MN _must_ know how to engage in signaling in order to obtain features it desires. > > So, how is the MN ignorant of CT? Service models? > MN is not ignorant of CT. In fact, the trigger to initiate CT may come from the MN itself! "4.4 The IP level context transfer triggers MAY be initiated by IP level (layer three) signalling. " Whether MN is ignorant/cognizant of service models is beyond scope, while recognized. > > Keep in mind, according to the CT requirements, CT does not know what > > is contained in the data chunks it transports. Thus, at best, it can > only forward to the MN that data chunk or another, opaque data chunk. > CT does not know what is in the data chunk. But, the feature-specific code knows, and it must have a hook to CT that allows MN notification. > Even this capability is a major modification to what should be > a simple state machine for the CT protocol. > I disagree. I readily see a CT SM that sends a notification message just as it processes a request for one or more contexts to be transferred. -Rajeev > > Gary > > *snip* > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 20:49: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 UAA11552 for ; Mon, 8 Apr 2002 20:49:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA25753 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 20:49:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25360; Mon, 8 Apr 2002 20:40:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25331 for ; Mon, 8 Apr 2002 20:40:24 -0400 (EDT) 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 UAA11457 for ; Mon, 8 Apr 2002 20:40:22 -0400 (EDT) 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 RAA20801; Mon, 8 Apr 2002 17:39:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g390dqx22628; Mon, 8 Apr 2002 17:39:52 -0700 X-mProtect: <200204090039> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGADx4X; Mon, 08 Apr 2002 17:39:50 PDT Message-ID: <3CB23857.D62CF3B1@iprg.nokia.com> Date: Mon, 08 Apr 2002 17:39:51 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.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 Gary Kenward wrote: > > > Rajeev: > > A user starts up an application that requests a "gold service". > The protocol stack (perhaps an NSIS protocol stack) sends in a > request from MN to AN for gold service". A handover occurs, and > (according to your scenario), the QoS context transfer fails (for some > > inexplicable reason). Some entity (the CT protocol stack according to Well, it is not so hard to imagine why CT might fail - transferred context is not useful; you don't want to CT to be applicable only where CARD is available, do you ? - transferred context is lost, and retransmission is not desirable > > your proposal) sends an indication to the MN that the QoS context > transfer > has failed (according to your proposal). How does the MN know what to > do > with this notice? The MN has to understand: > > - what a handover is at the IP level > It already knows, since it is on a new router! > - what an IP context transfer is to the same extent it has to know how to handle an error as a reply to feature (QoS) signaling. > > - that QoS context is (sometimes) transferred separately from other > > context I don't see why MN needs to know this.. > > - what the nature of the failure was, and thus, what action to > take. > What if this says initiate signaling to re-establish QoS. Until this signaling takes place, the MN's packets are still forwarded. That is, the session is _not_ disconnected. > - how and with what entity to initiate QoS re-negotiation. > the entity that sent the notification. > > The knowledge for all of the above is either explicitly or > implicitly > built into the MN. If the intent were for the MN to receive back a > message > that indicating "Gold service not available" then this is simply a > session > disconnect. If the intent is for the MN to be told that "the QoS > associated > I disagree with disconnecting a session because the support for received context is not available. > with Gold service" has failed, then the MN has to know that Gold > service > is actually a combination of features (AAA, security, HC), and to > initiate > negotiation, it has to be able to talk to the individual network > entities > - entities which may not even exist within a given network (e.g. a > provision > model). > "Gold Service" is a bundle you have conceived. I am only looking at the individual features. If QoS feature cannot be activated for whatever reason, the QoS feature uses a generic CT message to inform the MN. If multiple features cannot be instantiated, you would send a single message with multiple error codes. So, for a particular feature or an enumeration thereof, the MN _must_ know how to engage in signaling in order to obtain features it desires. > > So, how is the MN ignorant of CT? Service models? > MN is not ignorant of CT. In fact, the trigger to initiate CT may come from the MN itself! "4.4 The IP level context transfer triggers MAY be initiated by IP level (layer three) signalling. " Whether MN is ignorant/cognizant of service models is beyond scope, while recognized. > > Keep in mind, according to the CT requirements, CT does not know what > > is contained in the data chunks it transports. Thus, at best, it can > only forward to the MN that data chunk or another, opaque data chunk. > CT does not know what is in the data chunk. But, the feature-specific code knows, and it must have a hook to CT that allows MN notification. > Even this capability is a major modification to what should be > a simple state machine for the CT protocol. > I disagree. I readily see a CT SM that sends a notification message just as it processes a request for one or more contexts to be transferred. -Rajeev > > Gary > > *snip* > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 20:54: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 UAA11645 for ; Mon, 8 Apr 2002 20:54:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25795; Mon, 8 Apr 2002 20:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25766 for ; Mon, 8 Apr 2002 20:49:36 -0400 (EDT) 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 UAA11569 for ; Mon, 8 Apr 2002 20:49:33 -0400 (EDT) Received: (cpmta 28102 invoked from network); 8 Apr 2002 17:49:04 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.219) with SMTP; 8 Apr 2002 17:49:04 -0700 X-Sent: 9 Apr 2002 00:49:04 GMT Message-ID: <005f01c1df60$5d8d2470$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'Charles E. Perkins'" , "Nakhjiri Madjid-MNAKHJI1" Cc: "'James Kempf'" , References: <9FBD322B7824D511B36900508BF93C9C01AA49E7@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:49:11 -0400 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 RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. ----- Original Message ----- From: Gary Kenward > If someone really wants to provide CT over an all wireless >ad hoc network, for example, then, yes, additional reliability >will probably be required. In most wired infrastructure scenarios, >the link reliability is more then sufficient. pdn> There is not that much difference between an ad hoc network and a wireless network that doesn't support soft handover. I would argue that a wireless infrastructure network with hard handover is less reliable than an ad hoc nework with hard handover. >To allow for this flexibility in reliability, this type of >reliability needs to be provided in the transport layer, not >with CT. Specific reasons for building additional reliability >into the CT protocol that are generally applicable to a majority >of scenarios, and cannot be resolved by substituting a more >robust transport protocol, have yet to be offered. >Gary pdn>That's funny. Why don't you like more robust handoffs to begin with??? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 20:54: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 UAA11656 for ; Mon, 8 Apr 2002 20:54:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA26128 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 20:54:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25795; Mon, 8 Apr 2002 20:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25766 for ; Mon, 8 Apr 2002 20:49:36 -0400 (EDT) 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 UAA11569 for ; Mon, 8 Apr 2002 20:49:33 -0400 (EDT) Received: (cpmta 28102 invoked from network); 8 Apr 2002 17:49:04 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.219) with SMTP; 8 Apr 2002 17:49:04 -0700 X-Sent: 9 Apr 2002 00:49:04 GMT Message-ID: <005f01c1df60$5d8d2470$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'Charles E. Perkins'" , "Nakhjiri Madjid-MNAKHJI1" Cc: "'James Kempf'" , References: <9FBD322B7824D511B36900508BF93C9C01AA49E7@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:49:11 -0400 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 RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. ----- Original Message ----- From: Gary Kenward > If someone really wants to provide CT over an all wireless >ad hoc network, for example, then, yes, additional reliability >will probably be required. In most wired infrastructure scenarios, >the link reliability is more then sufficient. pdn> There is not that much difference between an ad hoc network and a wireless network that doesn't support soft handover. I would argue that a wireless infrastructure network with hard handover is less reliable than an ad hoc nework with hard handover. >To allow for this flexibility in reliability, this type of >reliability needs to be provided in the transport layer, not >with CT. Specific reasons for building additional reliability >into the CT protocol that are generally applicable to a majority >of scenarios, and cannot be resolved by substituting a more >robust transport protocol, have yet to be offered. >Gary pdn>That's funny. Why don't you like more robust handoffs to begin with??? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 20: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 UAA11732 for ; Mon, 8 Apr 2002 20:58:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25962; Mon, 8 Apr 2002 20:52:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25931 for ; Mon, 8 Apr 2002 20:52:25 -0400 (EDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11605 for ; Mon, 8 Apr 2002 20:52:22 -0400 (EDT) Received: (cpmta 11662 invoked from network); 8 Apr 2002 17:51:43 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.220) with SMTP; 8 Apr 2002 17:51:43 -0700 X-Sent: 9 Apr 2002 00:51:43 GMT Message-ID: <006501c1df60$bc502cf0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:51:49 -0400 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 ----- Original Message ----- From: "James Kempf" To: "Gary Kenward" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 2:25 PM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Gary, > > I don't think the issue is having the MN re-create the context. Is is > allowing the MN to recover by re-running the actions that were necessary > to create the context in the first place, in the event the AR was unable > to interpret it. Don't you agree that there will need to be several target ARs all receiving the context simultaneously, possibly via an anycast addressing structure? > Thus, for example, suppose that QoS context is transferred from old to > new AR, but new AR for some reason can't interpret it, perhaps there is > no bandwidth left or perhaps the new AR uses a different representation > for QoS context. The MN would need to be informed somehow so that it > could re-do its QoS signaling. Reword as, for example, suppose that QoS context is transferred to "a newly added AR", but the new AR can not interpret it. The MN could choose to skip using this AR completely. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 20: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 UAA11745 for ; Mon, 8 Apr 2002 20:58:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA26510 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 20:58:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25962; Mon, 8 Apr 2002 20:52:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25931 for ; Mon, 8 Apr 2002 20:52:25 -0400 (EDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11605 for ; Mon, 8 Apr 2002 20:52:22 -0400 (EDT) Received: (cpmta 11662 invoked from network); 8 Apr 2002 17:51:43 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.220) with SMTP; 8 Apr 2002 17:51:43 -0700 X-Sent: 9 Apr 2002 00:51:43 GMT Message-ID: <006501c1df60$bc502cf0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:51:49 -0400 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 ----- Original Message ----- From: "James Kempf" To: "Gary Kenward" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 2:25 PM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Gary, > > I don't think the issue is having the MN re-create the context. Is is > allowing the MN to recover by re-running the actions that were necessary > to create the context in the first place, in the event the AR was unable > to interpret it. Don't you agree that there will need to be several target ARs all receiving the context simultaneously, possibly via an anycast addressing structure? > Thus, for example, suppose that QoS context is transferred from old to > new AR, but new AR for some reason can't interpret it, perhaps there is > no bandwidth left or perhaps the new AR uses a different representation > for QoS context. The MN would need to be informed somehow so that it > could re-do its QoS signaling. Reword as, for example, suppose that QoS context is transferred to "a newly added AR", but the new AR can not interpret it. The MN could choose to skip using this AR completely. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21:04: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 VAA11859 for ; Mon, 8 Apr 2002 21:04:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26391; Mon, 8 Apr 2002 20:57:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26284 for ; Mon, 8 Apr 2002 20:56:59 -0400 (EDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11705 for ; Mon, 8 Apr 2002 20:56:56 -0400 (EDT) Received: (cpmta 25904 invoked from network); 8 Apr 2002 17:56:26 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.221) with SMTP; 8 Apr 2002 17:56:26 -0700 X-Sent: 9 Apr 2002 00:56:26 GMT Message-ID: <007101c1df61$64e44db0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E8@zcard031.ca.nortel.com> <02ab01c1df2b$b0512420$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:56:32 -0400 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 > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). This is wishful thinking. Lets finish the seamless handover over IP before we get into "gold class service". Convince me we have done just the basics! _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21: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 VAA11872 for ; Mon, 8 Apr 2002 21:04:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27429 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:04:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26391; Mon, 8 Apr 2002 20:57:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26284 for ; Mon, 8 Apr 2002 20:56:59 -0400 (EDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11705 for ; Mon, 8 Apr 2002 20:56:56 -0400 (EDT) Received: (cpmta 25904 invoked from network); 8 Apr 2002 17:56:26 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.221) with SMTP; 8 Apr 2002 17:56:26 -0700 X-Sent: 9 Apr 2002 00:56:26 GMT Message-ID: <007101c1df61$64e44db0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E8@zcard031.ca.nortel.com> <02ab01c1df2b$b0512420$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:56:32 -0400 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 > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). This is wishful thinking. Lets finish the seamless handover over IP before we get into "gold class service". Convince me we have done just the basics! _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21:05: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 VAA11894 for ; Mon, 8 Apr 2002 21:05:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26203; Mon, 8 Apr 2002 20:54:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26144 for ; Mon, 8 Apr 2002 20:54:55 -0400 (EDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11673 for ; Mon, 8 Apr 2002 20:54:52 -0400 (EDT) Received: (cpmta 14576 invoked from network); 8 Apr 2002 17:54:22 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.220) with SMTP; 8 Apr 2002 17:54:22 -0700 X-Sent: 9 Apr 2002 00:54:22 GMT Message-ID: <006b01c1df61$1b0293a0$0902a8c0@Study> From: "Phil Neumiller" To: "Rajeev Koodli" , "Gary Kenward" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <3CB1E487.5D2B7B37@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:54:28 -0400 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 > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > This is a drastic idea! I think we can do better. Yes, stay connected to multiple ARs. You will need it anyway for log normal shadow fading in outdoor environments. People on this list don't realize that frequencies are going up and these things will deployed outdoors where shadow fading is the killer. Its not going to be one big cell after another. Its going to be connections two or three crappy cells and making the best use of them. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21:05: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 VAA11904 for ; Mon, 8 Apr 2002 21:05:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27535 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:06:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26203; Mon, 8 Apr 2002 20:54:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26144 for ; Mon, 8 Apr 2002 20:54:55 -0400 (EDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11673 for ; Mon, 8 Apr 2002 20:54:52 -0400 (EDT) Received: (cpmta 14576 invoked from network); 8 Apr 2002 17:54:22 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.220) with SMTP; 8 Apr 2002 17:54:22 -0700 X-Sent: 9 Apr 2002 00:54:22 GMT Message-ID: <006b01c1df61$1b0293a0$0902a8c0@Study> From: "Phil Neumiller" To: "Rajeev Koodli" , "Gary Kenward" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <3CB1E487.5D2B7B37@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:54:28 -0400 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 > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > This is a drastic idea! I think we can do better. Yes, stay connected to multiple ARs. You will need it anyway for log normal shadow fading in outdoor environments. People on this list don't realize that frequencies are going up and these things will deployed outdoors where shadow fading is the killer. Its not going to be one big cell after another. Its going to be connections two or three crappy cells and making the best use of them. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21:06: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 VAA11936 for ; Mon, 8 Apr 2002 21:06:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26487; Mon, 8 Apr 2002 20:58:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26414 for ; Mon, 8 Apr 2002 20:58:02 -0400 (EDT) Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11719 for ; Mon, 8 Apr 2002 20:57:59 -0400 (EDT) Received: (cpmta 12385 invoked from network); 8 Apr 2002 17:57:31 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.217) with SMTP; 8 Apr 2002 17:57:31 -0700 X-Sent: 9 Apr 2002 00:57:31 GMT Message-ID: <007f01c1df61$8b8ab670$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'James Kempf'" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:57:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C1DF40.03CAFC20" 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 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_007C_01C1DF40.03CAFC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.>>Gary wrote: >>As I outlined in one of my other posts, why would you perform CT to an = >>AR that did not have the necessary capabilities. Is this actually = about=20 >>CAR failure??=20 Yupper I agree! ------=_NextPart_000_007C_01C1DF40.03CAFC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after = handoff.
>>Gary wrote:
>>As I outlined in one of my other posts, why = would you=20 perform CT to an
>>AR that did not have = the=20 necessary capabilities. Is this actually about
>>CAR failure??
 
Yupper I agree!
 
------=_NextPart_000_007C_01C1DF40.03CAFC20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21:07: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 VAA11950 for ; Mon, 8 Apr 2002 21:07:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27583 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:07:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26487; Mon, 8 Apr 2002 20:58:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26414 for ; Mon, 8 Apr 2002 20:58:02 -0400 (EDT) Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11719 for ; Mon, 8 Apr 2002 20:57:59 -0400 (EDT) Received: (cpmta 12385 invoked from network); 8 Apr 2002 17:57:31 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.217) with SMTP; 8 Apr 2002 17:57:31 -0700 X-Sent: 9 Apr 2002 00:57:31 GMT Message-ID: <007f01c1df61$8b8ab670$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'James Kempf'" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:57:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C1DF40.03CAFC20" 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 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_007C_01C1DF40.03CAFC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.>>Gary wrote: >>As I outlined in one of my other posts, why would you perform CT to an = >>AR that did not have the necessary capabilities. Is this actually = about=20 >>CAR failure??=20 Yupper I agree! ------=_NextPart_000_007C_01C1DF40.03CAFC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after = handoff.
>>Gary wrote:
>>As I outlined in one of my other posts, why = would you=20 perform CT to an
>>AR that did not have = the=20 necessary capabilities. Is this actually about
>>CAR failure??
 
Yupper I agree!
 
------=_NextPart_000_007C_01C1DF40.03CAFC20-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21:09: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 VAA12046 for ; Mon, 8 Apr 2002 21:09:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27080; Mon, 8 Apr 2002 21:01:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27008 for ; Mon, 8 Apr 2002 21:01:18 -0400 (EDT) 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 VAA11816 for ; Mon, 8 Apr 2002 21:01:15 -0400 (EDT) Received: (cpmta 703 invoked from network); 8 Apr 2002 18:00:46 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.206) with SMTP; 8 Apr 2002 18:00:46 -0700 X-Sent: 9 Apr 2002 01:00:46 GMT Message-ID: <008801c1df62$001ffd10$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49EF@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 21:00:53 -0400 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 RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.Aaarrghgh! See below.... >----- Original Message ----- >From: Gary Kenward >To: 'Rajeev Koodli' >Cc: Nakhjiri Madjid-MNAKHJI1 ; Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org >Sent: Monday, April 08, 2002 4:08 PM >Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. >Rajeev: > A user starts up an application that requests a "gold service". Define "gold service"? Define SeaMoby? What on earth are we talking about. The starting place is seamless handover and always has been. If we win that battle the rest is relatively easy. Why do we focus on the chrome when we need to work on the engine? >The protocol stack (perhaps an NSIS protocol stack) sends in a >request from MN to AN for gold service". Nice. Why don't we get UDP/TCP/SCTP to work first? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21:09: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 VAA12059 for ; Mon, 8 Apr 2002 21:09:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27938 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:09:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27080; Mon, 8 Apr 2002 21:01:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27008 for ; Mon, 8 Apr 2002 21:01:18 -0400 (EDT) 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 VAA11816 for ; Mon, 8 Apr 2002 21:01:15 -0400 (EDT) Received: (cpmta 703 invoked from network); 8 Apr 2002 18:00:46 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.206) with SMTP; 8 Apr 2002 18:00:46 -0700 X-Sent: 9 Apr 2002 01:00:46 GMT Message-ID: <008801c1df62$001ffd10$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49EF@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 21:00:53 -0400 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 RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.Aaarrghgh! See below.... >----- Original Message ----- >From: Gary Kenward >To: 'Rajeev Koodli' >Cc: Nakhjiri Madjid-MNAKHJI1 ; Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org >Sent: Monday, April 08, 2002 4:08 PM >Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. >Rajeev: > A user starts up an application that requests a "gold service". Define "gold service"? Define SeaMoby? What on earth are we talking about. The starting place is seamless handover and always has been. If we win that battle the rest is relatively easy. Why do we focus on the chrome when we need to work on the engine? >The protocol stack (perhaps an NSIS protocol stack) sends in a >request from MN to AN for gold service". Nice. Why don't we get UDP/TCP/SCTP to work first? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21:15: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 VAA12275 for ; Mon, 8 Apr 2002 21:15:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27920; Mon, 8 Apr 2002 21:09:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27830 for ; Mon, 8 Apr 2002 21:09:42 -0400 (EDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12041 for ; Mon, 8 Apr 2002 21:09:38 -0400 (EDT) Received: (cpmta 1844 invoked from network); 8 Apr 2002 18:09:10 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.221) with SMTP; 8 Apr 2002 18:09:10 -0700 X-Sent: 9 Apr 2002 01:09:10 GMT Message-ID: <00dd01c1df63$2c753640$0902a8c0@Study> From: "Phil Neumiller" To: "Charles E. Perkins" , "Gary Kenward" Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.com> <3CB2127F.A4E83662@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 21:09:17 -0400 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 ----- Original Message ----- > > What failure modes for CT would be noticeable above the unavoidable > > rate of handover failures due the vagaries of wireless coverage and > > wireless link layer performance???? > > Congestion at intermediate routing points comes to mind. Yes, and SOME MANET protocols are sensitive to this. > Just because two access points are both within range of a mobile node > does not mean that they are neighbors to each other. Aah, but maybe they want to be eh? Then what? > They may even > be attached to completely different physical media. Yes, but lets say I walk into a room with a Microsoft X100B-35S 100 Mbps wireless interface and you have your Binford 8000 and we want to chat. Should we not be able to take advantage of the local infrastructure? Securely??? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21:15: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 VAA12285 for ; Mon, 8 Apr 2002 21:15:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28309 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:15:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27920; Mon, 8 Apr 2002 21:09:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27830 for ; Mon, 8 Apr 2002 21:09:42 -0400 (EDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12041 for ; Mon, 8 Apr 2002 21:09:38 -0400 (EDT) Received: (cpmta 1844 invoked from network); 8 Apr 2002 18:09:10 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.221) with SMTP; 8 Apr 2002 18:09:10 -0700 X-Sent: 9 Apr 2002 01:09:10 GMT Message-ID: <00dd01c1df63$2c753640$0902a8c0@Study> From: "Phil Neumiller" To: "Charles E. Perkins" , "Gary Kenward" Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.com> <3CB2127F.A4E83662@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 21:09:17 -0400 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 ----- Original Message ----- > > What failure modes for CT would be noticeable above the unavoidable > > rate of handover failures due the vagaries of wireless coverage and > > wireless link layer performance???? > > Congestion at intermediate routing points comes to mind. Yes, and SOME MANET protocols are sensitive to this. > Just because two access points are both within range of a mobile node > does not mean that they are neighbors to each other. Aah, but maybe they want to be eh? Then what? > They may even > be attached to completely different physical media. Yes, but lets say I walk into a room with a Microsoft X100B-35S 100 Mbps wireless interface and you have your Binford 8000 and we want to chat. Should we not be able to take advantage of the local infrastructure? Securely??? _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21: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 VAA12447 for ; Mon, 8 Apr 2002 21:21:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28396; Mon, 8 Apr 2002 21:15:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28326 for ; Mon, 8 Apr 2002 21:15:17 -0400 (EDT) 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 VAA12302; Mon, 8 Apr 2002 21:15:14 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391DqI11183; Mon, 8 Apr 2002 18:13:52 -0700 (PDT) Message-ID: <004a01c1df63$9751a070$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49F0@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:12:14 -0700 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 Gary, When you say "handover failure" I think Mobile IP, and there is already some signaling available in FMIPv6/BETH to do this. This signaling does not extend to attributes of the IP service like whether or not the MN can connect to the network, what class of QoS service it gets, and any other security, etc.. There is currently no way to signal that the network expects the MN to reestablish these, except to say that the MN has entered a new AAA domain and should therefore perform network entry from scratch. This seems a little too heavyweight to me. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 1:21 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 15:55 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > As I outlined in one of my other posts, why would you > > perform CT to an > > > AR that did not have the necessary capabilities. Is this actually > > about > > > CAR failure?? > > > > > > > Yes and no. > > > > Suppose the MN is expecting CT to be performed and it is not > > because the > > A nit, but the MN does not expect CT. The MN expects continuous > service (i.e. seamless service), and knows nothing about how it is > supported (it could be provisioned). > > > new AR can't interpret the context. > > The old AR may discover this via CAR, but if there is no way to > > communicate it to the MN, then the MN can't know to perform the > > signaling from scratch on the new AR. One could either inform the MN > > beforehand to do the signaling, as is done with FMIPv6/BETH, or signal > > the MN on the new AR. > > > > For dynamic failures, such as when the AR runs out of Gold Class > > service, the signaling could only be done afterwards. > > I understand these scenarios, but I do not understand what they have > to do with CT. CT has never intended to be an MN signalling protocol. > Let me try a counter example: the service authorization fails. Would > a CT message saying the AA context transfer failed be of much use > to the MN? No, because the problem wasn't with the context, it was with > a disconnect between the service request and authorization profile for > that MN. > > There is a need for a "handover failure" indication message to the > MN (indicating full or partial handover failure), but this message should > be part of a different protocol from CT. > > Gary > > > > > jak > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21: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 VAA12458 for ; Mon, 8 Apr 2002 21:21:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28639 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:21:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28396; Mon, 8 Apr 2002 21:15:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28326 for ; Mon, 8 Apr 2002 21:15:17 -0400 (EDT) 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 VAA12302; Mon, 8 Apr 2002 21:15:14 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391DqI11183; Mon, 8 Apr 2002 18:13:52 -0700 (PDT) Message-ID: <004a01c1df63$9751a070$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49F0@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:12:14 -0700 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 Gary, When you say "handover failure" I think Mobile IP, and there is already some signaling available in FMIPv6/BETH to do this. This signaling does not extend to attributes of the IP service like whether or not the MN can connect to the network, what class of QoS service it gets, and any other security, etc.. There is currently no way to signal that the network expects the MN to reestablish these, except to say that the MN has entered a new AAA domain and should therefore perform network entry from scratch. This seems a little too heavyweight to me. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 1:21 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 15:55 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > As I outlined in one of my other posts, why would you > > perform CT to an > > > AR that did not have the necessary capabilities. Is this actually > > about > > > CAR failure?? > > > > > > > Yes and no. > > > > Suppose the MN is expecting CT to be performed and it is not > > because the > > A nit, but the MN does not expect CT. The MN expects continuous > service (i.e. seamless service), and knows nothing about how it is > supported (it could be provisioned). > > > new AR can't interpret the context. > > The old AR may discover this via CAR, but if there is no way to > > communicate it to the MN, then the MN can't know to perform the > > signaling from scratch on the new AR. One could either inform the MN > > beforehand to do the signaling, as is done with FMIPv6/BETH, or signal > > the MN on the new AR. > > > > For dynamic failures, such as when the AR runs out of Gold Class > > service, the signaling could only be done afterwards. > > I understand these scenarios, but I do not understand what they have > to do with CT. CT has never intended to be an MN signalling protocol. > Let me try a counter example: the service authorization fails. Would > a CT message saying the AA context transfer failed be of much use > to the MN? No, because the problem wasn't with the context, it was with > a disconnect between the service request and authorization profile for > that MN. > > There is a need for a "handover failure" indication message to the > MN (indicating full or partial handover failure), but this message should > be part of a different protocol from CT. > > Gary > > > > > jak > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21:25: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 VAA12693 for ; Mon, 8 Apr 2002 21:25:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28705; Mon, 8 Apr 2002 21:21:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28622 for ; Mon, 8 Apr 2002 21:21:21 -0400 (EDT) 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 VAA12444; Mon, 8 Apr 2002 21:21:18 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391KTI11417; Mon, 8 Apr 2002 18:20:30 -0700 (PDT) Message-ID: <006001c1df64$847e5500$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:18:52 -0700 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 Gary, OK, I think I am beginning to see your point. The CT protocol is just a container, if a particular feature context fails, it is up to the code handling the feature context to actually perform the notification of the MN. The CT code doesn't do particular features. I think there is still the case of a failure in interpretation by the new AR, or even a failure in CT itself, like it got lost on the way. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" ; ; ; Sent: Monday, April 08, 2002 1:30 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > A user starts up an application that requests a "gold service". > The protocol stack (perhaps an NSIS protocol stack) sends in a > request from MN to AN for gold service". A handover occurs, and > (according to your scenario), the QoS context transfer fails (for some > inexplicable reason). Some entity (the CT protocol stack according to > your proposal) sends an indication to the MN that the QoS context transfer > has failed (according to your proposal). How does the MN know what to do > with this notice? The MN has to understand: > > - what a handover is at the IP level > - what an IP context transfer is > - that QoS context is (sometimes) transferred separately from other > context > - what the nature of the failure was, and thus, what action to take. > - how and with what entity to initiate QoS re-negotiation. > > The knowledge for all of the above is either explicitly or implicitly > built into the MN. If the intent were for the MN to receive back a message > that indicating "Gold service not available" then this is simply a session > disconnect. If the intent is for the MN to be told that "the QoS associated > with Gold service" has failed, then the MN has to know that Gold service > is actually a combination of features (AAA, security, HC), and to initiate > negotiation, it has to be able to talk to the individual network entities > - entities which may not even exist within a given network (e.g. a provision > > model). > > So, how is the MN ignorant of CT? Service models? > > Keep in mind, according to the CT requirements, CT does not know what > is contained in the data chunks it transports. Thus, at best, it can > only forward to the MN that data chunk or another, opaque data chunk. > Even this capability is a major modification to what should be > a simple state machine for the CT protocol. > > Gary > > *snip* > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21:25: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 VAA12706 for ; Mon, 8 Apr 2002 21:25:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28952 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:25:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28705; Mon, 8 Apr 2002 21:21:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28622 for ; Mon, 8 Apr 2002 21:21:21 -0400 (EDT) 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 VAA12444; Mon, 8 Apr 2002 21:21:18 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391KTI11417; Mon, 8 Apr 2002 18:20:30 -0700 (PDT) Message-ID: <006001c1df64$847e5500$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:18:52 -0700 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 Gary, OK, I think I am beginning to see your point. The CT protocol is just a container, if a particular feature context fails, it is up to the code handling the feature context to actually perform the notification of the MN. The CT code doesn't do particular features. I think there is still the case of a failure in interpretation by the new AR, or even a failure in CT itself, like it got lost on the way. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" ; ; ; Sent: Monday, April 08, 2002 1:30 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > A user starts up an application that requests a "gold service". > The protocol stack (perhaps an NSIS protocol stack) sends in a > request from MN to AN for gold service". A handover occurs, and > (according to your scenario), the QoS context transfer fails (for some > inexplicable reason). Some entity (the CT protocol stack according to > your proposal) sends an indication to the MN that the QoS context transfer > has failed (according to your proposal). How does the MN know what to do > with this notice? The MN has to understand: > > - what a handover is at the IP level > - what an IP context transfer is > - that QoS context is (sometimes) transferred separately from other > context > - what the nature of the failure was, and thus, what action to take. > - how and with what entity to initiate QoS re-negotiation. > > The knowledge for all of the above is either explicitly or implicitly > built into the MN. If the intent were for the MN to receive back a message > that indicating "Gold service not available" then this is simply a session > disconnect. If the intent is for the MN to be told that "the QoS associated > with Gold service" has failed, then the MN has to know that Gold service > is actually a combination of features (AAA, security, HC), and to initiate > negotiation, it has to be able to talk to the individual network entities > - entities which may not even exist within a given network (e.g. a provision > > model). > > So, how is the MN ignorant of CT? Service models? > > Keep in mind, according to the CT requirements, CT does not know what > is contained in the data chunks it transports. Thus, at best, it can > only forward to the MN that data chunk or another, opaque data chunk. > Even this capability is a major modification to what should be > a simple state machine for the CT protocol. > > Gary > > *snip* > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 21:29: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 VAA12837 for ; Mon, 8 Apr 2002 21:29:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27811; Mon, 8 Apr 2002 21:09:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27676 for ; Mon, 8 Apr 2002 21:09:30 -0400 (EDT) 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 VAA12028; Mon, 8 Apr 2002 21:09:25 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3918SI10963; Mon, 8 Apr 2002 18:08:28 -0700 (PDT) Message-ID: <002b01c1df62$d622f9d0$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49EE@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:06:50 -0700 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 Gary, Well, clearly we have a disagreement here. If it is not the CT protocol, then I do not know how else it should be done. Basically, if the router can't for some reason use the context to complete the handover, I believe it has an obligation to inform the MN so that the MN can recover. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 12:51 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > I agree that the MN must be notified (frankly, ulimitately, the MN > will find out, even without a signalling message). > > I disagree that this has anything to do with the CT protocol. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 14:32 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; Rajeev > > Koodli > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I agree about session establishment, but the fact remains that if > > failure of a context transfer for some reason leaves the MN > > without any > > indication that it should proceed to re-establish the > > feature, then the > > MN can't know when it should redo signaling to set up its new > > state. We > > faced this issue with BETH/FMIPv6 and the solution we found > > there was to > > have routers on the border of a fast handover coverage area inform the > > MN what handover algorithm was supported by routers in the other > > coverage area. While I think this could be done for the cases > > involving > > router configuration, such as where the next access router can't > > interpret the context, I am not so sure about failure due to dynamic > > conditions, such as that the router currently has all its Gold Class > > service bandwidth allocated (a QoS failure). > > > > In any event, I think there is need for some kind of signaling to > > indicate to the MN that context transfer has failed and that the MN > > needs to redo signaling to re-establish feature contexts. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; "Nakhjiri > > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > > > Cc: ; ; > > Sent: Monday, April 08, 2002 11:08 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > James: > > > > > > My main problem with the theme in this discussion is that > > > CT is a context transfer protocol, not a session management > > protocol. > > > In particular, when there are feature context specific issues, it is > > > best to handle session re-establishment/re-negotiation/maintenance > > using > > > the protocol(s) that were designed to set up the services > > in the first > > > place. CT should not be stretched into being a general signalling > > protocol. > > > > > > In addition, there is the perhaps greater argument that the most > > > effective method of correcting handover issues is not through over > > > the air signalling exchanges. Given the nature of the wireless link, > > > it will almost always be faster and always be more cost > > effective, to > > > correct any problems with signalling within the > > infrastructure (if it > > is > > > needed). > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: April 8, 2002 11:42 > > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Madjid, > > > > > > > > The issue isn't reliability, it is whether the target AR can > > interpret > > > > the context intelligably. If not, the MN may need to recover > > > > by actually > > > > re-initializing whatever feature the context was being transfered > > for. > > > > But it cannot do this unless it knows that the CT has failed. > > > > > > > > For some feature contexts, like header compression, this > > > > isn't a problem > > > > because it will re-initialize automatically, but for AAA or QoS it > > > > clearly will be. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 3:00 PM > > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > > to close without any results. People could not agree on the > > > > > reliability needs of CT. We added a reliability mechanism to our > > > > > CT proposal that covered both retransmission and updates. > > > > > > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > > To: Rajeev Koodli > > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > Agree. > > > > > > > > > > But I don't see anything in the CT requirements about > > handling CT > > > > > failure. > > > > > > > > > > ??? > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > Rajeev, > > > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > > notify > > > > the > > > > > MN > > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > > robustness of CT protocol. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "James Kempf" > > > > > > > Cc: "Gary Kenward" ; > > > > > > > ; ; > > > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, > > some kind of > > > > > > > negotiation > > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure > > is needed. > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > > should > > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > > upstream > > > > > > > signaling) > > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS > > negotiation, > > > > > though it > > > > > > > may > > > > > > > > > be useful for finding a new wireless medium. I > > also see it > > > > > primarily > > > > > > > for > > > > > > > > > intertechnology handover, or, at best, > > > > interprovider handover. > > > > > > > > > > > > > > > > > > jak > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Rajeev Koodli" > > > > > > > > > To: "Gary Kenward" > > > > > > > > > Cc: ; ; > > > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after > > handover, > > > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state > > at the AR > > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > > may > > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > > establishment > > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > > one of the > > > > > > > > > > parameters that might then be fed to a selection > > > > algorithm. > > > > > Any > > > > > > > > > > signaling for actually establishing QoS itself > > > > beyond the AR > > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > > understand CARD > > > > > (and > > > > > > > > > > > I don't understand it well), it is not a QoS > > negotiation > > > > > > > > > > > protocol. The main application that you are > > referring > > to > > > > > > > primarily > > > > > > > > > > > arises out of a perceived need to determine at > > > > the MN the > > > > > best > > > > > > > link > > > > > > > > > > > layer to handover over to when inter-technology > > > > handovers > > > > > are > > > > > > > > > > > involved. > > > > > > > > > > > It can be applied to intra-technology handovers, but > > the > > > > > value > > > > > > > in > > > > > > > > > > > that situation is highly questionable (e.g. > > > > since it is a > > > > > > > discovery > > > > > > > > > > > protocol, the implication is that the purpose is to > > > > > determine > > > > > > > the > > > > > > > > > > > choice of channels available; for intra-technology > > > > > handovers, > > > > > > > there > > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > > available). > > > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > > imply NSIS > > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > > this is not > > > > > the > > > > > > > > > > > intention > > > > > > > > > > > (please correct me if I have this wrong John), in > > which > > > > case > > > > > I > > > > > > > think > > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS > > > > for > > > > > an > > > > > > > > > > > existing flow after a handover, or is it > > > > specifically for > > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > > boolean: > > > > the > > > > > > > role > > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > > believe, > > > > and > > > > > > > clearly > > > > > > > > > > > handover is a dynamic situation that could cause the > > QoS > > > > > > > provided to > > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > > frightening > > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > > transfer has > > > > > been > > > > > > > used > > > > > > > > > > > to > > > > > > > > > > > move the QoS context to the new > > routers (by the > > > > > > > requirements > > > > > > > > > > > for > > > > > > > > > > > CT this could be intra-, or inter- > > > > technology. Some > > > > > of us > > > > > > > > > > > believe > > > > > > > > > > > that for "seamless" handovers, the > > > > context will be > > > > > > > available > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > > forwarded. > > > > > > > This > > > > > > > > > > > implies > > > > > > > > > > > that there is a relationship, probabilistic > > > > perhaps, > > > > > > > between > > > > > > > > > > > the handover process and the target > > ARs for CT. > > > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > > handover > > > > > decision > > > > > > > (it > > > > > > > > > > > is not clear to me how this happens, but it > > seems > > > > > clear > > > > > > > that > > > > > > > > > > > for a more "seamless" handover, the MN > > > > should chose > > > > > an AR > > > > > > > > > that > > > > > > > > > > > has received the appropriate context; if > > > > not, then > > > > > what? > > > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > > QoS because > > > > > of > > > > > > > > > changes > > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > > predictable > > > > > > > > > > > outcomes? > > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > > entities > > > > > > > > > > > associated > > > > > > > > > > > with the three protocols interact before, > > > > during and after > > > > a > > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > > entities, > > > > the > > > > > > > > > > > respective > > > > > > > > > > > wg's could declare the issue out of scope, but this > > > > approach > > > > > > > does > > > > > > > > > not > > > > > > > > > > > sit well with me, for it seems to defer the > > > > problem to the > > > > > > > people > > > > > > > > > who > > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to > > > > > whether > > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > > Seamoby (CAR > > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > > and not NSIS. > > > > > CAR > > > > > > > > > > > > discovery is supposed to identify candidate access > > > > routers > > > > > > > > > > > > for handoff and QoS is an important property for > > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > > be concerned > > > > > with > > > > > > > the > > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > > draft. > > > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > > concerned > > > > > > > > > > > > with activity > > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 21:29: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 VAA12856 for ; Mon, 8 Apr 2002 21:29:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29136 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 21:29:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27811; Mon, 8 Apr 2002 21:09:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27676 for ; Mon, 8 Apr 2002 21:09:30 -0400 (EDT) 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 VAA12028; Mon, 8 Apr 2002 21:09:25 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3918SI10963; Mon, 8 Apr 2002 18:08:28 -0700 (PDT) Message-ID: <002b01c1df62$d622f9d0$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49EE@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:06:50 -0700 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 Gary, Well, clearly we have a disagreement here. If it is not the CT protocol, then I do not know how else it should be done. Basically, if the router can't for some reason use the context to complete the handover, I believe it has an obligation to inform the MN so that the MN can recover. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 12:51 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > I agree that the MN must be notified (frankly, ulimitately, the MN > will find out, even without a signalling message). > > I disagree that this has anything to do with the CT protocol. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 14:32 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; Rajeev > > Koodli > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I agree about session establishment, but the fact remains that if > > failure of a context transfer for some reason leaves the MN > > without any > > indication that it should proceed to re-establish the > > feature, then the > > MN can't know when it should redo signaling to set up its new > > state. We > > faced this issue with BETH/FMIPv6 and the solution we found > > there was to > > have routers on the border of a fast handover coverage area inform the > > MN what handover algorithm was supported by routers in the other > > coverage area. While I think this could be done for the cases > > involving > > router configuration, such as where the next access router can't > > interpret the context, I am not so sure about failure due to dynamic > > conditions, such as that the router currently has all its Gold Class > > service bandwidth allocated (a QoS failure). > > > > In any event, I think there is need for some kind of signaling to > > indicate to the MN that context transfer has failed and that the MN > > needs to redo signaling to re-establish feature contexts. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; "Nakhjiri > > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > > > Cc: ; ; > > Sent: Monday, April 08, 2002 11:08 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > James: > > > > > > My main problem with the theme in this discussion is that > > > CT is a context transfer protocol, not a session management > > protocol. > > > In particular, when there are feature context specific issues, it is > > > best to handle session re-establishment/re-negotiation/maintenance > > using > > > the protocol(s) that were designed to set up the services > > in the first > > > place. CT should not be stretched into being a general signalling > > protocol. > > > > > > In addition, there is the perhaps greater argument that the most > > > effective method of correcting handover issues is not through over > > > the air signalling exchanges. Given the nature of the wireless link, > > > it will almost always be faster and always be more cost > > effective, to > > > correct any problems with signalling within the > > infrastructure (if it > > is > > > needed). > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: April 8, 2002 11:42 > > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Madjid, > > > > > > > > The issue isn't reliability, it is whether the target AR can > > interpret > > > > the context intelligably. If not, the MN may need to recover > > > > by actually > > > > re-initializing whatever feature the context was being transfered > > for. > > > > But it cannot do this unless it knows that the CT has failed. > > > > > > > > For some feature contexts, like header compression, this > > > > isn't a problem > > > > because it will re-initialize automatically, but for AAA or QoS it > > > > clearly will be. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 3:00 PM > > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > > to close without any results. People could not agree on the > > > > > reliability needs of CT. We added a reliability mechanism to our > > > > > CT proposal that covered both retransmission and updates. > > > > > > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > > To: Rajeev Koodli > > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > Agree. > > > > > > > > > > But I don't see anything in the CT requirements about > > handling CT > > > > > failure. > > > > > > > > > > ??? > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > Rajeev, > > > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > > notify > > > > the > > > > > MN > > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > > robustness of CT protocol. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "James Kempf" > > > > > > > Cc: "Gary Kenward" ; > > > > > > > ; ; > > > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, > > some kind of > > > > > > > negotiation > > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure > > is needed. > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > > should > > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > > upstream > > > > > > > signaling) > > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS > > negotiation, > > > > > though it > > > > > > > may > > > > > > > > > be useful for finding a new wireless medium. I > > also see it > > > > > primarily > > > > > > > for > > > > > > > > > intertechnology handover, or, at best, > > > > interprovider handover. > > > > > > > > > > > > > > > > > > jak > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Rajeev Koodli" > > > > > > > > > To: "Gary Kenward" > > > > > > > > > Cc: ; ; > > > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after > > handover, > > > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state > > at the AR > > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > > may > > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > > establishment > > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > > one of the > > > > > > > > > > parameters that might then be fed to a selection > > > > algorithm. > > > > > Any > > > > > > > > > > signaling for actually establishing QoS itself > > > > beyond the AR > > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > > understand CARD > > > > > (and > > > > > > > > > > > I don't understand it well), it is not a QoS > > negotiation > > > > > > > > > > > protocol. The main application that you are > > referring > > to > > > > > > > primarily > > > > > > > > > > > arises out of a perceived need to determine at > > > > the MN the > > > > > best > > > > > > > link > > > > > > > > > > > layer to handover over to when inter-technology > > > > handovers > > > > > are > > > > > > > > > > > involved. > > > > > > > > > > > It can be applied to intra-technology handovers, but > > the > > > > > value > > > > > > > in > > > > > > > > > > > that situation is highly questionable (e.g. > > > > since it is a > > > > > > > discovery > > > > > > > > > > > protocol, the implication is that the purpose is to > > > > > determine > > > > > > > the > > > > > > > > > > > choice of channels available; for intra-technology > > > > > handovers, > > > > > > > there > > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > > available). > > > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > > imply NSIS > > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > > this is not > > > > > the > > > > > > > > > > > intention > > > > > > > > > > > (please correct me if I have this wrong John), in > > which > > > > case > > > > > I > > > > > > > think > > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS > > > > for > > > > > an > > > > > > > > > > > existing flow after a handover, or is it > > > > specifically for > > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > > boolean: > > > > the > > > > > > > role > > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > > believe, > > > > and > > > > > > > clearly > > > > > > > > > > > handover is a dynamic situation that could cause the > > QoS > > > > > > > provided to > > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > > frightening > > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > > transfer has > > > > > been > > > > > > > used > > > > > > > > > > > to > > > > > > > > > > > move the QoS context to the new > > routers (by the > > > > > > > requirements > > > > > > > > > > > for > > > > > > > > > > > CT this could be intra-, or inter- > > > > technology. Some > > > > > of us > > > > > > > > > > > believe > > > > > > > > > > > that for "seamless" handovers, the > > > > context will be > > > > > > > available > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > > forwarded. > > > > > > > This > > > > > > > > > > > implies > > > > > > > > > > > that there is a relationship, probabilistic > > > > perhaps, > > > > > > > between > > > > > > > > > > > the handover process and the target > > ARs for CT. > > > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > > handover > > > > > decision > > > > > > > (it > > > > > > > > > > > is not clear to me how this happens, but it > > seems > > > > > clear > > > > > > > that > > > > > > > > > > > for a more "seamless" handover, the MN > > > > should chose > > > > > an AR > > > > > > > > > that > > > > > > > > > > > has received the appropriate context; if > > > > not, then > > > > > what? > > > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > > QoS because > > > > > of > > > > > > > > > changes > > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > > predictable > > > > > > > > > > > outcomes? > > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > > entities > > > > > > > > > > > associated > > > > > > > > > > > with the three protocols interact before, > > > > during and after > > > > a > > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > > entities, > > > > the > > > > > > > > > > > respective > > > > > > > > > > > wg's could declare the issue out of scope, but this > > > > approach > > > > > > > does > > > > > > > > > not > > > > > > > > > > > sit well with me, for it seems to defer the > > > > problem to the > > > > > > > people > > > > > > > > > who > > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to > > > > > whether > > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > > Seamoby (CAR > > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > > and not NSIS. > > > > > CAR > > > > > > > > > > > > discovery is supposed to identify candidate access > > > > routers > > > > > > > > > > > > for handoff and QoS is an important property for > > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > > be concerned > > > > > with > > > > > > > the > > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > > draft. > > > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > > concerned > > > > > > > > > > > > with activity > > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 8 22:10: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 WAA14350 for ; Mon, 8 Apr 2002 22:10:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00642; Mon, 8 Apr 2002 21:59:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00610 for ; Mon, 8 Apr 2002 21:58:57 -0400 (EDT) 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 VAA14191; Mon, 8 Apr 2002 21:58:54 -0400 (EDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391vWI12818; Mon, 8 Apr 2002 18:57:32 -0700 (PDT) Message-ID: <011201c1df69$b147fe10$ab6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> <006501c1df60$bc502cf0$0902a8c0@Study> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:55:54 -0700 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, > > Gary, > > > > I don't think the issue is having the MN re-create the context. Is is > > allowing the MN to recover by re-running the actions that were necessary > > to create the context in the first place, in the event the AR was unable > > to interpret it. > > Don't you agree that there will need to be several target ARs all receiving > the context > simultaneously, possibly via an anycast addressing structure? > Sure, in IPv6. But there is still no guarantee that the transfer will succeed. > > > Thus, for example, suppose that QoS context is transferred from old to > > new AR, but new AR for some reason can't interpret it, perhaps there is > > no bandwidth left or perhaps the new AR uses a different representation > > for QoS context. The MN would need to be informed somehow so that it > > could re-do its QoS signaling. > > Reword as, for example, suppose that QoS context is transferred to "a newly > added AR", but the new AR can not interpret it. The MN could choose to skip > using this AR completely. > Right, but it would have to know that so it could move to a different AR (if it had a choice). jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 8 22:10: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 WAA14360 for ; Mon, 8 Apr 2002 22:10:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01574 for seamoby-archive@odin.ietf.org; Mon, 8 Apr 2002 22:11:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00642; Mon, 8 Apr 2002 21:59:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00610 for ; Mon, 8 Apr 2002 21:58:57 -0400 (EDT) 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 VAA14191; Mon, 8 Apr 2002 21:58:54 -0400 (EDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391vWI12818; Mon, 8 Apr 2002 18:57:32 -0700 (PDT) Message-ID: <011201c1df69$b147fe10$ab6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> <006501c1df60$bc502cf0$0902a8c0@Study> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:55:54 -0700 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, > > Gary, > > > > I don't think the issue is having the MN re-create the context. Is is > > allowing the MN to recover by re-running the actions that were necessary > > to create the context in the first place, in the event the AR was unable > > to interpret it. > > Don't you agree that there will need to be several target ARs all receiving > the context > simultaneously, possibly via an anycast addressing structure? > Sure, in IPv6. But there is still no guarantee that the transfer will succeed. > > > Thus, for example, suppose that QoS context is transferred from old to > > new AR, but new AR for some reason can't interpret it, perhaps there is > > no bandwidth left or perhaps the new AR uses a different representation > > for QoS context. The MN would need to be informed somehow so that it > > could re-do its QoS signaling. > > Reword as, for example, suppose that QoS context is transferred to "a newly > added AR", but the new AR can not interpret it. The MN could choose to skip > using this AR completely. > Right, but it would have to know that so it could move to a different AR (if it had a choice). jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 14:05: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 OAA14531 for ; Tue, 9 Apr 2002 14:05:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08425; Tue, 9 Apr 2002 13:56:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08366 for ; Tue, 9 Apr 2002 13:56:41 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14248; Tue, 9 Apr 2002 13:56:38 -0400 (EDT) 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 g39Htog03427; Tue, 9 Apr 2002 13:55:50 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 13:55:50 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A01@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: "'nsis@ietf.org'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 13:55:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFEF.C7DF5688" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFEF.C7DF5688 Content-Type: text/plain; charset="iso-8859-1" Charlie: Thanks for the $0.02. Some comments/questions: > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 8, 2002 17:58 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello Gary, > > I have $0.02 to add to the discussion: > > > Can anyone offer an explaining of how or why CT would add > significantly > > to the already unreliable physics of handover? > > Since I took physics in college, I can answer this. It would not > add significantly to handover unreliability. Then why should we worry about it? The ultimate question is, given that you detect a failure, can you make a significant improvement on the handover performance? > > > What failure modes for CT would be noticeable above the unavoidable > > rate of handover failures due the vagaries of wireless coverage and > > wireless link layer performance???? > > Congestion at intermediate routing points comes to mind. > Just because two access points are both within range of a mobile node > does not mean that they are neighbors to each other. They may even > be attached to completely different physical media. Could you not avoid this with traffic engineering? It would seem to me to be a bad choice, regardless, to throw your CT traffic in with your BE traffic. The impact on delay of transfer alone would be enough reason to provide special treatment for CT. And, if the CT is failing because of congestion, why would any signalling messages indicating failure and attempting recovery not also be congested? > > > If CT fails, then the handover fails. It is that simple. If CT were > > to fail with every 2nd handover attempt, then there would > be a problem. > > I quite disagree with this statement. It depends on very many things. > For instance, we have to be able to run CT without CARD. So, the > destination access router might not offer header compression at all, > for instance. Thus, the handover would succeed, but the > context transfer > (or, part of it) would fail. Ok. I wasn't clear. I did not mean to imply that all handovers require CT. I meant that if a handover of a flow requires context to work, and the CT fails, then the flow handover fails. Since this is, as you agree, a rare event insignificant amongst all the other reasons handovers fail, why worry about it? > > > But, I cannot seriously see CT failing more then every one > in a million > > handover attempts, or less. > > Cool! This could be good news. I am as nervous as anyone in pushing requirements onto the people who engineer a working network. There job is hard enough. However, I just do not see running signalling and signalling related traffic such as CT, through the same congested paths as BE traffic. Even for wireless ad-hoc networks, I would presume that there will be a need identified for some special traffic treatment over the air to facilitate signalling between nodes. > > > CT should not be attempted if there is an incompatibility > between source > > and destination ARs. > > As noted above, I quite disagree with this statement. I don't see the relationship between your disagreement and your notes above. If CARD is present, then the network should know ahead of time what the capabilities of a target router are, and what mitigating action needs to be taken to effect a useful CT. If CARD is not present, then the solution is to configure the network appropriately. This may include facilities at ARs for context translation ("may" - I think this is getting ahead of the current state of the art). The only other scenario I can think of is where the network configuration is dynamic, and thus the capabilities of the ARs can change dynamically. This is one reason why I mentioned wireless ad-hoc networks. It is not clear to me that we should be attempting to solve this very complex problem within SEAMOBY, as there are any number of assumptions that must be made to make the problem tractable. > > > And, I HAD thought that it was the > purpose of CAR > > to identify those incompatibilities and thus avoid doing CT > when it is > > clear it would fail. > > But, we have to be allowed to do CT without ever running CARD. > For instance, we have reactive mode. Reactive mode does not mean no CARD. What you are suggesting is a collection of ARs with different capabilities, unknown during configuration time, and where CARD is not used. I would propose that this is an unrealistic scenario. Said another way, I propose that if the capabilities of the ARs are known and unchanging, the network can be engineered for CT without CARD to work. Note that this statement applies to wireless ad-hoc networks and mobile ARs as well as fixed, wired ARs. If the capabilities of the ARs at the time of a handover are not pre-determinable, then I suggest that this is where CARD is used with the greatest import. Any other scenarios can be deemed poor network engineering practice. > > > How to mitigate those incompatibles is not a > > CT issue, it is a service adaptation issue, which can be resolved in > > a number of ways, some of which would imply signalled > negotiation either > > between the ARs or between the ARs and the MN. > > Sometimes, the service cannot be adapted, and the feature context is > just plain lost, because the feature is unavailable. > Suppose, for example, > that the contexts transferred include header compression, > QoS, security, > and other features. Now suppose that _only_ the security > context can be > transferred. That's still better than nothing! Maybe the > QoS application > will have to terminate, or go into degraded mode, but the > other applications > that need security will still be able to go on undisturbed. Why not? Sure, but what does this have to do with CT? There may be many reasons why a particular feature might fail, including malformed, missing or incompatible context. My position is this is not a ct issue, but rather an issue with the service entities themselves, which may mean the service entities perform some mitigating action, including informing the MN. Example: if the security context transfer fails, should a CT entity inform the MN, or should it be the responsibility of the security service entities? I think the latter. > > Regards, > Charlie P. > > PS. I relucantly left NSIS on the CC: list, but shouldn't it > be pruned? Perhaps. I haven't seen any complaints from NSIS as yet. I think some of us are trying to figure out what the respective roles of each protocol are and, most important, the inter-relationships. E.g. if QoS re-negotiation is to happen as a result of handover, in my view, it makes sense that we should use the capabilities of the NSIS protocol to do this re-negotiation, rather then replicate similar functionality in CARD or CT. The difficulty I suspect with this, is that none of the protocols exist yet, so it is hard for many of us to see what the trade-offs are. Perhaps the answer is to decide now where the divisions between the problem spaces (via requirements and objectives), and worry about trade-offs later. (Requirements drafts are not legal documents: they can be revised with sufficient reason.) Cheers, Gary > ------_=_NextPart_001_01C1DFEF.C7DF5688 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Charlie:

 Thanks for the $0.02. Some comments/questions:

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 8, 2002 17:58
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Hello Gary,
>
> I have $0.02 to add to the discussion:
>
> > Can anyone offer an explaining of how or why CT would add
> significantly
> > to the already unreliable physics of handover?
>
> Since I took physics in college, I can answer this.  It would not
> add significantly to handover unreliability.

Then why should we worry about it? The ultimate question is, given
that you detect a failure, can you make a significant improvement
on the handover performance?

>
> > What failure modes for CT would be noticeable above the unavoidable
> > rate of handover failures due the vagaries of wireless coverage and
> > wireless link layer performance????
>
> Congestion at intermediate routing points comes to mind.
> Just because two access points are both within range of a mobile node
> does not mean that they are neighbors to each other.  They may even
> be attached to completely different physical media.

Could you not avoid this with traffic engineering? It would seem to me
to be a bad choice, regardless, to throw your CT traffic in with your
BE traffic. The impact on delay of transfer alone would be enough reason
to provide special treatment for CT. And, if the CT is failing because
of congestion, why would any signalling messages indicating failure and
attempting recovery not also be congested?

>
> > If CT fails, then the handover fails. It is that simple. If CT were
> > to fail with every 2nd handover attempt, then there would
> be a problem.
>
> I quite disagree with this statement.  It depends on very many things.
> For instance, we have to be able to run CT without CARD.  So, the
> destination access router might not offer header compression at all,
> for instance.  Thus, the handover would succeed, but the
> context transfer
> (or, part of it) would fail.

Ok. I wasn't clear. I did not mean to imply that all handovers require CT.
I meant that if a handover of a flow requires context to work, and the
CT fails, then the flow handover fails. Since this is, as you agree, a
rare event insignificant amongst all the other reasons handovers fail,
why worry about it?

>
> > But, I cannot seriously see CT failing more then every one
> in a million
> > handover attempts, or less.
>
> Cool!  This could be good news.

I am as nervous as anyone in pushing requirements onto the people
who engineer a working network. There job is hard enough. However,
I just do not see running signalling and signalling related traffic
such as CT, through the same congested paths as BE traffic. Even for
wireless ad-hoc networks, I would presume that there will be a need
identified for some special traffic treatment over the air to facilitate
signalling between nodes.

>
> > CT should not be attempted if there is an incompatibility
> between source
> > and destination ARs.
>
> As noted above, I quite disagree with this statement.

I don't see the relationship between your disagreement and
your notes above.

If CARD is present, then the network should know ahead of time
what the capabilities of a target router are, and what mitigating
action needs to be taken to effect a useful CT.

If CARD is not present, then the solution is to configure the
network appropriately. This may include facilities at ARs
for context translation ("may" - I think this is getting ahead
of the current state of the art).

The only other scenario I can think of is where the network configuration
is dynamic, and thus the capabilities of the ARs can change dynamically.
This is one reason why I mentioned wireless ad-hoc networks. It is not
clear to me that we should be attempting to solve this very complex
problem within SEAMOBY, as there are any number of assumptions that
must be made to make the problem tractable.

>
> >                       And, I HAD thought that it was the
> purpose of CAR
> > to identify those incompatibilities and thus avoid doing CT
> when it is
> > clear it would fail.
>
> But, we have to be allowed to do CT without ever running CARD.
> For instance, we have reactive mode.

Reactive mode does not mean no CARD.

What you are suggesting is a collection of ARs with different capabilities,
unknown during configuration time, and where CARD is not used. I would propose
that this is an unrealistic scenario.

Said another way, I propose that if the capabilities of the ARs are known
and unchanging, the network can be engineered for CT without CARD to work.
Note that this statement applies to wireless ad-hoc networks and mobile
ARs as well as fixed, wired ARs.

If the capabilities of the ARs at the time of a handover are not pre-determinable,
then I suggest that this is where CARD is used with the greatest import.

Any other scenarios can be deemed poor network engineering practice.

>
> >                        How to mitigate those incompatibles is not a
> > CT issue, it is a service adaptation issue, which can be resolved in
> > a number of ways, some of which would imply signalled
> negotiation either
> > between the ARs or between the ARs and the MN.
>
> Sometimes, the service cannot be adapted, and the feature context is
> just plain lost, because the feature is unavailable. 
> Suppose, for example,
> that the contexts transferred include header compression,
> QoS, security,
> and other features.  Now suppose that _only_ the security
> context can be
> transferred.  That's still better than nothing!  Maybe the
> QoS application
> will have to terminate, or go into degraded mode, but the
> other applications
> that need security will still be able to go on undisturbed.  Why not?

Sure, but what does this have to do with CT? There may be many reasons
why a particular feature might fail, including malformed, missing or
incompatible context. My position is this is not a ct issue, but rather
an issue with the service entities themselves, which may mean the service
entities perform some mitigating action, including informing the MN.

Example: if the security context transfer fails, should a CT entity inform
the MN, or should it be the responsibility of the security service entities?
I think the latter.

>
> Regards,
> Charlie P.
>
> PS. I relucantly left NSIS on the CC: list, but shouldn't it
> be pruned?

Perhaps. I haven't seen any complaints from NSIS as yet. I think some of
us are trying to figure out what the respective roles of each protocol are
and, most important, the inter-relationships. E.g. if QoS re-negotiation is
to happen as a result of handover, in my view, it makes sense that we should
use the capabilities of the NSIS protocol to do this re-negotiation, rather
then replicate similar functionality in CARD or CT. The difficulty I suspect
with this, is that none of the protocols exist yet, so it is hard for many
of us to see what the trade-offs are.

Perhaps the answer is to decide now where the divisions between the problem
spaces (via requirements and objectives), and worry about trade-offs later.
(Requirements drafts are not legal documents: they can be revised with sufficient
reason.)

Cheers,
Gary
>

------_=_NextPart_001_01C1DFEF.C7DF5688-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 14:05: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 OAA14546 for ; Tue, 9 Apr 2002 14:05:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09545 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 14:05:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08425; Tue, 9 Apr 2002 13:56:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08366 for ; Tue, 9 Apr 2002 13:56:41 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14248; Tue, 9 Apr 2002 13:56:38 -0400 (EDT) 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 g39Htog03427; Tue, 9 Apr 2002 13:55:50 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 13:55:50 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A01@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: "'nsis@ietf.org'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 13:55:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFEF.C7DF5688" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFEF.C7DF5688 Content-Type: text/plain; charset="iso-8859-1" Charlie: Thanks for the $0.02. Some comments/questions: > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 8, 2002 17:58 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello Gary, > > I have $0.02 to add to the discussion: > > > Can anyone offer an explaining of how or why CT would add > significantly > > to the already unreliable physics of handover? > > Since I took physics in college, I can answer this. It would not > add significantly to handover unreliability. Then why should we worry about it? The ultimate question is, given that you detect a failure, can you make a significant improvement on the handover performance? > > > What failure modes for CT would be noticeable above the unavoidable > > rate of handover failures due the vagaries of wireless coverage and > > wireless link layer performance???? > > Congestion at intermediate routing points comes to mind. > Just because two access points are both within range of a mobile node > does not mean that they are neighbors to each other. They may even > be attached to completely different physical media. Could you not avoid this with traffic engineering? It would seem to me to be a bad choice, regardless, to throw your CT traffic in with your BE traffic. The impact on delay of transfer alone would be enough reason to provide special treatment for CT. And, if the CT is failing because of congestion, why would any signalling messages indicating failure and attempting recovery not also be congested? > > > If CT fails, then the handover fails. It is that simple. If CT were > > to fail with every 2nd handover attempt, then there would > be a problem. > > I quite disagree with this statement. It depends on very many things. > For instance, we have to be able to run CT without CARD. So, the > destination access router might not offer header compression at all, > for instance. Thus, the handover would succeed, but the > context transfer > (or, part of it) would fail. Ok. I wasn't clear. I did not mean to imply that all handovers require CT. I meant that if a handover of a flow requires context to work, and the CT fails, then the flow handover fails. Since this is, as you agree, a rare event insignificant amongst all the other reasons handovers fail, why worry about it? > > > But, I cannot seriously see CT failing more then every one > in a million > > handover attempts, or less. > > Cool! This could be good news. I am as nervous as anyone in pushing requirements onto the people who engineer a working network. There job is hard enough. However, I just do not see running signalling and signalling related traffic such as CT, through the same congested paths as BE traffic. Even for wireless ad-hoc networks, I would presume that there will be a need identified for some special traffic treatment over the air to facilitate signalling between nodes. > > > CT should not be attempted if there is an incompatibility > between source > > and destination ARs. > > As noted above, I quite disagree with this statement. I don't see the relationship between your disagreement and your notes above. If CARD is present, then the network should know ahead of time what the capabilities of a target router are, and what mitigating action needs to be taken to effect a useful CT. If CARD is not present, then the solution is to configure the network appropriately. This may include facilities at ARs for context translation ("may" - I think this is getting ahead of the current state of the art). The only other scenario I can think of is where the network configuration is dynamic, and thus the capabilities of the ARs can change dynamically. This is one reason why I mentioned wireless ad-hoc networks. It is not clear to me that we should be attempting to solve this very complex problem within SEAMOBY, as there are any number of assumptions that must be made to make the problem tractable. > > > And, I HAD thought that it was the > purpose of CAR > > to identify those incompatibilities and thus avoid doing CT > when it is > > clear it would fail. > > But, we have to be allowed to do CT without ever running CARD. > For instance, we have reactive mode. Reactive mode does not mean no CARD. What you are suggesting is a collection of ARs with different capabilities, unknown during configuration time, and where CARD is not used. I would propose that this is an unrealistic scenario. Said another way, I propose that if the capabilities of the ARs are known and unchanging, the network can be engineered for CT without CARD to work. Note that this statement applies to wireless ad-hoc networks and mobile ARs as well as fixed, wired ARs. If the capabilities of the ARs at the time of a handover are not pre-determinable, then I suggest that this is where CARD is used with the greatest import. Any other scenarios can be deemed poor network engineering practice. > > > How to mitigate those incompatibles is not a > > CT issue, it is a service adaptation issue, which can be resolved in > > a number of ways, some of which would imply signalled > negotiation either > > between the ARs or between the ARs and the MN. > > Sometimes, the service cannot be adapted, and the feature context is > just plain lost, because the feature is unavailable. > Suppose, for example, > that the contexts transferred include header compression, > QoS, security, > and other features. Now suppose that _only_ the security > context can be > transferred. That's still better than nothing! Maybe the > QoS application > will have to terminate, or go into degraded mode, but the > other applications > that need security will still be able to go on undisturbed. Why not? Sure, but what does this have to do with CT? There may be many reasons why a particular feature might fail, including malformed, missing or incompatible context. My position is this is not a ct issue, but rather an issue with the service entities themselves, which may mean the service entities perform some mitigating action, including informing the MN. Example: if the security context transfer fails, should a CT entity inform the MN, or should it be the responsibility of the security service entities? I think the latter. > > Regards, > Charlie P. > > PS. I relucantly left NSIS on the CC: list, but shouldn't it > be pruned? Perhaps. I haven't seen any complaints from NSIS as yet. I think some of us are trying to figure out what the respective roles of each protocol are and, most important, the inter-relationships. E.g. if QoS re-negotiation is to happen as a result of handover, in my view, it makes sense that we should use the capabilities of the NSIS protocol to do this re-negotiation, rather then replicate similar functionality in CARD or CT. The difficulty I suspect with this, is that none of the protocols exist yet, so it is hard for many of us to see what the trade-offs are. Perhaps the answer is to decide now where the divisions between the problem spaces (via requirements and objectives), and worry about trade-offs later. (Requirements drafts are not legal documents: they can be revised with sufficient reason.) Cheers, Gary > ------_=_NextPart_001_01C1DFEF.C7DF5688 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Charlie:

 Thanks for the $0.02. Some comments/questions:

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 8, 2002 17:58
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Hello Gary,
>
> I have $0.02 to add to the discussion:
>
> > Can anyone offer an explaining of how or why CT would add
> significantly
> > to the already unreliable physics of handover?
>
> Since I took physics in college, I can answer this.  It would not
> add significantly to handover unreliability.

Then why should we worry about it? The ultimate question is, given
that you detect a failure, can you make a significant improvement
on the handover performance?

>
> > What failure modes for CT would be noticeable above the unavoidable
> > rate of handover failures due the vagaries of wireless coverage and
> > wireless link layer performance????
>
> Congestion at intermediate routing points comes to mind.
> Just because two access points are both within range of a mobile node
> does not mean that they are neighbors to each other.  They may even
> be attached to completely different physical media.

Could you not avoid this with traffic engineering? It would seem to me
to be a bad choice, regardless, to throw your CT traffic in with your
BE traffic. The impact on delay of transfer alone would be enough reason
to provide special treatment for CT. And, if the CT is failing because
of congestion, why would any signalling messages indicating failure and
attempting recovery not also be congested?

>
> > If CT fails, then the handover fails. It is that simple. If CT were
> > to fail with every 2nd handover attempt, then there would
> be a problem.
>
> I quite disagree with this statement.  It depends on very many things.
> For instance, we have to be able to run CT without CARD.  So, the
> destination access router might not offer header compression at all,
> for instance.  Thus, the handover would succeed, but the
> context transfer
> (or, part of it) would fail.

Ok. I wasn't clear. I did not mean to imply that all handovers require CT.
I meant that if a handover of a flow requires context to work, and the
CT fails, then the flow handover fails. Since this is, as you agree, a
rare event insignificant amongst all the other reasons handovers fail,
why worry about it?

>
> > But, I cannot seriously see CT failing more then every one
> in a million
> > handover attempts, or less.
>
> Cool!  This could be good news.

I am as nervous as anyone in pushing requirements onto the people
who engineer a working network. There job is hard enough. However,
I just do not see running signalling and signalling related traffic
such as CT, through the same congested paths as BE traffic. Even for
wireless ad-hoc networks, I would presume that there will be a need
identified for some special traffic treatment over the air to facilitate
signalling between nodes.

>
> > CT should not be attempted if there is an incompatibility
> between source
> > and destination ARs.
>
> As noted above, I quite disagree with this statement.

I don't see the relationship between your disagreement and
your notes above.

If CARD is present, then the network should know ahead of time
what the capabilities of a target router are, and what mitigating
action needs to be taken to effect a useful CT.

If CARD is not present, then the solution is to configure the
network appropriately. This may include facilities at ARs
for context translation ("may" - I think this is getting ahead
of the current state of the art).

The only other scenario I can think of is where the network configuration
is dynamic, and thus the capabilities of the ARs can change dynamically.
This is one reason why I mentioned wireless ad-hoc networks. It is not
clear to me that we should be attempting to solve this very complex
problem within SEAMOBY, as there are any number of assumptions that
must be made to make the problem tractable.

>
> >                       And, I HAD thought that it was the
> purpose of CAR
> > to identify those incompatibilities and thus avoid doing CT
> when it is
> > clear it would fail.
>
> But, we have to be allowed to do CT without ever running CARD.
> For instance, we have reactive mode.

Reactive mode does not mean no CARD.

What you are suggesting is a collection of ARs with different capabilities,
unknown during configuration time, and where CARD is not used. I would propose
that this is an unrealistic scenario.

Said another way, I propose that if the capabilities of the ARs are known
and unchanging, the network can be engineered for CT without CARD to work.
Note that this statement applies to wireless ad-hoc networks and mobile
ARs as well as fixed, wired ARs.

If the capabilities of the ARs at the time of a handover are not pre-determinable,
then I suggest that this is where CARD is used with the greatest import.

Any other scenarios can be deemed poor network engineering practice.

>
> >                        How to mitigate those incompatibles is not a
> > CT issue, it is a service adaptation issue, which can be resolved in
> > a number of ways, some of which would imply signalled
> negotiation either
> > between the ARs or between the ARs and the MN.
>
> Sometimes, the service cannot be adapted, and the feature context is
> just plain lost, because the feature is unavailable. 
> Suppose, for example,
> that the contexts transferred include header compression,
> QoS, security,
> and other features.  Now suppose that _only_ the security
> context can be
> transferred.  That's still better than nothing!  Maybe the
> QoS application
> will have to terminate, or go into degraded mode, but the
> other applications
> that need security will still be able to go on undisturbed.  Why not?

Sure, but what does this have to do with CT? There may be many reasons
why a particular feature might fail, including malformed, missing or
incompatible context. My position is this is not a ct issue, but rather
an issue with the service entities themselves, which may mean the service
entities perform some mitigating action, including informing the MN.

Example: if the security context transfer fails, should a CT entity inform
the MN, or should it be the responsibility of the security service entities?
I think the latter.

>
> Regards,
> Charlie P.
>
> PS. I relucantly left NSIS on the CC: list, but shouldn't it
> be pruned?

Perhaps. I haven't seen any complaints from NSIS as yet. I think some of
us are trying to figure out what the respective roles of each protocol are
and, most important, the inter-relationships. E.g. if QoS re-negotiation is
to happen as a result of handover, in my view, it makes sense that we should
use the capabilities of the NSIS protocol to do this re-negotiation, rather
then replicate similar functionality in CARD or CT. The difficulty I suspect
with this, is that none of the protocols exist yet, so it is hard for many
of us to see what the trade-offs are.

Perhaps the answer is to decide now where the divisions between the problem
spaces (via requirements and objectives), and worry about trade-offs later.
(Requirements drafts are not legal documents: they can be revised with sufficient
reason.)

Cheers,
Gary
>

------_=_NextPart_001_01C1DFEF.C7DF5688-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 14:20: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 OAA15214 for ; Tue, 9 Apr 2002 14:20:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10019; Tue, 9 Apr 2002 14:11:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09996 for ; Tue, 9 Apr 2002 14:11:24 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14821 for ; Tue, 9 Apr 2002 14:11:21 -0400 (EDT) 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 g39IAXq26886; Tue, 9 Apr 2002 14:10:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:10:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A03@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phil Neumiller'" , "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:10:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF1.7CCFCC70" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFF1.7CCFCC70 Content-Type: text/plain; charset="iso-8859-1" Phil: > -----Original Message----- > From: Phil Neumiller [mailto:pneumiller@directvinternet.com] > Sent: April 8, 2002 20:49 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'; Nakhjiri > Madjid-MNAKHJI1 > Cc: 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > ----- Original Message ----- > From: Gary Kenward > > > > If someone really wants to provide CT over an all wireless > >ad hoc network, for example, then, yes, additional reliability > >will probably be required. In most wired infrastructure scenarios, > >the link reliability is more then sufficient. > > pdn> There is not that much difference between an ad hoc network and > a wireless network that doesn't support soft handover. I > would argue that > a wireless infrastructure network with hard handover is less > reliable than > an ad hoc nework with hard handover. Ok. > > > >To allow for this flexibility in reliability, this type of > >reliability needs to be provided in the transport layer, not > >with CT. Specific reasons for building additional reliability > >into the CT protocol that are generally applicable to a majority > >of scenarios, and cannot be resolved by substituting a more > >robust transport protocol, have yet to be offered. > >Gary > > pdn>That's funny. Why don't you like more robust handoffs to > begin with??? Not my point Phil. I was referring to CT Transport, not over-the-air transport. BTW: robust handovers are only needed when robust service is required. what would be sufficient for handover of BE traffic? Cheers, Gary > > > > > ------_=_NextPart_001_01C1DFF1.7CCFCC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:

> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@directv= internet.com]
> Sent: April 8, 2002 20:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles = E. Perkins'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: 'James Kempf'; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> RE: [Seamoby] RE: [NSIS] Establishing QoS after = handoff.
> ----- Original Message -----
> From: Gary Kenward
>
>
> >  If someone really wants to provide = CT over an all wireless
> >ad hoc network, for example, then, yes, = additional reliability
> >will probably be required. In most wired = infrastructure scenarios,
> >the link reliability is more then = sufficient.
>
> pdn> There is not that much difference = between an ad hoc network and
> a wireless network that doesn't support soft = handover.  I
> would argue that
> a wireless infrastructure network with hard = handover is less
> reliable than
> an ad hoc nework with hard handover.

Ok.

>
>
> >To allow for this flexibility in = reliability, this type of
> >reliability needs to be provided in the = transport layer, not
> >with CT. Specific reasons for building = additional reliability
> >into the CT protocol that are generally = applicable to a majority
> >of scenarios, and cannot be resolved by = substituting a more
> >robust transport protocol, have yet to be = offered.
> >Gary
>
> pdn>That's funny.  Why don't you like = more robust handoffs to
> begin with???

Not my point Phil. I was referring to CT Transport, = not over-the-air
transport.

BTW: robust handovers are only needed when robust = service is required.
what would be sufficient for handover of BE = traffic?

Cheers,
Gary
>
>
>
>
>

------_=_NextPart_001_01C1DFF1.7CCFCC70-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 14:20: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 OAA15226 for ; Tue, 9 Apr 2002 14:20:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10527 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 14:20:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10019; Tue, 9 Apr 2002 14:11:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09996 for ; Tue, 9 Apr 2002 14:11:24 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14821 for ; Tue, 9 Apr 2002 14:11:21 -0400 (EDT) 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 g39IAXq26886; Tue, 9 Apr 2002 14:10:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:10:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A03@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phil Neumiller'" , "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:10:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF1.7CCFCC70" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFF1.7CCFCC70 Content-Type: text/plain; charset="iso-8859-1" Phil: > -----Original Message----- > From: Phil Neumiller [mailto:pneumiller@directvinternet.com] > Sent: April 8, 2002 20:49 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'; Nakhjiri > Madjid-MNAKHJI1 > Cc: 'James Kempf'; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > ----- Original Message ----- > From: Gary Kenward > > > > If someone really wants to provide CT over an all wireless > >ad hoc network, for example, then, yes, additional reliability > >will probably be required. In most wired infrastructure scenarios, > >the link reliability is more then sufficient. > > pdn> There is not that much difference between an ad hoc network and > a wireless network that doesn't support soft handover. I > would argue that > a wireless infrastructure network with hard handover is less > reliable than > an ad hoc nework with hard handover. Ok. > > > >To allow for this flexibility in reliability, this type of > >reliability needs to be provided in the transport layer, not > >with CT. Specific reasons for building additional reliability > >into the CT protocol that are generally applicable to a majority > >of scenarios, and cannot be resolved by substituting a more > >robust transport protocol, have yet to be offered. > >Gary > > pdn>That's funny. Why don't you like more robust handoffs to > begin with??? Not my point Phil. I was referring to CT Transport, not over-the-air transport. BTW: robust handovers are only needed when robust service is required. what would be sufficient for handover of BE traffic? Cheers, Gary > > > > > ------_=_NextPart_001_01C1DFF1.7CCFCC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:

> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@directv= internet.com]
> Sent: April 8, 2002 20:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles = E. Perkins'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: 'James Kempf'; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> RE: [Seamoby] RE: [NSIS] Establishing QoS after = handoff.
> ----- Original Message -----
> From: Gary Kenward
>
>
> >  If someone really wants to provide = CT over an all wireless
> >ad hoc network, for example, then, yes, = additional reliability
> >will probably be required. In most wired = infrastructure scenarios,
> >the link reliability is more then = sufficient.
>
> pdn> There is not that much difference = between an ad hoc network and
> a wireless network that doesn't support soft = handover.  I
> would argue that
> a wireless infrastructure network with hard = handover is less
> reliable than
> an ad hoc nework with hard handover.

Ok.

>
>
> >To allow for this flexibility in = reliability, this type of
> >reliability needs to be provided in the = transport layer, not
> >with CT. Specific reasons for building = additional reliability
> >into the CT protocol that are generally = applicable to a majority
> >of scenarios, and cannot be resolved by = substituting a more
> >robust transport protocol, have yet to be = offered.
> >Gary
>
> pdn>That's funny.  Why don't you like = more robust handoffs to
> begin with???

Not my point Phil. I was referring to CT Transport, = not over-the-air
transport.

BTW: robust handovers are only needed when robust = service is required.
what would be sufficient for handover of BE = traffic?

Cheers,
Gary
>
>
>
>
>

------_=_NextPart_001_01C1DFF1.7CCFCC70-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 14:36: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 OAA15999 for ; Tue, 9 Apr 2002 14:36:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10271; Tue, 9 Apr 2002 14:17:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10196 for ; Tue, 9 Apr 2002 14:17:03 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15102; Tue, 9 Apr 2002 14:17:01 -0400 (EDT) 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 g39ICPq26994; Tue, 9 Apr 2002 14:12:25 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:12:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A04@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phil Neumiller'" , Rajeev Koodli Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:12:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF1.FD0BA71A" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFF1.FD0BA71A Content-Type: text/plain; charset="iso-8859-1" Phil: > -----Original Message----- > From: Phil Neumiller [mailto:pneumiller@directvinternet.com] *snip* > > Yes, stay connected to multiple ARs. You will need it anyway for > log normal shadow fading in outdoor environments. People on this > list don't realize that frequencies are going up and these things will > deployed > outdoors where shadow fading is the killer. Its not going to Don't forget the pain of rain! > be one big > cell > after another. Its going to be connections two or three > crappy cells and > making the best use of them. > > > ------_=_NextPart_001_01C1DFF1.FD0BA71A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:

> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@directv= internet.com]

*snip*

>
> Yes, stay connected to multiple ARs.  You = will need it anyway for
> log normal shadow fading in outdoor = environments.  People on this
> list don't realize that frequencies are going = up and these things will
> deployed
> outdoors where shadow fading is the = killer.  Its not going to

Don't forget the pain of rain!

> be one big
> cell
> after another.  Its going to be = connections two or three
> crappy cells and
> making the best use of them.
>
>
>

------_=_NextPart_001_01C1DFF1.FD0BA71A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 14:36: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 OAA16009 for ; Tue, 9 Apr 2002 14:36:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11979 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 14:36:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10271; Tue, 9 Apr 2002 14:17:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10196 for ; Tue, 9 Apr 2002 14:17:03 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15102; Tue, 9 Apr 2002 14:17:01 -0400 (EDT) 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 g39ICPq26994; Tue, 9 Apr 2002 14:12:25 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:12:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A04@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phil Neumiller'" , Rajeev Koodli Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:12:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF1.FD0BA71A" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFF1.FD0BA71A Content-Type: text/plain; charset="iso-8859-1" Phil: > -----Original Message----- > From: Phil Neumiller [mailto:pneumiller@directvinternet.com] *snip* > > Yes, stay connected to multiple ARs. You will need it anyway for > log normal shadow fading in outdoor environments. People on this > list don't realize that frequencies are going up and these things will > deployed > outdoors where shadow fading is the killer. Its not going to Don't forget the pain of rain! > be one big > cell > after another. Its going to be connections two or three > crappy cells and > making the best use of them. > > > ------_=_NextPart_001_01C1DFF1.FD0BA71A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:

> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@directv= internet.com]

*snip*

>
> Yes, stay connected to multiple ARs.  You = will need it anyway for
> log normal shadow fading in outdoor = environments.  People on this
> list don't realize that frequencies are going = up and these things will
> deployed
> outdoors where shadow fading is the = killer.  Its not going to

Don't forget the pain of rain!

> be one big
> cell
> after another.  Its going to be = connections two or three
> crappy cells and
> making the best use of them.
>
>
>

------_=_NextPart_001_01C1DFF1.FD0BA71A-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 14: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 OAA16037 for ; Tue, 9 Apr 2002 14:37:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11636; Tue, 9 Apr 2002 14:31:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11525 for ; Tue, 9 Apr 2002 14:31:46 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15737; Tue, 9 Apr 2002 14:31:43 -0400 (EDT) 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 g39IUug06268; Tue, 9 Apr 2002 14:30:56 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:30:56 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A06@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:30:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF3.BEDD7138" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFF3.BEDD7138 Content-Type: text/plain; charset="iso-8859-1" James: Sorry, but I am a bit confused (as usual), are you saying then that doing these functions with the CT protocol is less heavyweight, and thus preferable? The default action, always, is for the session to be dropped. This will ultimately force the MN to take action (oh, ok, some MNs will simply halt and catch fire). Anything more then dropping the session is simply to improve the handover performance under various conditions. Typically, when one gets into exception scenarios, the solutions become too complex or degrade performance too much to be justified against the potential gains. A classic example is run time type/value checking in C/C++. If there are no recovery mechanisms for the potential faults you describe, then does it make sense to build one into CT? On the other hand, if these mechanisms are built into the handover algorithm, or into the session support, then putting it into CT would be redundant, would it not? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 21:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > When you say "handover failure" I think Mobile IP, and there > is already > some signaling available in FMIPv6/BETH to do this. This > signaling does > not extend to attributes of the IP service like whether or not the MN > can connect to the network, what class of QoS service it gets, and any > other security, etc.. There is currently no way to signal that the > network expects the MN to reestablish these, except to say that the MN > has entered a new AAA domain and should therefore perform > network entry > from scratch. This seems a little too heavyweight to me. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "'Rajeev Koodli'" > ; "Nakhjiri Madjid-MNAKHJI1" > > Cc: ; ; > Sent: Monday, April 08, 2002 1:21 PM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James: > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 15:55 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > > Madjid-MNAKHJI1 > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > As I outlined in one of my other posts, why would you > > > perform CT to an > > > > AR that did not have the necessary capabilities. Is > this actually > > > about > > > > CAR failure?? > > > > > > > > > > Yes and no. > > > > > > Suppose the MN is expecting CT to be performed and it is not > > > because the > > > > A nit, but the MN does not expect CT. The MN expects continuous > > service (i.e. seamless service), and knows nothing about how it is > > supported (it could be provisioned). > > > > > new AR can't interpret the context. > > > The old AR may discover this via CAR, but if there is no way to > > > communicate it to the MN, then the MN can't know to perform the > > > signaling from scratch on the new AR. One could either inform the > MN > > > beforehand to do the signaling, as is done with FMIPv6/BETH, or > signal > > > the MN on the new AR. > > > > > > For dynamic failures, such as when the AR runs out of Gold Class > > > service, the signaling could only be done afterwards. > > > > I understand these scenarios, but I do not understand what they have > > to do with CT. CT has never intended to be an MN signalling > protocol. > > Let me try a counter example: the service authorization fails. Would > > a CT message saying the AA context transfer failed be of much use > > to the MN? No, because the problem wasn't with the context, it was > with > > a disconnect between the service request and authorization > profile for > > that MN. > > > > There is a need for a "handover failure" indication message to the > > MN (indicating full or partial handover failure), but this message > should > > be part of a different protocol from CT. > > > > Gary > > > > > > > > jak > > > > > > ------_=_NextPart_001_01C1DFF3.BEDD7138 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

  Sorry, but I am a bit confused (as usual), are you saying
then that doing these functions with the CT protocol is less
heavyweight, and thus preferable?

  The default action, always, is for the session to be dropped.
This will ultimately force the MN to take action (oh, ok, some
MNs will simply halt and catch fire). Anything more then dropping
the session is simply to improve the handover performance under
various conditions. Typically, when one gets into exception scenarios,
the solutions become too complex or degrade performance too much
to be justified against the potential gains. A classic example is
run time type/value checking in C/C++.

  If there are no recovery mechanisms for the potential faults
you describe, then does it make sense to build one into CT?
On the other hand, if these mechanisms are built into the handover
algorithm, or into the session support, then putting it into CT
would be redundant, would it not?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 21:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> When you say "handover failure" I think Mobile IP, and there
> is already
> some signaling available in FMIPv6/BETH to do this. This
> signaling does
> not extend to attributes of the IP service like whether or not the MN
> can connect to the network, what class of QoS service it gets, and any
> other security, etc.. There is currently no way to signal that the
> network expects the MN to reestablish these, except to say that the MN
> has entered a new AAA domain and should therefore perform
> network entry
> from scratch. This seems a little too heavyweight to me.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; "'Rajeev Koodli'"
> <rajeev@iprg.nokia.com>; "Nakhjiri Madjid-MNAKHJI1"
> <Madjid.Nakhjiri@motorola.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Monday, April 08, 2002 1:21 PM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> > James:
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 8, 2002 15:55
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> > > Madjid-MNAKHJI1
> > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > > As I outlined in one of my other posts, why would you
> > > perform CT to an
> > > > AR that did not have the necessary capabilities. Is
> this actually
> > > about
> > > > CAR failure??
> > > >
> > >
> > > Yes and no.
> > >
> > > Suppose the MN is expecting CT to be performed and it is not
> > > because the
> >
> > A nit, but the MN does not expect CT. The MN expects continuous
> > service (i.e. seamless service), and knows nothing about how it is
> > supported (it could be provisioned).
> >
> > > new AR can't interpret the context.
> > > The old AR may discover this via CAR, but if there is no way to
> > > communicate it to the MN, then the MN can't know to perform the
> > > signaling from scratch on the new AR.  One could either inform the
> MN
> > > beforehand to do the signaling, as is done with FMIPv6/BETH, or
> signal
> > > the MN on the new AR.
> > >
> > > For dynamic failures, such as when the AR runs out of Gold Class
> > > service, the signaling could only be done afterwards.
> >
> > I understand these scenarios, but I do not understand what they have
> > to do with CT. CT has never intended to be an MN signalling
> protocol.
> > Let me try a counter example: the service authorization fails. Would
> > a CT message saying the AA context transfer failed be of much use
> > to the MN? No, because the problem wasn't with the context, it was
> with
> > a disconnect between the service request and authorization
> profile for
> > that MN.
> >
> > There is a need for a "handover failure" indication message to the
> > MN (indicating full or partial handover failure), but this message
> should
> > be part of a different protocol from CT.
> >
> > Gary
> >
> > >
> > >             jak
> > >
> >
>

------_=_NextPart_001_01C1DFF3.BEDD7138-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 14:37: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 OAA16048 for ; Tue, 9 Apr 2002 14:37:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12052 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 14:37:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11636; Tue, 9 Apr 2002 14:31:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11525 for ; Tue, 9 Apr 2002 14:31:46 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15737; Tue, 9 Apr 2002 14:31:43 -0400 (EDT) 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 g39IUug06268; Tue, 9 Apr 2002 14:30:56 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:30:56 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A06@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:30:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF3.BEDD7138" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFF3.BEDD7138 Content-Type: text/plain; charset="iso-8859-1" James: Sorry, but I am a bit confused (as usual), are you saying then that doing these functions with the CT protocol is less heavyweight, and thus preferable? The default action, always, is for the session to be dropped. This will ultimately force the MN to take action (oh, ok, some MNs will simply halt and catch fire). Anything more then dropping the session is simply to improve the handover performance under various conditions. Typically, when one gets into exception scenarios, the solutions become too complex or degrade performance too much to be justified against the potential gains. A classic example is run time type/value checking in C/C++. If there are no recovery mechanisms for the potential faults you describe, then does it make sense to build one into CT? On the other hand, if these mechanisms are built into the handover algorithm, or into the session support, then putting it into CT would be redundant, would it not? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 21:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > When you say "handover failure" I think Mobile IP, and there > is already > some signaling available in FMIPv6/BETH to do this. This > signaling does > not extend to attributes of the IP service like whether or not the MN > can connect to the network, what class of QoS service it gets, and any > other security, etc.. There is currently no way to signal that the > network expects the MN to reestablish these, except to say that the MN > has entered a new AAA domain and should therefore perform > network entry > from scratch. This seems a little too heavyweight to me. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "'Rajeev Koodli'" > ; "Nakhjiri Madjid-MNAKHJI1" > > Cc: ; ; > Sent: Monday, April 08, 2002 1:21 PM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James: > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 15:55 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > > Madjid-MNAKHJI1 > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > As I outlined in one of my other posts, why would you > > > perform CT to an > > > > AR that did not have the necessary capabilities. Is > this actually > > > about > > > > CAR failure?? > > > > > > > > > > Yes and no. > > > > > > Suppose the MN is expecting CT to be performed and it is not > > > because the > > > > A nit, but the MN does not expect CT. The MN expects continuous > > service (i.e. seamless service), and knows nothing about how it is > > supported (it could be provisioned). > > > > > new AR can't interpret the context. > > > The old AR may discover this via CAR, but if there is no way to > > > communicate it to the MN, then the MN can't know to perform the > > > signaling from scratch on the new AR. One could either inform the > MN > > > beforehand to do the signaling, as is done with FMIPv6/BETH, or > signal > > > the MN on the new AR. > > > > > > For dynamic failures, such as when the AR runs out of Gold Class > > > service, the signaling could only be done afterwards. > > > > I understand these scenarios, but I do not understand what they have > > to do with CT. CT has never intended to be an MN signalling > protocol. > > Let me try a counter example: the service authorization fails. Would > > a CT message saying the AA context transfer failed be of much use > > to the MN? No, because the problem wasn't with the context, it was > with > > a disconnect between the service request and authorization > profile for > > that MN. > > > > There is a need for a "handover failure" indication message to the > > MN (indicating full or partial handover failure), but this message > should > > be part of a different protocol from CT. > > > > Gary > > > > > > > > jak > > > > > > ------_=_NextPart_001_01C1DFF3.BEDD7138 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

  Sorry, but I am a bit confused (as usual), are you saying
then that doing these functions with the CT protocol is less
heavyweight, and thus preferable?

  The default action, always, is for the session to be dropped.
This will ultimately force the MN to take action (oh, ok, some
MNs will simply halt and catch fire). Anything more then dropping
the session is simply to improve the handover performance under
various conditions. Typically, when one gets into exception scenarios,
the solutions become too complex or degrade performance too much
to be justified against the potential gains. A classic example is
run time type/value checking in C/C++.

  If there are no recovery mechanisms for the potential faults
you describe, then does it make sense to build one into CT?
On the other hand, if these mechanisms are built into the handover
algorithm, or into the session support, then putting it into CT
would be redundant, would it not?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 21:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> When you say "handover failure" I think Mobile IP, and there
> is already
> some signaling available in FMIPv6/BETH to do this. This
> signaling does
> not extend to attributes of the IP service like whether or not the MN
> can connect to the network, what class of QoS service it gets, and any
> other security, etc.. There is currently no way to signal that the
> network expects the MN to reestablish these, except to say that the MN
> has entered a new AAA domain and should therefore perform
> network entry
> from scratch. This seems a little too heavyweight to me.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; "'Rajeev Koodli'"
> <rajeev@iprg.nokia.com>; "Nakhjiri Madjid-MNAKHJI1"
> <Madjid.Nakhjiri@motorola.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Monday, April 08, 2002 1:21 PM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> > James:
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 8, 2002 15:55
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> > > Madjid-MNAKHJI1
> > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > > As I outlined in one of my other posts, why would you
> > > perform CT to an
> > > > AR that did not have the necessary capabilities. Is
> this actually
> > > about
> > > > CAR failure??
> > > >
> > >
> > > Yes and no.
> > >
> > > Suppose the MN is expecting CT to be performed and it is not
> > > because the
> >
> > A nit, but the MN does not expect CT. The MN expects continuous
> > service (i.e. seamless service), and knows nothing about how it is
> > supported (it could be provisioned).
> >
> > > new AR can't interpret the context.
> > > The old AR may discover this via CAR, but if there is no way to
> > > communicate it to the MN, then the MN can't know to perform the
> > > signaling from scratch on the new AR.  One could either inform the
> MN
> > > beforehand to do the signaling, as is done with FMIPv6/BETH, or
> signal
> > > the MN on the new AR.
> > >
> > > For dynamic failures, such as when the AR runs out of Gold Class
> > > service, the signaling could only be done afterwards.
> >
> > I understand these scenarios, but I do not understand what they have
> > to do with CT. CT has never intended to be an MN signalling
> protocol.
> > Let me try a counter example: the service authorization fails. Would
> > a CT message saying the AA context transfer failed be of much use
> > to the MN? No, because the problem wasn't with the context, it was
> with
> > a disconnect between the service request and authorization
> profile for
> > that MN.
> >
> > There is a need for a "handover failure" indication message to the
> > MN (indicating full or partial handover failure), but this message
> should
> > be part of a different protocol from CT.
> >
> > Gary
> >
> > >
> > >             jak
> > >
> >
>

------_=_NextPart_001_01C1DFF3.BEDD7138-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 15:26: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 PAA18084 for ; Tue, 9 Apr 2002 15:26:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14166; Tue, 9 Apr 2002 15:14:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14101 for ; Tue, 9 Apr 2002 15:14:14 -0400 (EDT) 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 PAA17577; Tue, 9 Apr 2002 15:14:10 -0400 (EDT) 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 g39J28I12008; Tue, 9 Apr 2002 12:02:08 -0700 (PDT) Message-ID: <019c01c1dff8$d2b252f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA4A06@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 12:00:31 -0700 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 Gary, > Sorry, but I am a bit confused (as usual), are you saying > then that doing these functions with the CT protocol is less > heavyweight, and thus preferable? > No, I'm saying that "dropping the session" is more heavyweight. And what do you mean by a session anyway? IP is connectionless. I think what you mean is that all feature contexts for the MN revert to the startup state, namely gone. > The default action, always, is for the session to be dropped. > This will ultimately force the MN to take action (oh, ok, some > MNs will simply halt and catch fire). Anything more then dropping > the session is simply to improve the handover performance under > various conditions. Typically, when one gets into exception scenarios, > the solutions become too complex or degrade performance too much > to be justified against the potential gains. A classic example is > run time type/value checking in C/C++. > My point is, if the MN never finds out about this, then it can't take any action. > If there are no recovery mechanisms for the potential faults > you describe, then does it make sense to build one into CT? > On the other hand, if these mechanisms are built into the handover > algorithm, or into the session support, then putting it into CT > would be redundant, would it not? > I'm not saying that there should be recovery built into CT. What I am saying is that the MN has got to know when it has to redo signaling in order to reestablish stuff like it's AAA state or it's QoS state. We went through this exact conversation on the MIP list with respect to BETH. The MN doesn't get involved in handover with BETH, so it needs to be informed when BETH handover fails (in practice, we tell it when BETH handover is about to fail). Then it can do standard MIP signaling in order to get a care of address. I'm willing to grant that having CT do feature by feature failure notification doesn't make sense, but I still think there needs to be some way to tell the MN that seamlessness has failed or is about to fail so it can take the right steps to restart the original network admission procedure. I think this is needed if for no other reason than when the MN reaches the edge of the operator's domain, if the operator doesn't have the right business agreements with the next operator, the MN has got to know to redo network entry, i.e. AAA from scratch, QoS from scratch, etc. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 15:26: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 PAA18094 for ; Tue, 9 Apr 2002 15:26:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14745 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 15:26:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14166; Tue, 9 Apr 2002 15:14:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14101 for ; Tue, 9 Apr 2002 15:14:14 -0400 (EDT) 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 PAA17577; Tue, 9 Apr 2002 15:14:10 -0400 (EDT) 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 g39J28I12008; Tue, 9 Apr 2002 12:02:08 -0700 (PDT) Message-ID: <019c01c1dff8$d2b252f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA4A06@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 12:00:31 -0700 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 Gary, > Sorry, but I am a bit confused (as usual), are you saying > then that doing these functions with the CT protocol is less > heavyweight, and thus preferable? > No, I'm saying that "dropping the session" is more heavyweight. And what do you mean by a session anyway? IP is connectionless. I think what you mean is that all feature contexts for the MN revert to the startup state, namely gone. > The default action, always, is for the session to be dropped. > This will ultimately force the MN to take action (oh, ok, some > MNs will simply halt and catch fire). Anything more then dropping > the session is simply to improve the handover performance under > various conditions. Typically, when one gets into exception scenarios, > the solutions become too complex or degrade performance too much > to be justified against the potential gains. A classic example is > run time type/value checking in C/C++. > My point is, if the MN never finds out about this, then it can't take any action. > If there are no recovery mechanisms for the potential faults > you describe, then does it make sense to build one into CT? > On the other hand, if these mechanisms are built into the handover > algorithm, or into the session support, then putting it into CT > would be redundant, would it not? > I'm not saying that there should be recovery built into CT. What I am saying is that the MN has got to know when it has to redo signaling in order to reestablish stuff like it's AAA state or it's QoS state. We went through this exact conversation on the MIP list with respect to BETH. The MN doesn't get involved in handover with BETH, so it needs to be informed when BETH handover fails (in practice, we tell it when BETH handover is about to fail). Then it can do standard MIP signaling in order to get a care of address. I'm willing to grant that having CT do feature by feature failure notification doesn't make sense, but I still think there needs to be some way to tell the MN that seamlessness has failed or is about to fail so it can take the right steps to restart the original network admission procedure. I think this is needed if for no other reason than when the MN reaches the edge of the operator's domain, if the operator doesn't have the right business agreements with the next operator, the MN has got to know to redo network entry, i.e. AAA from scratch, QoS from scratch, etc. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 15:40: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 PAA18757 for ; Tue, 9 Apr 2002 15:40:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14616; Tue, 9 Apr 2002 15:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14555 for ; Tue, 9 Apr 2002 15:21:53 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17937; Tue, 9 Apr 2002 15:21:49 -0400 (EDT) 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 g39JLJg09865; Tue, 9 Apr 2002 15:21:20 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:21:20 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A0B@zcard031.ca.nortel.com> From: "Gary Kenward" Cc: "'nsis@ietf.org'" , "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:21:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFFB.9C13BB6E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFFB.9C13BB6E Content-Type: text/plain; charset="iso-8859-1" Phil: Yup, Phil, I have studied it. My point was that the unreliability of CT should not be noticeable with respect to the relative unreliability of handover. And the latter is far from 100% reliable, even with all the advances. Of course, one could make CT grossly unreliable, but I contend that it is easier to make an information transfer between two (relatively close) nodes in a wired network reliable then it is to make anything in wireless more reliable. Cheers, Gary -----Original Message----- From: Phil Neumiller [mailto:pneumiller@directvinternet.com] Sent: April 8, 2002 20:43 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev Koodli'; James Kempf Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hmm. Gary have you studied the mechanics (i.e. the physics as you put it) of 3G aka CDMA handover? Why do you say its unreliable? Make before break won the battle years ago. Why do people in the IETF incessently restrict themselve to legacy handovers???? ----- Original Message ----- From: Gary Kenward To: 'Nakhjiri Madjid-MNAKHJI1' ; 'Rajeev Koodli' ; James Kempf Cc: Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org Sent: Monday, April 08, 2002 3:46 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > ------_=_NextPart_001_01C1DFFB.9C13BB6E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:
 
  Yup, Phil, I have studied it. My point was that the unreliability of CT should not
be noticeable with respect to the relative unreliability of handover. And the
latter is far from 100% reliable, even with all the advances.
 
  Of course, one could make CT grossly unreliable, but I contend that it is easier
to make an information transfer between two (relatively close) nodes in a wired
network reliable then it is to make anything in wireless more reliable.
 
Cheers,
Gary
-----Original Message-----
From: Phil Neumiller [mailto:pneumiller@directvinternet.com]
Sent: April 8, 2002 20:43
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev Koodli'; James Kempf
Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.


Hmm.  Gary have you studied the mechanics (i.e. the physics as you put it) of 3G aka
CDMA handover?  Why do you say its unreliable?  Make before break won the battle years
ago.  Why do people in the IETF incessently restrict themselve to legacy handovers????
 
----- Original Message -----
From: Gary Kenward
To: 'Nakhjiri Madjid-MNAKHJI1' ; 'Rajeev Koodli' ; James Kempf
Cc: Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org
Sent: Monday, April 08, 2002 3:46 PM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.


Can anyone offer an explaining of how or why CT would add significantly
to the already unreliable physics of handover?
What failure modes for CT would be noticeable above the unavoidable
rate of handover failures due the vagaries of wireless coverage and
wireless link layer performance????
If CT fails, then the handover fails. It is that simple. If CT were
to fail with every 2nd handover attempt, then there would be a problem.
But, I cannot seriously see CT failing more then every one in a million
handover attempts, or less.
CT should not be attempted if there is an incompatibility between source
and destination ARs. And, I HAD thought that it was the purpose of CAR
to identify those incompatibilities and thus avoid doing CT when it is
clear it would fail. How to mitigate those incompatibles is not a
CT issue, it is a service adaptation issue, which can be resolved in
a number of ways, some of which would imply signalled negotiation either
between the ARs or between the ARs and the MN.
Gary
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, which by the way
> neither CT requirements, nor nsis requirements are covering, has to
> do with failure in QoS negotiation. I don't think you can count
> the case, where the QoS information that CT has given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or not?
> >
>
> This notification should be covered by CT.  We should offer
> seamless handover to NSIS :-) Seriously, this concerns
> robustness of CT protocol.
>
> -Rajeev
>
>
>

------_=_NextPart_001_01C1DFFB.9C13BB6E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 15: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 PAA18767 for ; Tue, 9 Apr 2002 15:40:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15859 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 15:40:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14616; Tue, 9 Apr 2002 15:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14555 for ; Tue, 9 Apr 2002 15:21:53 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17937; Tue, 9 Apr 2002 15:21:49 -0400 (EDT) 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 g39JLJg09865; Tue, 9 Apr 2002 15:21:20 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:21:20 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A0B@zcard031.ca.nortel.com> From: "Gary Kenward" Cc: "'nsis@ietf.org'" , "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:21:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFFB.9C13BB6E" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFFB.9C13BB6E Content-Type: text/plain; charset="iso-8859-1" Phil: Yup, Phil, I have studied it. My point was that the unreliability of CT should not be noticeable with respect to the relative unreliability of handover. And the latter is far from 100% reliable, even with all the advances. Of course, one could make CT grossly unreliable, but I contend that it is easier to make an information transfer between two (relatively close) nodes in a wired network reliable then it is to make anything in wireless more reliable. Cheers, Gary -----Original Message----- From: Phil Neumiller [mailto:pneumiller@directvinternet.com] Sent: April 8, 2002 20:43 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev Koodli'; James Kempf Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hmm. Gary have you studied the mechanics (i.e. the physics as you put it) of 3G aka CDMA handover? Why do you say its unreliable? Make before break won the battle years ago. Why do people in the IETF incessently restrict themselve to legacy handovers???? ----- Original Message ----- From: Gary Kenward To: 'Nakhjiri Madjid-MNAKHJI1' ; 'Rajeev Koodli' ; James Kempf Cc: Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org Sent: Monday, April 08, 2002 3:46 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > ------_=_NextPart_001_01C1DFFB.9C13BB6E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:
 
  Yup, Phil, I have studied it. My point was that the unreliability of CT should not
be noticeable with respect to the relative unreliability of handover. And the
latter is far from 100% reliable, even with all the advances.
 
  Of course, one could make CT grossly unreliable, but I contend that it is easier
to make an information transfer between two (relatively close) nodes in a wired
network reliable then it is to make anything in wireless more reliable.
 
Cheers,
Gary
-----Original Message-----
From: Phil Neumiller [mailto:pneumiller@directvinternet.com]
Sent: April 8, 2002 20:43
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev Koodli'; James Kempf
Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.


Hmm.  Gary have you studied the mechanics (i.e. the physics as you put it) of 3G aka
CDMA handover?  Why do you say its unreliable?  Make before break won the battle years
ago.  Why do people in the IETF incessently restrict themselve to legacy handovers????
 
----- Original Message -----
From: Gary Kenward
To: 'Nakhjiri Madjid-MNAKHJI1' ; 'Rajeev Koodli' ; James Kempf
Cc: Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org
Sent: Monday, April 08, 2002 3:46 PM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.


Can anyone offer an explaining of how or why CT would add significantly
to the already unreliable physics of handover?
What failure modes for CT would be noticeable above the unavoidable
rate of handover failures due the vagaries of wireless coverage and
wireless link layer performance????
If CT fails, then the handover fails. It is that simple. If CT were
to fail with every 2nd handover attempt, then there would be a problem.
But, I cannot seriously see CT failing more then every one in a million
handover attempts, or less.
CT should not be attempted if there is an incompatibility between source
and destination ARs. And, I HAD thought that it was the purpose of CAR
to identify those incompatibilities and thus avoid doing CT when it is
clear it would fail. How to mitigate those incompatibles is not a
CT issue, it is a service adaptation issue, which can be resolved in
a number of ways, some of which would imply signalled negotiation either
between the ARs or between the ARs and the MN.
Gary
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, which by the way
> neither CT requirements, nor nsis requirements are covering, has to
> do with failure in QoS negotiation. I don't think you can count
> the case, where the QoS information that CT has given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or not?
> >
>
> This notification should be covered by CT.  We should offer
> seamless handover to NSIS :-) Seriously, this concerns
> robustness of CT protocol.
>
> -Rajeev
>
>
>

------_=_NextPart_001_01C1DFFB.9C13BB6E-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 16:03: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 QAA19752 for ; Tue, 9 Apr 2002 16:02:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16307; Tue, 9 Apr 2002 15:50:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16154 for ; Tue, 9 Apr 2002 15:50:03 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19163; Tue, 9 Apr 2002 15:49:59 -0400 (EDT) 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 g39JnBq06102; Tue, 9 Apr 2002 15:49:11 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:49:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A0C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:49:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFFF.9DDF7DEE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFFF.9DDF7DEE Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 9, 2002 15:01 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > > Sorry, but I am a bit confused (as usual), are you saying > > then that doing these functions with the CT protocol is less > > heavyweight, and thus preferable? > > > > No, I'm saying that "dropping the session" is more > heavyweight. And what Agreed. It would be better to try and fix things first. The real question is at what level. > do you mean by a session anyway? > IP is connectionless. Well...sessions do not require connections. But I have a feeling we both do not want to open up that can-of-worms debate. When I say "session", I mean all the collection of services/resources that have been set up to support an IP flow, QoS, AAA, HC, etc. If you have a better word, I'll use it. > > I think what you mean is that all feature contexts for the MN > revert to > the startup state, namely gone. Ok. Except, that it may be only the feature contexts for a given microflow. E.g just because a new AR cannot support EF PHB, does not mean that the BE flows need to be dropped. > > > The default action, always, is for the session to be dropped. > > This will ultimately force the MN to take action (oh, ok, some > > MNs will simply halt and catch fire). Anything more then dropping > > the session is simply to improve the handover performance under > > various conditions. Typically, when one gets into exception > scenarios, > > the solutions become too complex or degrade performance too much > > to be justified against the potential gains. A classic example is > > run time type/value checking in C/C++. > > > > My point is, if the MN never finds out about this, then it can't take > any action. My points is that this is not a CT protocol function. There are any number of failure points for a service feature, and it is the responsibility of the control entity for that service feature to notify the MN. > > > If there are no recovery mechanisms for the potential faults > > you describe, then does it make sense to build one into CT? > > On the other hand, if these mechanisms are built into the handover > > algorithm, or into the session support, then putting it into CT > > would be redundant, would it not? > > > > I'm not saying that there should be recovery built into CT. What I am > saying is > that the MN has got to know when it has to redo signaling in order to > reestablish > stuff like it's AAA state or it's QoS state. see comment above. But, btw: how does the MN re-establish state without dropping the flow? E.g. authentication? authorization? does re-establishing EF PHB make any sense (if you cannot do it within a 100 ms, has the service not been "dropped" anyway?) > > We went through this exact conversation on the MIP list with > respect to > BETH. The > MN doesn't get involved in handover with BETH, so it needs to be > informed when > BETH handover fails (in practice, we tell it when BETH > handover is about > to fail). > Then it can do standard MIP signaling in order to get a care > of address. > > I'm willing to grant that having CT do feature by feature failure > notification doesn't make sense, > but I still think there needs to be some way to tell the MN that > seamlessness has failed > or is about to fail so it can take the right steps to restart the > original network admission > procedure. > > I think this is needed if for no other reason than when the MN reaches > the edge of the operator's > domain, if the operator doesn't have the right business > agreements with > the next operator, the MN > has got to know to redo network entry, i.e. AAA from scratch, QoS from > scratch, etc. We agree on the first part of these two paragraphs. But, I am confused: I am not aware of any current facilities within QoS/AAA that allows the MN to repair AAA/QoS state as opposed to "building it from scratch". Certainly, protocols can be extended, but then, they can also be extended to allow for notification. Consider: o CT fails for a specific context o CT somehow sends notification that the context for QoS has failed. o MN determines (somehow) what this failure message means (again, consider that CT can, at best, notify that a particular data chunk failed somehow at the new AR, not why). o MN initiates a re-negotiation with the appropriate network entity (AAA server perhaps? an QoS Controller perhaps?) Versus: o CT fails for a specific context o service feature entity at new AR determines that it is unable to support one or more of the MN flows either because it does not have the context, or because it cannot support the context o new AR determines, perhaps using local policy decisions, what mitigating action can to be taken locally (e.g. downgrade an AF flow to a BE flow to support forwarding until new negotiations can take place). - OR - o new AR determines, perhaps using local policy decisions, that the control entity for the feature (e.g. the AAA server), needs to be notified (e.g. the service lacks proper authorization), the control entity can then take direct action (e.g. perhaps by some inter-system authorization exchange). - OR - o new AR determines, perhaps using local policy decisions, that the MN is should fix the problem, and sends a notification. Which scenario appears more flexible, more responsive, and more likely to support seamless handovers? Gary > > jak > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DFFF.9DDF7DEE Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 9, 2002 15:01
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> >   Sorry, but I am a bit confused (as usual), are you saying
> > then that doing these functions with the CT protocol is less
> > heavyweight, and thus preferable?
> >
>
> No, I'm saying that "dropping the session" is more
> heavyweight. And what

Agreed. It would be better to try and fix things first. The real
question is at what level.

> do you mean by a session anyway?
> IP is connectionless.

Well...sessions do not require connections. But I have a feeling
we both do not want to open up that can-of-worms debate.

When I say "session", I mean all the collection of services/resources
that have been set up to support an IP flow, QoS, AAA, HC, etc.
If you have a better word, I'll use it.

>
> I think what you mean is that all feature contexts for the MN
> revert to
> the startup state, namely gone.

Ok. Except, that it may be only the feature contexts for a given
microflow. E.g just because a new AR cannot support EF PHB, does
not mean that the BE flows need to be dropped.

>
> >   The default action, always, is for the session to be dropped.
> > This will ultimately force the MN to take action (oh, ok, some
> > MNs will simply halt and catch fire). Anything more then dropping
> > the session is simply to improve the handover performance under
> > various conditions. Typically, when one gets into exception
> scenarios,
> > the solutions become too complex or degrade performance too much
> > to be justified against the potential gains. A classic example is
> > run time type/value checking in C/C++.
> >
>
> My point is, if the MN never finds out about this, then it can't take
> any action.

My points is that this is not a CT protocol function. There are any
number of failure points for a service feature, and it is the responsibility
of the control entity for that service feature to notify the MN.

>
> >   If there are no recovery mechanisms for the potential faults
> > you describe, then does it make sense to build one into CT?
> > On the other hand, if these mechanisms are built into the handover
> > algorithm, or into the session support, then putting it into CT
> > would be redundant, would it not?
> >
>
> I'm not saying that there should be recovery built into CT. What I am
> saying is
> that the MN has got to know when it has to redo signaling in order to
> reestablish
> stuff like it's AAA state or it's QoS state.

see comment above.

But, btw: how does the MN re-establish state without dropping the flow?
E.g. authentication? authorization? does re-establishing EF PHB make
any sense (if you cannot do it within a 100 ms, has the service not
been "dropped" anyway?)

>
> We went through this exact conversation on the MIP list with
> respect to
> BETH. The
> MN doesn't get involved in handover with BETH, so it needs to be
> informed when
> BETH handover fails (in practice, we tell it when BETH
> handover is about
> to fail).
> Then it can do standard MIP signaling in order to get a care
> of address.
>
> I'm willing to grant that having CT do feature by feature failure
> notification doesn't make sense,
> but I still think there needs to be some way to tell the MN that
> seamlessness has failed
> or is about to fail so it can take the right steps to restart the
> original network admission
> procedure.
>
> I think this is needed if for no other reason than when the MN reaches
> the edge of the operator's
> domain, if the operator doesn't have the right business
> agreements with
> the next operator, the MN
> has got to know to redo network entry, i.e. AAA from scratch, QoS from
> scratch, etc.

We agree on the first part of these two paragraphs. But, I am confused:
I am not aware of any current facilities within QoS/AAA that allows the MN
to repair AAA/QoS state as opposed to "building it from scratch". Certainly,
protocols can be extended, but then, they can also be extended to allow
for notification.

Consider:

   o CT fails for a specific context

   o CT somehow sends notification that the context for QoS has failed.

   o MN determines (somehow) what this failure message means (again, consider that
CT can, at best, notify that a particular data chunk failed somehow at the new AR,
not why).

   o MN initiates a re-negotiation with the appropriate network entity (AAA server
perhaps? an QoS Controller perhaps?)

Versus:

   o CT fails for a specific context

   o service feature entity at new AR determines that it is unable to support
     one or more of the MN flows either because it does not have the context,
     or because it cannot support the context

   o new AR determines, perhaps using local policy decisions, what mitigating
     action can to be taken locally (e.g. downgrade an AF flow to a BE flow to
     support forwarding until new negotiations can take place).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the control
     entity for the feature (e.g. the AAA server), needs to be notified (e.g.
     the service lacks proper authorization), the control entity can then take
     direct action (e.g. perhaps by some inter-system authorization exchange).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the MN is
     should fix the problem, and sends a notification.

Which scenario appears more flexible, more responsive, and more likely to
support seamless handovers?

Gary

>
>             jak
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DFFF.9DDF7DEE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 16:03: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 QAA19769 for ; Tue, 9 Apr 2002 16:03:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17158 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 16:03:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16307; Tue, 9 Apr 2002 15:50:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16154 for ; Tue, 9 Apr 2002 15:50:03 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19163; Tue, 9 Apr 2002 15:49:59 -0400 (EDT) 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 g39JnBq06102; Tue, 9 Apr 2002 15:49:11 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:49:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A0C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:49:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFFF.9DDF7DEE" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1DFFF.9DDF7DEE Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 9, 2002 15:01 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > > Sorry, but I am a bit confused (as usual), are you saying > > then that doing these functions with the CT protocol is less > > heavyweight, and thus preferable? > > > > No, I'm saying that "dropping the session" is more > heavyweight. And what Agreed. It would be better to try and fix things first. The real question is at what level. > do you mean by a session anyway? > IP is connectionless. Well...sessions do not require connections. But I have a feeling we both do not want to open up that can-of-worms debate. When I say "session", I mean all the collection of services/resources that have been set up to support an IP flow, QoS, AAA, HC, etc. If you have a better word, I'll use it. > > I think what you mean is that all feature contexts for the MN > revert to > the startup state, namely gone. Ok. Except, that it may be only the feature contexts for a given microflow. E.g just because a new AR cannot support EF PHB, does not mean that the BE flows need to be dropped. > > > The default action, always, is for the session to be dropped. > > This will ultimately force the MN to take action (oh, ok, some > > MNs will simply halt and catch fire). Anything more then dropping > > the session is simply to improve the handover performance under > > various conditions. Typically, when one gets into exception > scenarios, > > the solutions become too complex or degrade performance too much > > to be justified against the potential gains. A classic example is > > run time type/value checking in C/C++. > > > > My point is, if the MN never finds out about this, then it can't take > any action. My points is that this is not a CT protocol function. There are any number of failure points for a service feature, and it is the responsibility of the control entity for that service feature to notify the MN. > > > If there are no recovery mechanisms for the potential faults > > you describe, then does it make sense to build one into CT? > > On the other hand, if these mechanisms are built into the handover > > algorithm, or into the session support, then putting it into CT > > would be redundant, would it not? > > > > I'm not saying that there should be recovery built into CT. What I am > saying is > that the MN has got to know when it has to redo signaling in order to > reestablish > stuff like it's AAA state or it's QoS state. see comment above. But, btw: how does the MN re-establish state without dropping the flow? E.g. authentication? authorization? does re-establishing EF PHB make any sense (if you cannot do it within a 100 ms, has the service not been "dropped" anyway?) > > We went through this exact conversation on the MIP list with > respect to > BETH. The > MN doesn't get involved in handover with BETH, so it needs to be > informed when > BETH handover fails (in practice, we tell it when BETH > handover is about > to fail). > Then it can do standard MIP signaling in order to get a care > of address. > > I'm willing to grant that having CT do feature by feature failure > notification doesn't make sense, > but I still think there needs to be some way to tell the MN that > seamlessness has failed > or is about to fail so it can take the right steps to restart the > original network admission > procedure. > > I think this is needed if for no other reason than when the MN reaches > the edge of the operator's > domain, if the operator doesn't have the right business > agreements with > the next operator, the MN > has got to know to redo network entry, i.e. AAA from scratch, QoS from > scratch, etc. We agree on the first part of these two paragraphs. But, I am confused: I am not aware of any current facilities within QoS/AAA that allows the MN to repair AAA/QoS state as opposed to "building it from scratch". Certainly, protocols can be extended, but then, they can also be extended to allow for notification. Consider: o CT fails for a specific context o CT somehow sends notification that the context for QoS has failed. o MN determines (somehow) what this failure message means (again, consider that CT can, at best, notify that a particular data chunk failed somehow at the new AR, not why). o MN initiates a re-negotiation with the appropriate network entity (AAA server perhaps? an QoS Controller perhaps?) Versus: o CT fails for a specific context o service feature entity at new AR determines that it is unable to support one or more of the MN flows either because it does not have the context, or because it cannot support the context o new AR determines, perhaps using local policy decisions, what mitigating action can to be taken locally (e.g. downgrade an AF flow to a BE flow to support forwarding until new negotiations can take place). - OR - o new AR determines, perhaps using local policy decisions, that the control entity for the feature (e.g. the AAA server), needs to be notified (e.g. the service lacks proper authorization), the control entity can then take direct action (e.g. perhaps by some inter-system authorization exchange). - OR - o new AR determines, perhaps using local policy decisions, that the MN is should fix the problem, and sends a notification. Which scenario appears more flexible, more responsive, and more likely to support seamless handovers? Gary > > jak > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DFFF.9DDF7DEE Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 9, 2002 15:01
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> >   Sorry, but I am a bit confused (as usual), are you saying
> > then that doing these functions with the CT protocol is less
> > heavyweight, and thus preferable?
> >
>
> No, I'm saying that "dropping the session" is more
> heavyweight. And what

Agreed. It would be better to try and fix things first. The real
question is at what level.

> do you mean by a session anyway?
> IP is connectionless.

Well...sessions do not require connections. But I have a feeling
we both do not want to open up that can-of-worms debate.

When I say "session", I mean all the collection of services/resources
that have been set up to support an IP flow, QoS, AAA, HC, etc.
If you have a better word, I'll use it.

>
> I think what you mean is that all feature contexts for the MN
> revert to
> the startup state, namely gone.

Ok. Except, that it may be only the feature contexts for a given
microflow. E.g just because a new AR cannot support EF PHB, does
not mean that the BE flows need to be dropped.

>
> >   The default action, always, is for the session to be dropped.
> > This will ultimately force the MN to take action (oh, ok, some
> > MNs will simply halt and catch fire). Anything more then dropping
> > the session is simply to improve the handover performance under
> > various conditions. Typically, when one gets into exception
> scenarios,
> > the solutions become too complex or degrade performance too much
> > to be justified against the potential gains. A classic example is
> > run time type/value checking in C/C++.
> >
>
> My point is, if the MN never finds out about this, then it can't take
> any action.

My points is that this is not a CT protocol function. There are any
number of failure points for a service feature, and it is the responsibility
of the control entity for that service feature to notify the MN.

>
> >   If there are no recovery mechanisms for the potential faults
> > you describe, then does it make sense to build one into CT?
> > On the other hand, if these mechanisms are built into the handover
> > algorithm, or into the session support, then putting it into CT
> > would be redundant, would it not?
> >
>
> I'm not saying that there should be recovery built into CT. What I am
> saying is
> that the MN has got to know when it has to redo signaling in order to
> reestablish
> stuff like it's AAA state or it's QoS state.

see comment above.

But, btw: how does the MN re-establish state without dropping the flow?
E.g. authentication? authorization? does re-establishing EF PHB make
any sense (if you cannot do it within a 100 ms, has the service not
been "dropped" anyway?)

>
> We went through this exact conversation on the MIP list with
> respect to
> BETH. The
> MN doesn't get involved in handover with BETH, so it needs to be
> informed when
> BETH handover fails (in practice, we tell it when BETH
> handover is about
> to fail).
> Then it can do standard MIP signaling in order to get a care
> of address.
>
> I'm willing to grant that having CT do feature by feature failure
> notification doesn't make sense,
> but I still think there needs to be some way to tell the MN that
> seamlessness has failed
> or is about to fail so it can take the right steps to restart the
> original network admission
> procedure.
>
> I think this is needed if for no other reason than when the MN reaches
> the edge of the operator's
> domain, if the operator doesn't have the right business
> agreements with
> the next operator, the MN
> has got to know to redo network entry, i.e. AAA from scratch, QoS from
> scratch, etc.

We agree on the first part of these two paragraphs. But, I am confused:
I am not aware of any current facilities within QoS/AAA that allows the MN
to repair AAA/QoS state as opposed to "building it from scratch". Certainly,
protocols can be extended, but then, they can also be extended to allow
for notification.

Consider:

   o CT fails for a specific context

   o CT somehow sends notification that the context for QoS has failed.

   o MN determines (somehow) what this failure message means (again, consider that
CT can, at best, notify that a particular data chunk failed somehow at the new AR,
not why).

   o MN initiates a re-negotiation with the appropriate network entity (AAA server
perhaps? an QoS Controller perhaps?)

Versus:

   o CT fails for a specific context

   o service feature entity at new AR determines that it is unable to support
     one or more of the MN flows either because it does not have the context,
     or because it cannot support the context

   o new AR determines, perhaps using local policy decisions, what mitigating
     action can to be taken locally (e.g. downgrade an AF flow to a BE flow to
     support forwarding until new negotiations can take place).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the control
     entity for the feature (e.g. the AAA server), needs to be notified (e.g.
     the service lacks proper authorization), the control entity can then take
     direct action (e.g. perhaps by some inter-system authorization exchange).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the MN is
     should fix the problem, and sends a notification.

Which scenario appears more flexible, more responsive, and more likely to
support seamless handovers?

Gary

>
>             jak
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DFFF.9DDF7DEE-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 16: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 QAA22179 for ; Tue, 9 Apr 2002 16:57:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19470; Tue, 9 Apr 2002 16:48:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19440 for ; Tue, 9 Apr 2002 16:48:15 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22056 for ; Tue, 9 Apr 2002 16:48:11 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA03313 for ; Tue, 9 Apr 2002 13:48:13 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA20514 for ; Tue, 9 Apr 2002 13:48:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NGD198T>; Tue, 9 Apr 2002 15:48:12 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650055@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , "Charles E. Perkins" Cc: Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:48:05 -0500 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 Hi Rajeev, Again sorry for the delay, I have been away from the list. I guess such hook is a design issue, i.e. how complex or simple you want your CT to be. Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 6:07 PM To: Charles E. Perkins Cc: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hello Madjid, a clarification: I don't think that Jim and I were trying to reformulate reliability requirements. They are, as Charlie points out, feature-specific. We were trying to say that the CT protocol must have a hook to inform the MN when there is an error condition (including when it is not possible to support the feature). So, I am only trying to indicate that there needs to be a notification message, since like any other protocol, CT would have error cases and failure modes. Regards, -Rajeev "Charles E. Perkins" wrote: > (I trimmed the mailing lists and some of the trailing messages) > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > > _______________________________________________ > Seamoby mailing 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 Apr 9 16: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 QAA22180 for ; Tue, 9 Apr 2002 16:57:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19379; Tue, 9 Apr 2002 16:45:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19348 for ; Tue, 9 Apr 2002 16:45:42 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21958 for ; Tue, 9 Apr 2002 16:45:39 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA20264 for ; Tue, 9 Apr 2002 13:45:41 -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 NAA17368 for ; Tue, 9 Apr 2002 13:45:41 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG854XK>; Tue, 9 Apr 2002 15:45:41 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650054@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:45:39 -0500 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 Hi Charlie, Sorry for the delay. Yes, and that was one the reasons we could not agree on the reliability requirements. Other reasons were: the uncertaintly about the underlying protocol, i.e. ICMP or SCTP or UDP or something else, plus the timing effects of retransmissions of context on handoff. BR, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Friday, April 05, 2002 5:08 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'James Kempf'; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. (I trimmed the mailing lists and some of the trailing messages) Hello Madjid, The problem is that the reliability needs depend on the context feature type. Some contexts should be transferred reliably, and some are not so crucial. Reliable transfer for header compression context is not as crucial as, say, security context -- for various reasons, but at least because retransmission for the header compression state would take too long. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 16:57: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 QAA22203 for ; Tue, 9 Apr 2002 16:57:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19815 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 16:57:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19470; Tue, 9 Apr 2002 16:48:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19440 for ; Tue, 9 Apr 2002 16:48:15 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22056 for ; Tue, 9 Apr 2002 16:48:11 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA03313 for ; Tue, 9 Apr 2002 13:48:13 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA20514 for ; Tue, 9 Apr 2002 13:48:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NGD198T>; Tue, 9 Apr 2002 15:48:12 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650055@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , "Charles E. Perkins" Cc: Nakhjiri Madjid-MNAKHJI1 , "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:48:05 -0500 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 Hi Rajeev, Again sorry for the delay, I have been away from the list. I guess such hook is a design issue, i.e. how complex or simple you want your CT to be. Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 6:07 PM To: Charles E. Perkins Cc: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hello Madjid, a clarification: I don't think that Jim and I were trying to reformulate reliability requirements. They are, as Charlie points out, feature-specific. We were trying to say that the CT protocol must have a hook to inform the MN when there is an error condition (including when it is not possible to support the feature). So, I am only trying to indicate that there needs to be a notification message, since like any other protocol, CT would have error cases and failure modes. Regards, -Rajeev "Charles E. Perkins" wrote: > (I trimmed the mailing lists and some of the trailing messages) > > Hello Madjid, > > The problem is that the reliability needs depend on the context > feature type. Some contexts should be transferred reliably, and > some are not so crucial. Reliable transfer for header compression > context is not as crucial as, say, security context -- for > various reasons, but at least because retransmission for the > header compression state would take too long. > > Regards, > Charlie P. > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > Well, you are opening a can of worm that took seamoby 3 months > > to close without any results. People could not agree on the > > reliability needs of CT. We added a reliability mechanism to our > > CT proposal that covered both retransmission and updates. > > > > Madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, April 05, 2002 12:22 PM > > To: Rajeev Koodli > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 10:02 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James Kempf wrote: > > > > > > > Rajeev, > > > > > > > > I agree, but there is still an issue of how the AR would notify the > > MN > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > This notification should be covered by CT. We should offer > > > seamless handover to NSIS :-) Seriously, this concerns > > > robustness of CT protocol. > > > > > > -Rajeev > > _______________________________________________ > Seamoby mailing 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 Apr 9 16:57: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 QAA22200 for ; Tue, 9 Apr 2002 16:57:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19817 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 16:57:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19379; Tue, 9 Apr 2002 16:45:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19348 for ; Tue, 9 Apr 2002 16:45:42 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21958 for ; Tue, 9 Apr 2002 16:45:39 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA20264 for ; Tue, 9 Apr 2002 13:45:41 -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 NAA17368 for ; Tue, 9 Apr 2002 13:45:41 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG854XK>; Tue, 9 Apr 2002 15:45:41 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650054@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: "'James Kempf'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:45:39 -0500 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 Hi Charlie, Sorry for the delay. Yes, and that was one the reasons we could not agree on the reliability requirements. Other reasons were: the uncertaintly about the underlying protocol, i.e. ICMP or SCTP or UDP or something else, plus the timing effects of retransmissions of context on handoff. BR, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Friday, April 05, 2002 5:08 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'James Kempf'; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. (I trimmed the mailing lists and some of the trailing messages) Hello Madjid, The problem is that the reliability needs depend on the context feature type. Some contexts should be transferred reliably, and some are not so crucial. Reliable transfer for header compression context is not as crucial as, say, security context -- for various reasons, but at least because retransmission for the header compression state would take too long. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 17:01: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 RAA22369 for ; Tue, 9 Apr 2002 17:01:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19732; Tue, 9 Apr 2002 16:55:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19680 for ; Tue, 9 Apr 2002 16:55:38 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22153; Tue, 9 Apr 2002 16:55:33 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA27478; Tue, 9 Apr 2002 13:44:05 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA18551; Tue, 9 Apr 2002 13:55:35 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG85VCB>; Tue, 9 Apr 2002 15:55:35 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650056@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli Cc: nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:55:33 -0500 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, As I said, it depends on how complicated you want the CT to be. I thought we were supposed to see CT as a container and not look into contents. Ideally the two networks communicating with each other have some clue about each other (either part of same admin domain, and hence all capabilities are known, or different admin domain, in which case, roaming agreements might be needed). Why should CT itself care about whether what it is carrying make sense to the newAR or not, it can, like any other signaling protocol (NSIS as an example) carry a lot of opaque info. At the most maybe a notification like what Rajeev proposed. Going further than that you need to be careful not to get into specific feature issues. BR, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 10:42 AM To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Madjid, The issue isn't reliability, it is whether the target AR can interpret the context intelligably. If not, the MN may need to recover by actually re-initializing whatever feature the context was being transfered for. But it cannot do this unless it knows that the CT has failed. For some feature contexts, like header compression, this isn't a problem because it will re-initialize automatically, but for AAA or QoS it clearly will be. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 3:00 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev > > > > > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 9:19 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello Jim, > > > > > > > > James Kempf wrote: > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > negotiation > > > > > after handover would be required. > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > notify the MN to engage in context re-creation. > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > signaling) > > > > independent of failure/success of CT. > > > > > > > > Hope this is clearer.. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > though it > > > may > > > > > be useful for finding a new wireless medium. I also see it > primarily > > > for > > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > > > jak > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "Gary Kenward" > > > > > Cc: ; ; > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > protocol. The main application that you are referring to > > > primarily > > > > > > > arises out of a perceived need to determine at the MN the > best > > > link > > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > > involved. > > > > > > > It can be applied to intra-technology handovers, but the > value > > > in > > > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > > > protocol, the implication is that the purpose is to > determine > > > the > > > > > > > choice of channels available; for intra-technology > handovers, > > > there > > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > > involvement > > > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > > intention > > > > > > > (please correct me if I have this wrong John), in which case > I > > > think > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for > an > > > > > > > existing flow after a handover, or is it specifically for > > > > > establishing > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > > clearly > > > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > > > change. > > > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > > scenario: > > > > > > > > > > > > > > - a handover takes place, and context transfer has > been > > > used > > > > > > > to > > > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > > > for > > > > > > > CT this could be intra-, or inter- technology. Some > of us > > > > > > > believe > > > > > > > that for "seamless" handovers, the context will be > > > available > > > > > at > > > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > > This > > > > > > > implies > > > > > > > that there is a relationship, probabilistic perhaps, > > > between > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > decision > > > (it > > > > > > > is not clear to me how this happens, but it seems > clear > > > that > > > > > > > for a more "seamless" handover, the MN should chose > an AR > > > > > that > > > > > > > has received the appropriate context; if not, then > what? > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because > of > > > > > changes > > > > > > > introduced by the handover; > > > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > > outcomes? > > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > > with the three protocols interact before, during and after a > > > > > handover? > > > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > > wg's could declare the issue out of scope, but this approach > > > does > > > > > not > > > > > > > sit well with me, for it seems to defer the problem to the > > > people > > > > > who > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > Cheers, > > > > > > > Gary > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hemant.Chaskar@nokia.com > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > To: nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > whether > > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > > > Br, > > > > > > > > Hemant > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned > with > > > the > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > negotiation, which ideally > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > > with activity > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing 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 > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 17:01: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 RAA22387 for ; Tue, 9 Apr 2002 17:01:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20851 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 17:01:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19732; Tue, 9 Apr 2002 16:55:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19680 for ; Tue, 9 Apr 2002 16:55:38 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22153; Tue, 9 Apr 2002 16:55:33 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA27478; Tue, 9 Apr 2002 13:44:05 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA18551; Tue, 9 Apr 2002 13:55:35 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG85VCB>; Tue, 9 Apr 2002 15:55:35 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650056@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli Cc: nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:55:33 -0500 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, As I said, it depends on how complicated you want the CT to be. I thought we were supposed to see CT as a container and not look into contents. Ideally the two networks communicating with each other have some clue about each other (either part of same admin domain, and hence all capabilities are known, or different admin domain, in which case, roaming agreements might be needed). Why should CT itself care about whether what it is carrying make sense to the newAR or not, it can, like any other signaling protocol (NSIS as an example) carry a lot of opaque info. At the most maybe a notification like what Rajeev proposed. Going further than that you need to be careful not to get into specific feature issues. BR, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 10:42 AM To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Madjid, The issue isn't reliability, it is whether the target AR can interpret the context intelligably. If not, the MN may need to recover by actually re-initializing whatever feature the context was being transfered for. But it cannot do this unless it knows that the CT has failed. For some feature contexts, like header compression, this isn't a problem because it will re-initialize automatically, but for AAA or QoS it clearly will be. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 3:00 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev > > > > > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 9:19 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello Jim, > > > > > > > > James Kempf wrote: > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > negotiation > > > > > after handover would be required. > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > notify the MN to engage in context re-creation. > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > signaling) > > > > independent of failure/success of CT. > > > > > > > > Hope this is clearer.. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > though it > > > may > > > > > be useful for finding a new wireless medium. I also see it > primarily > > > for > > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > > > jak > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "Gary Kenward" > > > > > Cc: ; ; > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > protocol. The main application that you are referring to > > > primarily > > > > > > > arises out of a perceived need to determine at the MN the > best > > > link > > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > > involved. > > > > > > > It can be applied to intra-technology handovers, but the > value > > > in > > > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > > > protocol, the implication is that the purpose is to > determine > > > the > > > > > > > choice of channels available; for intra-technology > handovers, > > > there > > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > > involvement > > > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > > intention > > > > > > > (please correct me if I have this wrong John), in which case > I > > > think > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for > an > > > > > > > existing flow after a handover, or is it specifically for > > > > > establishing > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > > clearly > > > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > > > change. > > > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > > scenario: > > > > > > > > > > > > > > - a handover takes place, and context transfer has > been > > > used > > > > > > > to > > > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > > > for > > > > > > > CT this could be intra-, or inter- technology. Some > of us > > > > > > > believe > > > > > > > that for "seamless" handovers, the context will be > > > available > > > > > at > > > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > > This > > > > > > > implies > > > > > > > that there is a relationship, probabilistic perhaps, > > > between > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > decision > > > (it > > > > > > > is not clear to me how this happens, but it seems > clear > > > that > > > > > > > for a more "seamless" handover, the MN should chose > an AR > > > > > that > > > > > > > has received the appropriate context; if not, then > what? > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because > of > > > > > changes > > > > > > > introduced by the handover; > > > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > > outcomes? > > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > > with the three protocols interact before, during and after a > > > > > handover? > > > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > > wg's could declare the issue out of scope, but this approach > > > does > > > > > not > > > > > > > sit well with me, for it seems to defer the problem to the > > > people > > > > > who > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > Cheers, > > > > > > > Gary > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hemant.Chaskar@nokia.com > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > To: nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > whether > > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > > > Br, > > > > > > > > Hemant > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned > with > > > the > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > negotiation, which ideally > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > > with activity > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing 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 > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 17:16: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 RAA23031 for ; Tue, 9 Apr 2002 17:16:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21253; Tue, 9 Apr 2002 17:06:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21132 for ; Tue, 9 Apr 2002 17:06:28 -0400 (EDT) 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 RAA22645 for ; Tue, 9 Apr 2002 17:06:23 -0400 (EDT) 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 OAA12715; Tue, 9 Apr 2002 14:05:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39L5ou28234; Tue, 9 Apr 2002 14:05:50 -0700 X-mProtect: <200204092105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd98dN1e; Tue, 09 Apr 2002 14:05:49 PDT Message-ID: <3CB357AD.3F6689E1@iprg.nokia.com> Date: Tue, 09 Apr 2002 14:05:49 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B04650054@IL27EXM10.cig.mot.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 Hello Madjid, I think that the underlying protocol has to be selected in order to meet the needs of the contexts that are going to be transferred. These needs ought to be encoded and discernible as part of the definition of the context feature. In our framework, that would make it a property of the profile type for the feature. There are other details surrounding the aggregation of various contexts for transfer as part of the same message during handover. Nevertheless, the process of figuring out the detailed requirements is straightforward, and tedious. My preference would be to allow several possibilities for the transport protocol. We might want to use SCTP for context transfers that don't have time critical needs, or between access routers that can maintain nailed-up connections. We might want to use something else for context transfers between access routers that have no such open connections, or for transfers that exclude the possibility of retransmission for the context feature data. The underlying protocol could itself be specified as part of the profile data for the context feature. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Hi Charlie, > > Sorry for the delay. > Yes, and that was one the reasons we could not agree on > the reliability requirements. Other reasons were: > the uncertaintly about the underlying protocol, i.e. ICMP > or SCTP or UDP or something else, plus the timing effects > of retransmissions of context on handoff. > > BR, > Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 17:16: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 RAA23043 for ; Tue, 9 Apr 2002 17:16:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21298; Tue, 9 Apr 2002 17:06:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21166 for ; Tue, 9 Apr 2002 17:06:29 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22643; Tue, 9 Apr 2002 17:06:19 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA13133; Tue, 9 Apr 2002 14:06:18 -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 NAA17925; Tue, 9 Apr 2002 13:53:56 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG85VMD>; Tue, 9 Apr 2002 16:06:18 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650057@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:06:13 -0500 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 if the newAR does not have enough bandwidth for the MN, there should not be a handover (that is why CAR needs to handle capability issues as I said before). I wonder in such a case, would it not be easier to just redo QoS signaling based on some NSIS-like protocol. We are not insisting on absolutely do CT until the end of time, regardless of how many time it fails. The design must be flexible enough to handle handover delays as much as possible. I must say that if you make a simple concept such as context transfer to be handled by a too complicate protocol, people will not use it. So it is your choice. I was not at the last IETF and the meeting minutes have not been posted to the list, can you tell me when and how the CT selection process is going to happen? Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 1:26 PM To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Gary, I don't think the issue is having the MN re-create the context. Is is allowing the MN to recover by re-running the actions that were necessary to create the context in the first place, in the event the AR was unable to interpret it. Thus, for example, suppose that QoS context is transferred from old to new AR, but new AR for some reason can't interpret it, perhaps there is no bandwidth left or perhaps the new AR uses a different representation for QoS context. The MN would need to be informed somehow so that it could re-do its QoS signaling. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 10:54 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Tue Apr 9 17:16: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 RAA23061 for ; Tue, 9 Apr 2002 17:16:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21809 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 17:16:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21298; Tue, 9 Apr 2002 17:06:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21166 for ; Tue, 9 Apr 2002 17:06:29 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22643; Tue, 9 Apr 2002 17:06:19 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA13133; Tue, 9 Apr 2002 14:06:18 -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 NAA17925; Tue, 9 Apr 2002 13:53:56 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG85VMD>; Tue, 9 Apr 2002 16:06:18 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650057@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:06:13 -0500 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 if the newAR does not have enough bandwidth for the MN, there should not be a handover (that is why CAR needs to handle capability issues as I said before). I wonder in such a case, would it not be easier to just redo QoS signaling based on some NSIS-like protocol. We are not insisting on absolutely do CT until the end of time, regardless of how many time it fails. The design must be flexible enough to handle handover delays as much as possible. I must say that if you make a simple concept such as context transfer to be handled by a too complicate protocol, people will not use it. So it is your choice. I was not at the last IETF and the meeting minutes have not been posted to the list, can you tell me when and how the CT selection process is going to happen? Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 1:26 PM To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Gary, I don't think the issue is having the MN re-create the context. Is is allowing the MN to recover by re-running the actions that were necessary to create the context in the first place, in the event the AR was unable to interpret it. Thus, for example, suppose that QoS context is transferred from old to new AR, but new AR for some reason can't interpret it, perhaps there is no bandwidth left or perhaps the new AR uses a different representation for QoS context. The MN would need to be informed somehow so that it could re-do its QoS signaling. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 10:54 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing 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 Tue Apr 9 17:16: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 RAA23060 for ; Tue, 9 Apr 2002 17:16:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21805 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 17:16:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21253; Tue, 9 Apr 2002 17:06:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21132 for ; Tue, 9 Apr 2002 17:06:28 -0400 (EDT) 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 RAA22645 for ; Tue, 9 Apr 2002 17:06:23 -0400 (EDT) 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 OAA12715; Tue, 9 Apr 2002 14:05:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39L5ou28234; Tue, 9 Apr 2002 14:05:50 -0700 X-mProtect: <200204092105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd98dN1e; Tue, 09 Apr 2002 14:05:49 PDT Message-ID: <3CB357AD.3F6689E1@iprg.nokia.com> Date: Tue, 09 Apr 2002 14:05:49 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B04650054@IL27EXM10.cig.mot.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 Hello Madjid, I think that the underlying protocol has to be selected in order to meet the needs of the contexts that are going to be transferred. These needs ought to be encoded and discernible as part of the definition of the context feature. In our framework, that would make it a property of the profile type for the feature. There are other details surrounding the aggregation of various contexts for transfer as part of the same message during handover. Nevertheless, the process of figuring out the detailed requirements is straightforward, and tedious. My preference would be to allow several possibilities for the transport protocol. We might want to use SCTP for context transfers that don't have time critical needs, or between access routers that can maintain nailed-up connections. We might want to use something else for context transfers between access routers that have no such open connections, or for transfers that exclude the possibility of retransmission for the context feature data. The underlying protocol could itself be specified as part of the profile data for the context feature. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Hi Charlie, > > Sorry for the delay. > Yes, and that was one the reasons we could not agree on > the reliability requirements. Other reasons were: > the uncertaintly about the underlying protocol, i.e. ICMP > or SCTP or UDP or something else, plus the timing effects > of retransmissions of context on handoff. > > BR, > Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 17: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 RAA23103 for ; Tue, 9 Apr 2002 17:17:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21453; Tue, 9 Apr 2002 17:09:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21384 for ; Tue, 9 Apr 2002 17:09:01 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22793; Tue, 9 Apr 2002 17:08:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA27849; Tue, 9 Apr 2002 14:08:58 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA05092; Tue, 9 Apr 2002 14:08:58 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <2NF0LHPR>; Tue, 9 Apr 2002 16:08:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650058@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:08:53 -0500 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 all you have to do is to add a CT-NACK, please, look at our TEXT proposal. We even have a CT-NACK for each feature. madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 1:32 PM To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Gary, I agree about session establishment, but the fact remains that if failure of a context transfer for some reason leaves the MN without any indication that it should proceed to re-establish the feature, then the MN can't know when it should redo signaling to set up its new state. We faced this issue with BETH/FMIPv6 and the solution we found there was to have routers on the border of a fast handover coverage area inform the MN what handover algorithm was supported by routers in the other coverage area. While I think this could be done for the cases involving router configuration, such as where the next access router can't interpret the context, I am not so sure about failure due to dynamic conditions, such as that the router currently has all its Gold Class service bandwidth allocated (a QoS failure). In any event, I think there is need for some kind of signaling to indicate to the MN that context transfer has failed and that the MN needs to redo signaling to re-establish feature contexts. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 11:08 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > My main problem with the theme in this discussion is that > CT is a context transfer protocol, not a session management protocol. > In particular, when there are feature context specific issues, it is > best to handle session re-establishment/re-negotiation/maintenance using > the protocol(s) that were designed to set up the services in the first > place. CT should not be stretched into being a general signalling protocol. > > In addition, there is the perhaps greater argument that the most > effective method of correcting handover issues is not through over > the air signalling exchanges. Given the nature of the wireless link, > it will almost always be faster and always be more cost effective, to > correct any problems with signalling within the infrastructure (if it is > needed). > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 11:42 > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Madjid, > > > > The issue isn't reliability, it is whether the target AR can interpret > > the context intelligably. If not, the MN may need to recover > > by actually > > re-initializing whatever feature the context was being transfered for. > > But it cannot do this unless it knows that the CT has failed. > > > > For some feature contexts, like header compression, this > > isn't a problem > > because it will re-initialize automatically, but for AAA or QoS it > > clearly will be. > > > > jak > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 3:00 PM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify > > the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > negotiation > > > > > > > after handover would be required. > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > > > signaling) > > > > > > independent of failure/success of CT. > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > though it > > > > > may > > > > > > > be useful for finding a new wireless medium. I also see it > > > primarily > > > > > for > > > > > > > intertechnology handover, or, at best, > > interprovider handover. > > > > > > > > > > > > > > jak > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "Gary Kenward" > > > > > > > Cc: ; ; > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > establishment > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > one of the > > > > > > > > parameters that might then be fed to a selection > > algorithm. > > > Any > > > > > > > > signaling for actually establishing QoS itself > > beyond the AR > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > understand CARD > > > (and > > > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > > > protocol. The main application that you are referring to > > > > > primarily > > > > > > > > > arises out of a perceived need to determine at > > the MN the > > > best > > > > > link > > > > > > > > > layer to handover over to when inter-technology > > handovers > > > are > > > > > > > > > involved. > > > > > > > > > It can be applied to intra-technology handovers, but the > > > value > > > > > in > > > > > > > > > that situation is highly questionable (e.g. > > since it is a > > > > > discovery > > > > > > > > > protocol, the implication is that the purpose is to > > > determine > > > > > the > > > > > > > > > choice of channels available; for intra-technology > > > handovers, > > > > > there > > > > > > > > > are many, many reasons why this "choice" may not be > > > available). > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > imply NSIS > > > > > > > involvement > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > this is not > > > the > > > > > > > > > intention > > > > > > > > > (please correct me if I have this wrong John), in which > > case > > > I > > > > > think > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS > > for > > > an > > > > > > > > > existing flow after a handover, or is it > > specifically for > > > > > > > establishing > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: > > the > > > > > role > > > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and > > > > > clearly > > > > > > > > > handover is a dynamic situation that could cause the QoS > > > > > provided to > > > > > > > > > change. > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > frightening > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > transfer has > > > been > > > > > used > > > > > > > > > to > > > > > > > > > move the QoS context to the new routers (by the > > > > > requirements > > > > > > > > > for > > > > > > > > > CT this could be intra-, or inter- > > technology. Some > > > of us > > > > > > > > > believe > > > > > > > > > that for "seamless" handovers, the > > context will be > > > > > available > > > > > > > at > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > forwarded. > > > > > This > > > > > > > > > implies > > > > > > > > > that there is a relationship, probabilistic > > perhaps, > > > > > between > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision > > > > > (it > > > > > > > > > is not clear to me how this happens, but it seems > > > clear > > > > > that > > > > > > > > > for a more "seamless" handover, the MN > > should chose > > > an AR > > > > > > > that > > > > > > > > > has received the appropriate context; if > > not, then > > > what? > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > QoS because > > > of > > > > > > > changes > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > predictable > > > > > > > > > outcomes? > > > > > > > > > Or, perhaps, the question is, how do the functional > > entities > > > > > > > > > associated > > > > > > > > > with the three protocols interact before, > > during and after > > a > > > > > > > handover? > > > > > > > > > > > > > > > > > > If it the interaction is within the functional entities, > > the > > > > > > > > > respective > > > > > > > > > wg's could declare the issue out of scope, but this > > approach > > > > > does > > > > > > > not > > > > > > > > > sit well with me, for it seems to defer the > > problem to the > > > > > people > > > > > > > who > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > > > whether > > > > > > > > > > this QoS negotiation be covered by NSIS or > > Seamoby (CAR > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > and not NSIS. > > > CAR > > > > > > > > > > discovery is supposed to identify candidate access > > routers > > > > > > > > > > for handoff and QoS is an important property for > > > candidacy. > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > be concerned > > > with > > > > > the > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > negotiation, which ideally > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > concerned > > > > > > > > > > with activity > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Seamoby mailing 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 > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 17: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 RAA23116 for ; Tue, 9 Apr 2002 17:17:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21855 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 17:17:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21453; Tue, 9 Apr 2002 17:09:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21384 for ; Tue, 9 Apr 2002 17:09:01 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22793; Tue, 9 Apr 2002 17:08:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA27849; Tue, 9 Apr 2002 14:08:58 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA05092; Tue, 9 Apr 2002 14:08:58 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <2NF0LHPR>; Tue, 9 Apr 2002 16:08:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650058@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:08:53 -0500 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 all you have to do is to add a CT-NACK, please, look at our TEXT proposal. We even have a CT-NACK for each feature. madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 1:32 PM To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Gary, I agree about session establishment, but the fact remains that if failure of a context transfer for some reason leaves the MN without any indication that it should proceed to re-establish the feature, then the MN can't know when it should redo signaling to set up its new state. We faced this issue with BETH/FMIPv6 and the solution we found there was to have routers on the border of a fast handover coverage area inform the MN what handover algorithm was supported by routers in the other coverage area. While I think this could be done for the cases involving router configuration, such as where the next access router can't interpret the context, I am not so sure about failure due to dynamic conditions, such as that the router currently has all its Gold Class service bandwidth allocated (a QoS failure). In any event, I think there is need for some kind of signaling to indicate to the MN that context transfer has failed and that the MN needs to redo signaling to re-establish feature contexts. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 11:08 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > My main problem with the theme in this discussion is that > CT is a context transfer protocol, not a session management protocol. > In particular, when there are feature context specific issues, it is > best to handle session re-establishment/re-negotiation/maintenance using > the protocol(s) that were designed to set up the services in the first > place. CT should not be stretched into being a general signalling protocol. > > In addition, there is the perhaps greater argument that the most > effective method of correcting handover issues is not through over > the air signalling exchanges. Given the nature of the wireless link, > it will almost always be faster and always be more cost effective, to > correct any problems with signalling within the infrastructure (if it is > needed). > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 11:42 > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Madjid, > > > > The issue isn't reliability, it is whether the target AR can interpret > > the context intelligably. If not, the MN may need to recover > > by actually > > re-initializing whatever feature the context was being transfered for. > > But it cannot do this unless it knows that the CT has failed. > > > > For some feature contexts, like header compression, this > > isn't a problem > > because it will re-initialize automatically, but for AAA or QoS it > > clearly will be. > > > > jak > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 3:00 PM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify > > the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > negotiation > > > > > > > after handover would be required. > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > > > signaling) > > > > > > independent of failure/success of CT. > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > though it > > > > > may > > > > > > > be useful for finding a new wireless medium. I also see it > > > primarily > > > > > for > > > > > > > intertechnology handover, or, at best, > > interprovider handover. > > > > > > > > > > > > > > jak > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "Gary Kenward" > > > > > > > Cc: ; ; > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > establishment > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > one of the > > > > > > > > parameters that might then be fed to a selection > > algorithm. > > > Any > > > > > > > > signaling for actually establishing QoS itself > > beyond the AR > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > understand CARD > > > (and > > > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > > > protocol. The main application that you are referring to > > > > > primarily > > > > > > > > > arises out of a perceived need to determine at > > the MN the > > > best > > > > > link > > > > > > > > > layer to handover over to when inter-technology > > handovers > > > are > > > > > > > > > involved. > > > > > > > > > It can be applied to intra-technology handovers, but the > > > value > > > > > in > > > > > > > > > that situation is highly questionable (e.g. > > since it is a > > > > > discovery > > > > > > > > > protocol, the implication is that the purpose is to > > > determine > > > > > the > > > > > > > > > choice of channels available; for intra-technology > > > handovers, > > > > > there > > > > > > > > > are many, many reasons why this "choice" may not be > > > available). > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > imply NSIS > > > > > > > involvement > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > this is not > > > the > > > > > > > > > intention > > > > > > > > > (please correct me if I have this wrong John), in which > > case > > > I > > > > > think > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS > > for > > > an > > > > > > > > > existing flow after a handover, or is it > > specifically for > > > > > > > establishing > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: > > the > > > > > role > > > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and > > > > > clearly > > > > > > > > > handover is a dynamic situation that could cause the QoS > > > > > provided to > > > > > > > > > change. > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > frightening > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > transfer has > > > been > > > > > used > > > > > > > > > to > > > > > > > > > move the QoS context to the new routers (by the > > > > > requirements > > > > > > > > > for > > > > > > > > > CT this could be intra-, or inter- > > technology. Some > > > of us > > > > > > > > > believe > > > > > > > > > that for "seamless" handovers, the > > context will be > > > > > available > > > > > > > at > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > forwarded. > > > > > This > > > > > > > > > implies > > > > > > > > > that there is a relationship, probabilistic > > perhaps, > > > > > between > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision > > > > > (it > > > > > > > > > is not clear to me how this happens, but it seems > > > clear > > > > > that > > > > > > > > > for a more "seamless" handover, the MN > > should chose > > > an AR > > > > > > > that > > > > > > > > > has received the appropriate context; if > > not, then > > > what? > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > QoS because > > > of > > > > > > > changes > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > predictable > > > > > > > > > outcomes? > > > > > > > > > Or, perhaps, the question is, how do the functional > > entities > > > > > > > > > associated > > > > > > > > > with the three protocols interact before, > > during and after > > a > > > > > > > handover? > > > > > > > > > > > > > > > > > > If it the interaction is within the functional entities, > > the > > > > > > > > > respective > > > > > > > > > wg's could declare the issue out of scope, but this > > approach > > > > > does > > > > > > > not > > > > > > > > > sit well with me, for it seems to defer the > > problem to the > > > > > people > > > > > > > who > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > > > whether > > > > > > > > > > this QoS negotiation be covered by NSIS or > > Seamoby (CAR > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > and not NSIS. > > > CAR > > > > > > > > > > discovery is supposed to identify candidate access > > routers > > > > > > > > > > for handoff and QoS is an important property for > > > candidacy. > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > be concerned > > > with > > > > > the > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > negotiation, which ideally > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > concerned > > > > > > > > > > with activity > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > nsis mailing list > > > > > > > > > > nsis@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Seamoby mailing 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 > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 17:29: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 RAA23504 for ; Tue, 9 Apr 2002 17:29:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22202; Tue, 9 Apr 2002 17:23:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22170 for ; Tue, 9 Apr 2002 17:23:22 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23319 for ; Tue, 9 Apr 2002 17:23:18 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA06041 for ; Tue, 9 Apr 2002 14:23:19 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA03975 for ; Tue, 9 Apr 2002 14:23:18 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NGDFAJ4>; Tue, 9 Apr 2002 16:23:18 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650059@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:23:10 -0500 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 Charlie, I agree that the design of reliability mechanisms for CT depends on the underlying transport protocol and that is exactly why, we could not agree on the reliability. However, as we pointed out in our TEXT proposal, some reliability issues cannot be handled even by reliable transport such as SCTP. and one such issue is the need for update. If your state (say header compression) has changed since last CT, you cannot retx the old context, you need to send an updated context, and we handled this with a flag in our design. I think we discussed many of the issues that are currently being discussed on this list. But due to the delay in the selection process, we have not updated or renewed the draft. Anyway the 00 version is here (expiring soon). ftp://ftp.isi.edu/internet-drafts/draft-nakhjiri-seamoby-text-ct-00.txt We would be happy to get any comments. Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Tuesday, April 09, 2002 4:06 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hello Madjid, I think that the underlying protocol has to be selected in order to meet the needs of the contexts that are going to be transferred. These needs ought to be encoded and discernible as part of the definition of the context feature. In our framework, that would make it a property of the profile type for the feature. There are other details surrounding the aggregation of various contexts for transfer as part of the same message during handover. Nevertheless, the process of figuring out the detailed requirements is straightforward, and tedious. My preference would be to allow several possibilities for the transport protocol. We might want to use SCTP for context transfers that don't have time critical needs, or between access routers that can maintain nailed-up connections. We might want to use something else for context transfers between access routers that have no such open connections, or for transfers that exclude the possibility of retransmission for the context feature data. The underlying protocol could itself be specified as part of the profile data for the context feature. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Hi Charlie, > > Sorry for the delay. > Yes, and that was one the reasons we could not agree on > the reliability requirements. Other reasons were: > the uncertaintly about the underlying protocol, i.e. ICMP > or SCTP or UDP or something else, plus the timing effects > of retransmissions of context on handoff. > > BR, > Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 17:29: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 RAA23517 for ; Tue, 9 Apr 2002 17:29:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22623 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 17:29:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22202; Tue, 9 Apr 2002 17:23:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22170 for ; Tue, 9 Apr 2002 17:23:22 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23319 for ; Tue, 9 Apr 2002 17:23:18 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA06041 for ; Tue, 9 Apr 2002 14:23:19 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA03975 for ; Tue, 9 Apr 2002 14:23:18 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NGDFAJ4>; Tue, 9 Apr 2002 16:23:18 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650059@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Charles E. Perkins'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:23:10 -0500 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 Charlie, I agree that the design of reliability mechanisms for CT depends on the underlying transport protocol and that is exactly why, we could not agree on the reliability. However, as we pointed out in our TEXT proposal, some reliability issues cannot be handled even by reliable transport such as SCTP. and one such issue is the need for update. If your state (say header compression) has changed since last CT, you cannot retx the old context, you need to send an updated context, and we handled this with a flag in our design. I think we discussed many of the issues that are currently being discussed on this list. But due to the delay in the selection process, we have not updated or renewed the draft. Anyway the 00 version is here (expiring soon). ftp://ftp.isi.edu/internet-drafts/draft-nakhjiri-seamoby-text-ct-00.txt We would be happy to get any comments. Regards, Madjid -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Tuesday, April 09, 2002 4:06 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hello Madjid, I think that the underlying protocol has to be selected in order to meet the needs of the contexts that are going to be transferred. These needs ought to be encoded and discernible as part of the definition of the context feature. In our framework, that would make it a property of the profile type for the feature. There are other details surrounding the aggregation of various contexts for transfer as part of the same message during handover. Nevertheless, the process of figuring out the detailed requirements is straightforward, and tedious. My preference would be to allow several possibilities for the transport protocol. We might want to use SCTP for context transfers that don't have time critical needs, or between access routers that can maintain nailed-up connections. We might want to use something else for context transfers between access routers that have no such open connections, or for transfers that exclude the possibility of retransmission for the context feature data. The underlying protocol could itself be specified as part of the profile data for the context feature. Regards, Charlie P. Nakhjiri Madjid-MNAKHJI1 wrote: > > Hi Charlie, > > Sorry for the delay. > Yes, and that was one the reasons we could not agree on > the reliability requirements. Other reasons were: > the uncertaintly about the underlying protocol, i.e. ICMP > or SCTP or UDP or something else, plus the timing effects > of retransmissions of context on handoff. > > BR, > Madjid _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 9 17:34: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 RAA23749 for ; Tue, 9 Apr 2002 17:34:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22527; Tue, 9 Apr 2002 17:28:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22392 for ; Tue, 9 Apr 2002 17:28:11 -0400 (EDT) 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 RAA23469; Tue, 9 Apr 2002 17:28:06 -0400 (EDT) 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 OAA14442; Tue, 9 Apr 2002 14:27:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39LRbD23390; Tue, 9 Apr 2002 14:27:37 -0700 X-mProtect: <200204092127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqatjt3; Tue, 09 Apr 2002 14:27:35 PDT Message-ID: <3CB35CC7.4F017391@iprg.nokia.com> Date: Tue, 09 Apr 2002 14:27:36 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: "'James Kempf'" , Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B04650058@IL27EXM10.cig.mot.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 Nakhjiri Madjid-MNAKHJI1 wrote: > all you have to do is to add a CT-NACK, > please, look at our TEXT proposal. > We even have a CT-NACK for each feature. Right. A simple notification message would suffice. BTW, in our framework we call it CTIN-Ack now (Section 5.2); earlier versions (going back to Pittsburgh IETF) called it SHACK :-) Regards, -Rajeev > > > madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, April 08, 2002 1:32 PM > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). > > In any event, I think there is need for some kind of signaling to > indicate to the MN that context transfer has failed and that the MN > needs to redo signaling to re-establish feature contexts. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > Cc: ; ; > Sent: Monday, April 08, 2002 11:08 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James: > > > > My main problem with the theme in this discussion is that > > CT is a context transfer protocol, not a session management protocol. > > In particular, when there are feature context specific issues, it is > > best to handle session re-establishment/re-negotiation/maintenance > using > > the protocol(s) that were designed to set up the services in the first > > place. CT should not be stretched into being a general signalling > protocol. > > > > In addition, there is the perhaps greater argument that the most > > effective method of correcting handover issues is not through over > > the air signalling exchanges. Given the nature of the wireless link, > > it will almost always be faster and always be more cost effective, to > > correct any problems with signalling within the infrastructure (if it > is > > needed). > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 11:42 > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Madjid, > > > > > > The issue isn't reliability, it is whether the target AR can > interpret > > > the context intelligably. If not, the MN may need to recover > > > by actually > > > re-initializing whatever feature the context was being transfered > for. > > > But it cannot do this unless it knows that the CT has failed. > > > > > > For some feature contexts, like header compression, this > > > isn't a problem > > > because it will re-initialize automatically, but for AAA or QoS it > > > clearly will be. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 3:00 PM > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > to close without any results. People could not agree on the > > > > reliability needs of CT. We added a reliability mechanism to our > > > > CT proposal that covered both retransmission and updates. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > To: Rajeev Koodli > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Agree. > > > > > > > > But I don't see anything in the CT requirements about handling CT > > > > failure. > > > > > > > > ??? > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "James Kempf" > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > Rajeev, > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > notify > > > the > > > > MN > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > robustness of CT protocol. > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Rajeev Koodli" > > > > > > To: "James Kempf" > > > > > > Cc: "Gary Kenward" ; > > > > > > ; ; > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > after handoff. > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > > negotiation > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > should > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > upstream > > > > > > signaling) > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > > though it > > > > > > may > > > > > > > > be useful for finding a new wireless medium. I also see it > > > > primarily > > > > > > for > > > > > > > > intertechnology handover, or, at best, > > > interprovider handover. > > > > > > > > > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Rajeev Koodli" > > > > > > > > To: "Gary Kenward" > > > > > > > > Cc: ; ; > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > may > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > establishment > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > one of the > > > > > > > > > parameters that might then be fed to a selection > > > algorithm. > > > > Any > > > > > > > > > signaling for actually establishing QoS itself > > > beyond the AR > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > understand CARD > > > > (and > > > > > > > > > > I don't understand it well), it is not a QoS > negotiation > > > > > > > > > > protocol. The main application that you are referring > to > > > > > > primarily > > > > > > > > > > arises out of a perceived need to determine at > > > the MN the > > > > best > > > > > > link > > > > > > > > > > layer to handover over to when inter-technology > > > handovers > > > > are > > > > > > > > > > involved. > > > > > > > > > > It can be applied to intra-technology handovers, but > the > > > > value > > > > > > in > > > > > > > > > > that situation is highly questionable (e.g. > > > since it is a > > > > > > discovery > > > > > > > > > > protocol, the implication is that the purpose is to > > > > determine > > > > > > the > > > > > > > > > > choice of channels available; for intra-technology > > > > handovers, > > > > > > there > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > available). > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > imply NSIS > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > this is not > > > > the > > > > > > > > > > intention > > > > > > > > > > (please correct me if I have this wrong John), in > which > > > case > > > > I > > > > > > think > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS > > > for > > > > an > > > > > > > > > > existing flow after a handover, or is it > > > specifically for > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > boolean: > > > the > > > > > > role > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > believe, > > > and > > > > > > clearly > > > > > > > > > > handover is a dynamic situation that could cause the > QoS > > > > > > provided to > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > frightening > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > transfer has > > > > been > > > > > > used > > > > > > > > > > to > > > > > > > > > > move the QoS context to the new routers (by the > > > > > > requirements > > > > > > > > > > for > > > > > > > > > > CT this could be intra-, or inter- > > > technology. Some > > > > of us > > > > > > > > > > believe > > > > > > > > > > that for "seamless" handovers, the > > > context will be > > > > > > available > > > > > > > > at > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > forwarded. > > > > > > This > > > > > > > > > > implies > > > > > > > > > > that there is a relationship, probabilistic > > > perhaps, > > > > > > between > > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > handover > > > > decision > > > > > > (it > > > > > > > > > > is not clear to me how this happens, but it > seems > > > > clear > > > > > > that > > > > > > > > > > for a more "seamless" handover, the MN > > > should chose > > > > an AR > > > > > > > > that > > > > > > > > > > has received the appropriate context; if > > > not, then > > > > what? > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > QoS because > > > > of > > > > > > > > changes > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > predictable > > > > > > > > > > outcomes? > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > entities > > > > > > > > > > associated > > > > > > > > > > with the three protocols interact before, > > > during and after > > > a > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > entities, > > > the > > > > > > > > > > respective > > > > > > > > > > wg's could declare the issue out of scope, but this > > > approach > > > > > > does > > > > > > > > not > > > > > > > > > > sit well with me, for it seems to defer the > > > problem to the > > > > > > people > > > > > > > > who > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to > > > > whether > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > Seamoby (CAR > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > and not NSIS. > > > > CAR > > > > > > > > > > > discovery is supposed to identify candidate access > > > routers > > > > > > > > > > > for handoff and QoS is an important property for > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > be concerned > > > > with > > > > > > the > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > draft. > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > concerned > > > > > > > > > > > with activity > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 9 17:34: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 RAA23769 for ; Tue, 9 Apr 2002 17:34:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23289 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 17:34:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22527; Tue, 9 Apr 2002 17:28:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22392 for ; Tue, 9 Apr 2002 17:28:11 -0400 (EDT) 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 RAA23469; Tue, 9 Apr 2002 17:28:06 -0400 (EDT) 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 OAA14442; Tue, 9 Apr 2002 14:27:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39LRbD23390; Tue, 9 Apr 2002 14:27:37 -0700 X-mProtect: <200204092127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqatjt3; Tue, 09 Apr 2002 14:27:35 PDT Message-ID: <3CB35CC7.4F017391@iprg.nokia.com> Date: Tue, 09 Apr 2002 14:27:36 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: "'James Kempf'" , Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B04650058@IL27EXM10.cig.mot.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 Nakhjiri Madjid-MNAKHJI1 wrote: > all you have to do is to add a CT-NACK, > please, look at our TEXT proposal. > We even have a CT-NACK for each feature. Right. A simple notification message would suffice. BTW, in our framework we call it CTIN-Ack now (Section 5.2); earlier versions (going back to Pittsburgh IETF) called it SHACK :-) Regards, -Rajeev > > > madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, April 08, 2002 1:32 PM > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). > > In any event, I think there is need for some kind of signaling to > indicate to the MN that context transfer has failed and that the MN > needs to redo signaling to re-establish feature contexts. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > Cc: ; ; > Sent: Monday, April 08, 2002 11:08 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James: > > > > My main problem with the theme in this discussion is that > > CT is a context transfer protocol, not a session management protocol. > > In particular, when there are feature context specific issues, it is > > best to handle session re-establishment/re-negotiation/maintenance > using > > the protocol(s) that were designed to set up the services in the first > > place. CT should not be stretched into being a general signalling > protocol. > > > > In addition, there is the perhaps greater argument that the most > > effective method of correcting handover issues is not through over > > the air signalling exchanges. Given the nature of the wireless link, > > it will almost always be faster and always be more cost effective, to > > correct any problems with signalling within the infrastructure (if it > is > > needed). > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 11:42 > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Madjid, > > > > > > The issue isn't reliability, it is whether the target AR can > interpret > > > the context intelligably. If not, the MN may need to recover > > > by actually > > > re-initializing whatever feature the context was being transfered > for. > > > But it cannot do this unless it knows that the CT has failed. > > > > > > For some feature contexts, like header compression, this > > > isn't a problem > > > because it will re-initialize automatically, but for AAA or QoS it > > > clearly will be. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 3:00 PM > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > to close without any results. People could not agree on the > > > > reliability needs of CT. We added a reliability mechanism to our > > > > CT proposal that covered both retransmission and updates. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > To: Rajeev Koodli > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Agree. > > > > > > > > But I don't see anything in the CT requirements about handling CT > > > > failure. > > > > > > > > ??? > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "James Kempf" > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > Rajeev, > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > notify > > > the > > > > MN > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > robustness of CT protocol. > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Rajeev Koodli" > > > > > > To: "James Kempf" > > > > > > Cc: "Gary Kenward" ; > > > > > > ; ; > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > after handoff. > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > > negotiation > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > should > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > upstream > > > > > > signaling) > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > > though it > > > > > > may > > > > > > > > be useful for finding a new wireless medium. I also see it > > > > primarily > > > > > > for > > > > > > > > intertechnology handover, or, at best, > > > interprovider handover. > > > > > > > > > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Rajeev Koodli" > > > > > > > > To: "Gary Kenward" > > > > > > > > Cc: ; ; > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > may > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > establishment > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > one of the > > > > > > > > > parameters that might then be fed to a selection > > > algorithm. > > > > Any > > > > > > > > > signaling for actually establishing QoS itself > > > beyond the AR > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > understand CARD > > > > (and > > > > > > > > > > I don't understand it well), it is not a QoS > negotiation > > > > > > > > > > protocol. The main application that you are referring > to > > > > > > primarily > > > > > > > > > > arises out of a perceived need to determine at > > > the MN the > > > > best > > > > > > link > > > > > > > > > > layer to handover over to when inter-technology > > > handovers > > > > are > > > > > > > > > > involved. > > > > > > > > > > It can be applied to intra-technology handovers, but > the > > > > value > > > > > > in > > > > > > > > > > that situation is highly questionable (e.g. > > > since it is a > > > > > > discovery > > > > > > > > > > protocol, the implication is that the purpose is to > > > > determine > > > > > > the > > > > > > > > > > choice of channels available; for intra-technology > > > > handovers, > > > > > > there > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > available). > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > imply NSIS > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > this is not > > > > the > > > > > > > > > > intention > > > > > > > > > > (please correct me if I have this wrong John), in > which > > > case > > > > I > > > > > > think > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS > > > for > > > > an > > > > > > > > > > existing flow after a handover, or is it > > > specifically for > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > boolean: > > > the > > > > > > role > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > believe, > > > and > > > > > > clearly > > > > > > > > > > handover is a dynamic situation that could cause the > QoS > > > > > > provided to > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > frightening > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > transfer has > > > > been > > > > > > used > > > > > > > > > > to > > > > > > > > > > move the QoS context to the new routers (by the > > > > > > requirements > > > > > > > > > > for > > > > > > > > > > CT this could be intra-, or inter- > > > technology. Some > > > > of us > > > > > > > > > > believe > > > > > > > > > > that for "seamless" handovers, the > > > context will be > > > > > > available > > > > > > > > at > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > forwarded. > > > > > > This > > > > > > > > > > implies > > > > > > > > > > that there is a relationship, probabilistic > > > perhaps, > > > > > > between > > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > handover > > > > decision > > > > > > (it > > > > > > > > > > is not clear to me how this happens, but it > seems > > > > clear > > > > > > that > > > > > > > > > > for a more "seamless" handover, the MN > > > should chose > > > > an AR > > > > > > > > that > > > > > > > > > > has received the appropriate context; if > > > not, then > > > > what? > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > QoS because > > > > of > > > > > > > > changes > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > predictable > > > > > > > > > > outcomes? > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > entities > > > > > > > > > > associated > > > > > > > > > > with the three protocols interact before, > > > during and after > > > a > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > entities, > > > the > > > > > > > > > > respective > > > > > > > > > > wg's could declare the issue out of scope, but this > > > approach > > > > > > does > > > > > > > > not > > > > > > > > > > sit well with me, for it seems to defer the > > > problem to the > > > > > > people > > > > > > > > who > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to > > > > whether > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > Seamoby (CAR > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > and not NSIS. > > > > CAR > > > > > > > > > > > discovery is supposed to identify candidate access > > > routers > > > > > > > > > > > for handoff and QoS is an important property for > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > be concerned > > > > with > > > > > > the > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > draft. > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > concerned > > > > > > > > > > > with activity > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 9 18:07: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 SAA24470 for ; Tue, 9 Apr 2002 18:07:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23863; Tue, 9 Apr 2002 17:50:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23796 for ; Tue, 9 Apr 2002 17:49:55 -0400 (EDT) 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 RAA24116; Tue, 9 Apr 2002 17:49:50 -0400 (EDT) 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 g39LmLI19600; Tue, 9 Apr 2002 14:48:21 -0700 (PDT) Message-ID: <02c801c1e010$0a7590a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA4A0C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:46:44 -0700 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 Gary, I'd be happy with: o CT is impossible to do with new AR for some reason, perhaps failure of a specific feature context, perhaps new AR is in a different administrative domain, etc. o New AR notifies MN that it must redo network admission to get back up its state, i.e. go back to the initial state before it entered the network. but I would rather have: o CT fails for a specific feature context. o New AR notifies MN that it must redo signaling for that specific feature only. I think 1) is unavoidable for cases such as when an MN goes from one operator's domain to another, and the two have no business agreement allowing CT between them. I think 2) would be nice to have to smooth corner cases, such as new AR runs out of a particular QoS allocation. But I am sensitive that 2) should be handled by the particular feature, i.e. if CT fails to transfer session keys, then the specific AAA feature context code could perform the notification. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Tuesday, April 09, 2002 12:49 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 9, 2002 15:01 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > > Sorry, but I am a bit confused (as usual), are you saying > > > then that doing these functions with the CT protocol is less > > > heavyweight, and thus preferable? > > > > > > > No, I'm saying that "dropping the session" is more > > heavyweight. And what > > Agreed. It would be better to try and fix things first. The real > question is at what level. > > > do you mean by a session anyway? > > IP is connectionless. > > Well...sessions do not require connections. But I have a feeling > we both do not want to open up that can-of-worms debate. > > When I say "session", I mean all the collection of services/resources > that have been set up to support an IP flow, QoS, AAA, HC, etc. > If you have a better word, I'll use it. > > > > > I think what you mean is that all feature contexts for the MN > > revert to > > the startup state, namely gone. > > Ok. Except, that it may be only the feature contexts for a given > microflow. E.g just because a new AR cannot support EF PHB, does > not mean that the BE flows need to be dropped. > > > > > > The default action, always, is for the session to be dropped. > > > This will ultimately force the MN to take action (oh, ok, some > > > MNs will simply halt and catch fire). Anything more then dropping > > > the session is simply to improve the handover performance under > > > various conditions. Typically, when one gets into exception > > scenarios, > > > the solutions become too complex or degrade performance too much > > > to be justified against the potential gains. A classic example is > > > run time type/value checking in C/C++. > > > > > > > My point is, if the MN never finds out about this, then it can't take > > any action. > > My points is that this is not a CT protocol function. There are any > number of failure points for a service feature, and it is the responsibility > of the control entity for that service feature to notify the MN. > > > > > > If there are no recovery mechanisms for the potential faults > > > you describe, then does it make sense to build one into CT? > > > On the other hand, if these mechanisms are built into the handover > > > algorithm, or into the session support, then putting it into CT > > > would be redundant, would it not? > > > > > > > I'm not saying that there should be recovery built into CT. What I am > > saying is > > that the MN has got to know when it has to redo signaling in order to > > reestablish > > stuff like it's AAA state or it's QoS state. > > see comment above. > > But, btw: how does the MN re-establish state without dropping the flow? > E.g. authentication? authorization? does re-establishing EF PHB make > any sense (if you cannot do it within a 100 ms, has the service not > been "dropped" anyway?) > > > > > We went through this exact conversation on the MIP list with > > respect to > > BETH. The > > MN doesn't get involved in handover with BETH, so it needs to be > > informed when > > BETH handover fails (in practice, we tell it when BETH > > handover is about > > to fail). > > Then it can do standard MIP signaling in order to get a care > > of address. > > > > I'm willing to grant that having CT do feature by feature failure > > notification doesn't make sense, > > but I still think there needs to be some way to tell the MN that > > seamlessness has failed > > or is about to fail so it can take the right steps to restart the > > original network admission > > procedure. > > > > I think this is needed if for no other reason than when the MN reaches > > the edge of the operator's > > domain, if the operator doesn't have the right business > > agreements with > > the next operator, the MN > > has got to know to redo network entry, i.e. AAA from scratch, QoS from > > scratch, etc. > > We agree on the first part of these two paragraphs. But, I am confused: > I am not aware of any current facilities within QoS/AAA that allows the MN > to repair AAA/QoS state as opposed to "building it from scratch". Certainly, > protocols can be extended, but then, they can also be extended to allow > for notification. > > Consider: > > o CT fails for a specific context > > o CT somehow sends notification that the context for QoS has failed. > > o MN determines (somehow) what this failure message means (again, > consider that > CT can, at best, notify that a particular data chunk failed somehow at the > new AR, > not why). > > o MN initiates a re-negotiation with the appropriate network entity (AAA > server > perhaps? an QoS Controller perhaps?) > > Versus: > > o CT fails for a specific context > > o service feature entity at new AR determines that it is unable to > support > one or more of the MN flows either because it does not have the > context, > or because it cannot support the context > > o new AR determines, perhaps using local policy decisions, what > mitigating > action can to be taken locally (e.g. downgrade an AF flow to a BE flow > to > support forwarding until new negotiations can take place). > > - OR - > > o new AR determines, perhaps using local policy decisions, that the > control > entity for the feature (e.g. the AAA server), needs to be notified > (e.g. > the service lacks proper authorization), the control entity can then > take > direct action (e.g. perhaps by some inter-system authorization > exchange). > > - OR - > > o new AR determines, perhaps using local policy decisions, that the MN is > should fix the problem, and sends a notification. > > Which scenario appears more flexible, more responsive, and more likely to > support seamless handovers? > > Gary > > > > > jak > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 9 18:07: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 SAA24491 for ; Tue, 9 Apr 2002 18:07:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24833 for seamoby-archive@odin.ietf.org; Tue, 9 Apr 2002 18:07:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23863; Tue, 9 Apr 2002 17:50:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23796 for ; Tue, 9 Apr 2002 17:49:55 -0400 (EDT) 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 RAA24116; Tue, 9 Apr 2002 17:49:50 -0400 (EDT) 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 g39LmLI19600; Tue, 9 Apr 2002 14:48:21 -0700 (PDT) Message-ID: <02c801c1e010$0a7590a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA4A0C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:46:44 -0700 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 Gary, I'd be happy with: o CT is impossible to do with new AR for some reason, perhaps failure of a specific feature context, perhaps new AR is in a different administrative domain, etc. o New AR notifies MN that it must redo network admission to get back up its state, i.e. go back to the initial state before it entered the network. but I would rather have: o CT fails for a specific feature context. o New AR notifies MN that it must redo signaling for that specific feature only. I think 1) is unavoidable for cases such as when an MN goes from one operator's domain to another, and the two have no business agreement allowing CT between them. I think 2) would be nice to have to smooth corner cases, such as new AR runs out of a particular QoS allocation. But I am sensitive that 2) should be handled by the particular feature, i.e. if CT fails to transfer session keys, then the specific AAA feature context code could perform the notification. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Tuesday, April 09, 2002 12:49 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 9, 2002 15:01 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > > Sorry, but I am a bit confused (as usual), are you saying > > > then that doing these functions with the CT protocol is less > > > heavyweight, and thus preferable? > > > > > > > No, I'm saying that "dropping the session" is more > > heavyweight. And what > > Agreed. It would be better to try and fix things first. The real > question is at what level. > > > do you mean by a session anyway? > > IP is connectionless. > > Well...sessions do not require connections. But I have a feeling > we both do not want to open up that can-of-worms debate. > > When I say "session", I mean all the collection of services/resources > that have been set up to support an IP flow, QoS, AAA, HC, etc. > If you have a better word, I'll use it. > > > > > I think what you mean is that all feature contexts for the MN > > revert to > > the startup state, namely gone. > > Ok. Except, that it may be only the feature contexts for a given > microflow. E.g just because a new AR cannot support EF PHB, does > not mean that the BE flows need to be dropped. > > > > > > The default action, always, is for the session to be dropped. > > > This will ultimately force the MN to take action (oh, ok, some > > > MNs will simply halt and catch fire). Anything more then dropping > > > the session is simply to improve the handover performance under > > > various conditions. Typically, when one gets into exception > > scenarios, > > > the solutions become too complex or degrade performance too much > > > to be justified against the potential gains. A classic example is > > > run time type/value checking in C/C++. > > > > > > > My point is, if the MN never finds out about this, then it can't take > > any action. > > My points is that this is not a CT protocol function. There are any > number of failure points for a service feature, and it is the responsibility > of the control entity for that service feature to notify the MN. > > > > > > If there are no recovery mechanisms for the potential faults > > > you describe, then does it make sense to build one into CT? > > > On the other hand, if these mechanisms are built into the handover > > > algorithm, or into the session support, then putting it into CT > > > would be redundant, would it not? > > > > > > > I'm not saying that there should be recovery built into CT. What I am > > saying is > > that the MN has got to know when it has to redo signaling in order to > > reestablish > > stuff like it's AAA state or it's QoS state. > > see comment above. > > But, btw: how does the MN re-establish state without dropping the flow? > E.g. authentication? authorization? does re-establishing EF PHB make > any sense (if you cannot do it within a 100 ms, has the service not > been "dropped" anyway?) > > > > > We went through this exact conversation on the MIP list with > > respect to > > BETH. The > > MN doesn't get involved in handover with BETH, so it needs to be > > informed when > > BETH handover fails (in practice, we tell it when BETH > > handover is about > > to fail). > > Then it can do standard MIP signaling in order to get a care > > of address. > > > > I'm willing to grant that having CT do feature by feature failure > > notification doesn't make sense, > > but I still think there needs to be some way to tell the MN that > > seamlessness has failed > > or is about to fail so it can take the right steps to restart the > > original network admission > > procedure. > > > > I think this is needed if for no other reason than when the MN reaches > > the edge of the operator's > > domain, if the operator doesn't have the right business > > agreements with > > the next operator, the MN > > has got to know to redo network entry, i.e. AAA from scratch, QoS from > > scratch, etc. > > We agree on the first part of these two paragraphs. But, I am confused: > I am not aware of any current facilities within QoS/AAA that allows the MN > to repair AAA/QoS state as opposed to "building it from scratch". Certainly, > protocols can be extended, but then, they can also be extended to allow > for notification. > > Consider: > > o CT fails for a specific context > > o CT somehow sends notification that the context for QoS has failed. > > o MN determines (somehow) what this failure message means (again, > consider that > CT can, at best, notify that a particular data chunk failed somehow at the > new AR, > not why). > > o MN initiates a re-negotiation with the appropriate network entity (AAA > server > perhaps? an QoS Controller perhaps?) > > Versus: > > o CT fails for a specific context > > o service feature entity at new AR determines that it is unable to > support > one or more of the MN flows either because it does not have the > context, > or because it cannot support the context > > o new AR determines, perhaps using local policy decisions, what > mitigating > action can to be taken locally (e.g. downgrade an AF flow to a BE flow > to > support forwarding until new negotiations can take place). > > - OR - > > o new AR determines, perhaps using local policy decisions, that the > control > entity for the feature (e.g. the AAA server), needs to be notified > (e.g. > the service lacks proper authorization), the control entity can then > take > direct action (e.g. perhaps by some inter-system authorization > exchange). > > - OR - > > o new AR determines, perhaps using local policy decisions, that the MN is > should fix the problem, and sends a notification. > > Which scenario appears more flexible, more responsive, and more likely to > support seamless handovers? > > Gary > > > > > jak > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 10 11:47: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 LAA22911 for ; Wed, 10 Apr 2002 11:47:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29559; Wed, 10 Apr 2002 11:37:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29531 for ; Wed, 10 Apr 2002 11:37:29 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22535 for ; Wed, 10 Apr 2002 11:37:23 -0400 (EDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id <2BYXFPFC>; Wed, 10 Apr 2002 11:37:15 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486166DE@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'James Kempf'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Wed, 10 Apr 2002 11:37:11 -0400 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, Is SeaMoby CT getting reduced to duplicating what NASREQ wants to do? What about AAA for MIPv4? I "thought" the whole idea of discovering the candidates, was to help the "mobile" find the best choice. I must admit I have been hard pressed to follow things closely here in SeaMoby for some time now, so if you want to beat me up on previous consensus calls thats OK... The mobile has the best pseudo-instantaneous perspective on a handover choice. For example, a mobile should be able to request a workload metric from its candidate ARs and make a handoff decision partially based on that and other information acquired from its surrounding ARs (I am assuming everything trusts each other for the moment). This brings in the concept of distributed bidding being possible for handoffs. This would likely drag AAA along (kicking and screaming of course). I think SeaMoby CT could provide a nice spectrum management tool if accountants want to auction their spectrum in real time. I saw CT facilitating this sort of context transfer, and of course QoS stuff too. What types of context are other people thinking of using CT for (I am really curious about some CT applications). Also, considering that more hosts will be multi-radio capable I see CT being useful to do a SeamLess radio change, perhaps via a temporary multi-home or tunnel (BETH-like thingy). -pdn > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, April 09, 2002 5:47 PM > To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > I'd be happy with: > > o CT is impossible to do with new AR for some reason, perhaps > failure of a specific feature context, > perhaps new AR is in a different administrative > domain, etc. > > o New AR notifies MN that it must redo network > admission to get > back up its state, i.e. go back to > the initial state before it entered the network. > > but I would rather have: > > o CT fails for a specific feature context. > > o New AR notifies MN that it must redo signaling for that > specific feature only. > > I **************************************************************************** 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 Wed Apr 10 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 LAA22921 for ; Wed, 10 Apr 2002 11:47:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00081 for seamoby-archive@odin.ietf.org; Wed, 10 Apr 2002 11:47:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29559; Wed, 10 Apr 2002 11:37:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29531 for ; Wed, 10 Apr 2002 11:37:29 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22535 for ; Wed, 10 Apr 2002 11:37:23 -0400 (EDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id <2BYXFPFC>; Wed, 10 Apr 2002 11:37:15 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486166DE@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'James Kempf'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Wed, 10 Apr 2002 11:37:11 -0400 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, Is SeaMoby CT getting reduced to duplicating what NASREQ wants to do? What about AAA for MIPv4? I "thought" the whole idea of discovering the candidates, was to help the "mobile" find the best choice. I must admit I have been hard pressed to follow things closely here in SeaMoby for some time now, so if you want to beat me up on previous consensus calls thats OK... The mobile has the best pseudo-instantaneous perspective on a handover choice. For example, a mobile should be able to request a workload metric from its candidate ARs and make a handoff decision partially based on that and other information acquired from its surrounding ARs (I am assuming everything trusts each other for the moment). This brings in the concept of distributed bidding being possible for handoffs. This would likely drag AAA along (kicking and screaming of course). I think SeaMoby CT could provide a nice spectrum management tool if accountants want to auction their spectrum in real time. I saw CT facilitating this sort of context transfer, and of course QoS stuff too. What types of context are other people thinking of using CT for (I am really curious about some CT applications). Also, considering that more hosts will be multi-radio capable I see CT being useful to do a SeamLess radio change, perhaps via a temporary multi-home or tunnel (BETH-like thingy). -pdn > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, April 09, 2002 5:47 PM > To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > I'd be happy with: > > o CT is impossible to do with new AR for some reason, perhaps > failure of a specific feature context, > perhaps new AR is in a different administrative > domain, etc. > > o New AR notifies MN that it must redo network > admission to get > back up its state, i.e. go back to > the initial state before it entered the network. > > but I would rather have: > > o CT fails for a specific feature context. > > o New AR notifies MN that it must redo signaling for that > specific feature only. > > I **************************************************************************** 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 Wed Apr 10 12:18: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 MAA24078 for ; Wed, 10 Apr 2002 12:18:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02746; Wed, 10 Apr 2002 12:05:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02717 for ; Wed, 10 Apr 2002 12:05:54 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23561 for ; Wed, 10 Apr 2002 12:05:49 -0400 (EDT) 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 g3AG5JZ01358; Wed, 10 Apr 2002 12:05:19 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 12:05:19 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A18@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phillip Neumiller'" , "'James Kempf'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Wed, 10 Apr 2002 12:05:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E0A9.8144D512" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E0A9.8144D512 Content-Type: text/plain; charset="iso-8859-1" Phil: All what you say makes sense, to me at least, with one nagging doubt on my part: you say the mobile has the "best pseudo-instantaneous perspective on a handover choice", however, in truth, all the mobile has, in contrast to what the network has, is a view of the availability and, perhaps, quality, of the downlink channels to each AP. Everything else, the network(s) has(have) to provide to the mobile. For me, there are very big issues with the idea of having the network specific information downloaded to an MN for this decision. As you are aware, I "cut my teeth" in wireless data working for companies that produced devices as well as network equipment. I believe that there are some real device issues with having to process this capability information, in addition to the over the air bandwidth consumption of the signalling. There is also the big issue that many network operators and AP/AR providers may not want to disclose what the current state of an AP/AR/wireless link to an MN for competitive reasons. The big issue here that seems to be driving this focus on the MN as the primary in the handover decision seems to be inter-network handover. The MN (IP layer) in this situation appears to be the common denominator in this case. Particularly when it is assumed that the existence/nature of the target AP/AR is not known a priori by the old network. The bottom line is that all of this makes me nervous because I do not believe the solution is as simple as advertising the available bandwidth. And the complexity and overhead builds up once you move beyond this assumption. I've said my piece. Carry on. Gary > -----Original Message----- > From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] > Sent: April 10, 2002 11:37 > To: 'James Kempf' > Cc: 'seamoby@ietf.org' > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James, > > Is SeaMoby CT getting reduced to duplicating what NASREQ wants to do? > What about AAA for MIPv4? I "thought" the whole idea of discovering > the candidates, was to help the "mobile" find the best choice. I must > admit I have been hard pressed to follow things closely here > in SeaMoby > for some time now, so if you want to beat me up on previous consensus > calls thats OK... > > The mobile has the best pseudo-instantaneous perspective on a > handover > choice. For example, a mobile should be able to request a workload > metric from its candidate ARs and make a handoff decision partially > based on that and other information acquired from its surrounding > ARs (I am assuming everything trusts each other for the moment). > > This brings in the concept of distributed bidding being possible for > handoffs. This would likely drag AAA along (kicking and screaming > of course). I think SeaMoby CT could provide a nice spectrum > management > tool if accountants want to auction their spectrum in real > time. I saw > CT facilitating this sort of context transfer, and of course QoS stuff > too. What types of context are other people thinking of using CT for > (I am really curious about some CT applications). > > Also, considering that more hosts will be multi-radio capable I see > CT being useful to do a SeamLess radio change, perhaps via a temporary > multi-home or tunnel (BETH-like thingy). > > -pdn > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, April 09, 2002 5:47 PM > > To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I'd be happy with: > > > > o CT is impossible to do with new AR for some > reason, perhaps > > failure of a specific feature context, > > perhaps new AR is in a different administrative > > domain, etc. > > > > o New AR notifies MN that it must redo network > > admission to get > > back up its state, i.e. go back to > > the initial state before it entered the network. > > > > but I would rather have: > > > > o CT fails for a specific feature context. > > > > o New AR notifies MN that it must redo signaling for that > > specific feature only. > > > > I > ************************************************************** > ************** > 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 > ------_=_NextPart_001_01C1E0A9.8144D512 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:

 All what you say makes sense, to me at least, with one nagging
doubt on my part: you say the mobile has the "best pseudo-instantaneous
perspective on a handover choice", however, in truth, all the mobile
has, in contrast to what the network has, is a view of the availability
and, perhaps, quality, of the downlink channels to each AP. Everything
else, the network(s) has(have) to provide to the mobile. For me, there
are very big issues with the idea of having the network specific information
downloaded to an MN for this decision.

 As you are aware, I "cut my teeth" in wireless data working for companies
that produced devices as well as network equipment. I believe that there
are some real device issues with having to process this capability information,
in addition to the over the air bandwidth consumption of the signalling.
There is also the big issue that many network operators and AP/AR providers
may not want to disclose what the current state of an AP/AR/wireless link
to an MN for competitive reasons.

 The big issue here that seems to be driving this focus on the MN as the
primary in the handover decision seems to be inter-network handover. The
MN (IP layer) in this situation appears to be the common denominator in this
case. Particularly when it is assumed that the existence/nature of the
target AP/AR is not known a priori by the old network.

 The bottom line is that all of this makes me nervous because I do not
believe the solution is as simple as advertising the available bandwidth.
And the complexity and overhead builds up once you move beyond this assumption.

 I've said my piece. Carry on.

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: April 10, 2002 11:37
> To: 'James Kempf'
> Cc: 'seamoby@ietf.org'
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> James,
>
> Is SeaMoby CT getting reduced to duplicating what NASREQ wants to do?
> What about AAA for MIPv4?  I "thought" the whole idea of discovering
> the candidates, was to help the "mobile" find the best choice.  I must
> admit I have been hard pressed to follow things closely here
> in SeaMoby
> for some time now, so if you want to beat me up on previous consensus
> calls thats OK... 
>
> The mobile has the best pseudo-instantaneous perspective on a
> handover
> choice.  For example, a mobile should be able to request a workload
> metric from its candidate ARs and make a handoff decision partially
> based on that and other information acquired from its surrounding
> ARs (I am assuming everything trusts each other for the moment).
>
> This brings in the concept of distributed bidding being possible for
> handoffs.  This would likely drag AAA along (kicking and screaming
> of course).  I think SeaMoby CT could provide a nice spectrum
> management
> tool if accountants want to auction their spectrum  in real
> time.  I saw
> CT facilitating this sort of context transfer, and of course QoS stuff
> too.  What types of context are  other people thinking of using CT for
> (I am really curious about some CT applications).
>
> Also, considering that more hosts will be multi-radio capable I see
> CT being useful to do a SeamLess radio change, perhaps via a temporary
> multi-home or tunnel (BETH-like thingy).
>
> -pdn
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: Tuesday, April 09, 2002 5:47 PM
> > To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1
> > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> >
> > Gary,
> >
> > I'd be happy with:
> >
> >         o CT is impossible to do with new AR for some
> reason, perhaps
> > failure of a specific feature context,
> >             perhaps new AR is in a different administrative
> > domain, etc.
> >
> >         o New AR notifies MN that it must redo network
> > admission to get
> > back up its state, i.e. go back to
> >             the initial state before it entered the network.
> >
> > but I would rather have:
> >
> >         o CT fails for a specific feature context.
> >
> >         o New AR notifies MN that it must redo signaling for that
> > specific feature only.
> >
> > I
> **************************************************************
> **************
> 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
>

------_=_NextPart_001_01C1E0A9.8144D512-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 10 12:18: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 MAA24088 for ; Wed, 10 Apr 2002 12:18:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03372 for seamoby-archive@odin.ietf.org; Wed, 10 Apr 2002 12:18:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02746; Wed, 10 Apr 2002 12:05:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02717 for ; Wed, 10 Apr 2002 12:05:54 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23561 for ; Wed, 10 Apr 2002 12:05:49 -0400 (EDT) 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 g3AG5JZ01358; Wed, 10 Apr 2002 12:05:19 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 12:05:19 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A18@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phillip Neumiller'" , "'James Kempf'" Cc: "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Wed, 10 Apr 2002 12:05:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E0A9.8144D512" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E0A9.8144D512 Content-Type: text/plain; charset="iso-8859-1" Phil: All what you say makes sense, to me at least, with one nagging doubt on my part: you say the mobile has the "best pseudo-instantaneous perspective on a handover choice", however, in truth, all the mobile has, in contrast to what the network has, is a view of the availability and, perhaps, quality, of the downlink channels to each AP. Everything else, the network(s) has(have) to provide to the mobile. For me, there are very big issues with the idea of having the network specific information downloaded to an MN for this decision. As you are aware, I "cut my teeth" in wireless data working for companies that produced devices as well as network equipment. I believe that there are some real device issues with having to process this capability information, in addition to the over the air bandwidth consumption of the signalling. There is also the big issue that many network operators and AP/AR providers may not want to disclose what the current state of an AP/AR/wireless link to an MN for competitive reasons. The big issue here that seems to be driving this focus on the MN as the primary in the handover decision seems to be inter-network handover. The MN (IP layer) in this situation appears to be the common denominator in this case. Particularly when it is assumed that the existence/nature of the target AP/AR is not known a priori by the old network. The bottom line is that all of this makes me nervous because I do not believe the solution is as simple as advertising the available bandwidth. And the complexity and overhead builds up once you move beyond this assumption. I've said my piece. Carry on. Gary > -----Original Message----- > From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com] > Sent: April 10, 2002 11:37 > To: 'James Kempf' > Cc: 'seamoby@ietf.org' > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James, > > Is SeaMoby CT getting reduced to duplicating what NASREQ wants to do? > What about AAA for MIPv4? I "thought" the whole idea of discovering > the candidates, was to help the "mobile" find the best choice. I must > admit I have been hard pressed to follow things closely here > in SeaMoby > for some time now, so if you want to beat me up on previous consensus > calls thats OK... > > The mobile has the best pseudo-instantaneous perspective on a > handover > choice. For example, a mobile should be able to request a workload > metric from its candidate ARs and make a handoff decision partially > based on that and other information acquired from its surrounding > ARs (I am assuming everything trusts each other for the moment). > > This brings in the concept of distributed bidding being possible for > handoffs. This would likely drag AAA along (kicking and screaming > of course). I think SeaMoby CT could provide a nice spectrum > management > tool if accountants want to auction their spectrum in real > time. I saw > CT facilitating this sort of context transfer, and of course QoS stuff > too. What types of context are other people thinking of using CT for > (I am really curious about some CT applications). > > Also, considering that more hosts will be multi-radio capable I see > CT being useful to do a SeamLess radio change, perhaps via a temporary > multi-home or tunnel (BETH-like thingy). > > -pdn > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, April 09, 2002 5:47 PM > > To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I'd be happy with: > > > > o CT is impossible to do with new AR for some > reason, perhaps > > failure of a specific feature context, > > perhaps new AR is in a different administrative > > domain, etc. > > > > o New AR notifies MN that it must redo network > > admission to get > > back up its state, i.e. go back to > > the initial state before it entered the network. > > > > but I would rather have: > > > > o CT fails for a specific feature context. > > > > o New AR notifies MN that it must redo signaling for that > > specific feature only. > > > > I > ************************************************************** > ************** > 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 > ------_=_NextPart_001_01C1E0A9.8144D512 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:

 All what you say makes sense, to me at least, with one nagging
doubt on my part: you say the mobile has the "best pseudo-instantaneous
perspective on a handover choice", however, in truth, all the mobile
has, in contrast to what the network has, is a view of the availability
and, perhaps, quality, of the downlink channels to each AP. Everything
else, the network(s) has(have) to provide to the mobile. For me, there
are very big issues with the idea of having the network specific information
downloaded to an MN for this decision.

 As you are aware, I "cut my teeth" in wireless data working for companies
that produced devices as well as network equipment. I believe that there
are some real device issues with having to process this capability information,
in addition to the over the air bandwidth consumption of the signalling.
There is also the big issue that many network operators and AP/AR providers
may not want to disclose what the current state of an AP/AR/wireless link
to an MN for competitive reasons.

 The big issue here that seems to be driving this focus on the MN as the
primary in the handover decision seems to be inter-network handover. The
MN (IP layer) in this situation appears to be the common denominator in this
case. Particularly when it is assumed that the existence/nature of the
target AP/AR is not known a priori by the old network.

 The bottom line is that all of this makes me nervous because I do not
believe the solution is as simple as advertising the available bandwidth.
And the complexity and overhead builds up once you move beyond this assumption.

 I've said my piece. Carry on.

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: April 10, 2002 11:37
> To: 'James Kempf'
> Cc: 'seamoby@ietf.org'
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> James,
>
> Is SeaMoby CT getting reduced to duplicating what NASREQ wants to do?
> What about AAA for MIPv4?  I "thought" the whole idea of discovering
> the candidates, was to help the "mobile" find the best choice.  I must
> admit I have been hard pressed to follow things closely here
> in SeaMoby
> for some time now, so if you want to beat me up on previous consensus
> calls thats OK... 
>
> The mobile has the best pseudo-instantaneous perspective on a
> handover
> choice.  For example, a mobile should be able to request a workload
> metric from its candidate ARs and make a handoff decision partially
> based on that and other information acquired from its surrounding
> ARs (I am assuming everything trusts each other for the moment).
>
> This brings in the concept of distributed bidding being possible for
> handoffs.  This would likely drag AAA along (kicking and screaming
> of course).  I think SeaMoby CT could provide a nice spectrum
> management
> tool if accountants want to auction their spectrum  in real
> time.  I saw
> CT facilitating this sort of context transfer, and of course QoS stuff
> too.  What types of context are  other people thinking of using CT for
> (I am really curious about some CT applications).
>
> Also, considering that more hosts will be multi-radio capable I see
> CT being useful to do a SeamLess radio change, perhaps via a temporary
> multi-home or tunnel (BETH-like thingy).
>
> -pdn
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > Sent: Tuesday, April 09, 2002 5:47 PM
> > To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1
> > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> >
> > Gary,
> >
> > I'd be happy with:
> >
> >         o CT is impossible to do with new AR for some
> reason, perhaps
> > failure of a specific feature context,
> >             perhaps new AR is in a different administrative
> > domain, etc.
> >
> >         o New AR notifies MN that it must redo network
> > admission to get
> > back up its state, i.e. go back to
> >             the initial state before it entered the network.
> >
> > but I would rather have:
> >
> >         o CT fails for a specific feature context.
> >
> >         o New AR notifies MN that it must redo signaling for that
> > specific feature only.
> >
> > I
> **************************************************************
> **************
> 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
>

------_=_NextPart_001_01C1E0A9.8144D512-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 12 07:30: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 HAA09367 for ; Fri, 12 Apr 2002 07:30:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08600; Fri, 12 Apr 2002 07:12:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08573 for ; Fri, 12 Apr 2002 07:12:45 -0400 (EDT) Received: from tns-fbu-22-211.oslo.telenor.no ([134.47.137.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07595 for ; Fri, 12 Apr 2002 07:12:42 -0400 (EDT) From: Paal.Engelstad@telenor.com Received: from 134.47.162.190 by tns-fbu-22-211.oslo.telenor.no (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 13:13:14 +0200 Received: from tns-fbu-22-214.corp.telenor.no ([134.47.162.92]) by tns-fbu-22-209.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 13:11:48 +0200 Received: from tns-fbu-22-213.corp.telenor.no ([134.47.162.191]) by tns-fbu-22-214.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 13:11:55 +0200 Received: from TNS-FBU-2E-001.corp.telenor.no ([134.47.162.186]) by tns-fbu-22-213.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 13:11:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Date: Fri, 12 Apr 2002 13:11:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: ? Meeting minutes from IETF 53 ? Thread-Index: AcHiEtZIIS3eMHsJT6+YAGOeKadyWA== To: X-OriginalArrivalTime: 12 Apr 2002 11:11:48.0219 (UTC) FILETIME=[D6AF5CB0:01C1E212] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA08574 Subject: [Seamoby] ? Meeting minutes from 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: 8bit Can someone tell me where I can find the IETF 53 meeting minutes? Thanks, Paal _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Fri Apr 12 07:30: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 HAA09380 for ; Fri, 12 Apr 2002 07:30:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09238 for seamoby-archive@odin.ietf.org; Fri, 12 Apr 2002 07:30:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08600; Fri, 12 Apr 2002 07:12:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08573 for ; Fri, 12 Apr 2002 07:12:45 -0400 (EDT) Received: from tns-fbu-22-211.oslo.telenor.no ([134.47.137.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07595 for ; Fri, 12 Apr 2002 07:12:42 -0400 (EDT) From: Paal.Engelstad@telenor.com Received: from 134.47.162.190 by tns-fbu-22-211.oslo.telenor.no (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 13:13:14 +0200 Received: from tns-fbu-22-214.corp.telenor.no ([134.47.162.92]) by tns-fbu-22-209.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 13:11:48 +0200 Received: from tns-fbu-22-213.corp.telenor.no ([134.47.162.191]) by tns-fbu-22-214.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 13:11:55 +0200 Received: from TNS-FBU-2E-001.corp.telenor.no ([134.47.162.186]) by tns-fbu-22-213.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.2966); Fri, 12 Apr 2002 13:11:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Date: Fri, 12 Apr 2002 13:11:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: ? Meeting minutes from IETF 53 ? Thread-Index: AcHiEtZIIS3eMHsJT6+YAGOeKadyWA== To: X-OriginalArrivalTime: 12 Apr 2002 11:11:48.0219 (UTC) FILETIME=[D6AF5CB0:01C1E212] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA08574 Subject: [Seamoby] ? Meeting minutes from 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: 8bit Can someone tell me where I can find the IETF 53 meeting minutes? Thanks, Paal _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 12 12:19: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 MAA13677 for ; Fri, 12 Apr 2002 12:19:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26103; Fri, 12 Apr 2002 12:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26072 for ; Fri, 12 Apr 2002 12:08:55 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11873 for ; Fri, 12 Apr 2002 12:08:47 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA22158 for ; Fri, 12 Apr 2002 08:57:16 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA00648 for ; Fri, 12 Apr 2002 09:08:49 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <2NF03AF2>; Fri, 12 Apr 2002 11:08:48 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465006F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 12 Apr 2002 11:08:48 -0500 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 Cool, a simple Nack might not hurt, Was your proposal based on a different handover proposal than the ones in MIP WG? I remember readin it long time ago and didn't recognize some messages? BR, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Tuesday, April 09, 2002 4:28 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'James Kempf'; Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Nakhjiri Madjid-MNAKHJI1 wrote: > all you have to do is to add a CT-NACK, > please, look at our TEXT proposal. > We even have a CT-NACK for each feature. Right. A simple notification message would suffice. BTW, in our framework we call it CTIN-Ack now (Section 5.2); earlier versions (going back to Pittsburgh IETF) called it SHACK :-) Regards, -Rajeev > > > madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, April 08, 2002 1:32 PM > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). > > In any event, I think there is need for some kind of signaling to > indicate to the MN that context transfer has failed and that the MN > needs to redo signaling to re-establish feature contexts. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > Cc: ; ; > Sent: Monday, April 08, 2002 11:08 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James: > > > > My main problem with the theme in this discussion is that > > CT is a context transfer protocol, not a session management protocol. > > In particular, when there are feature context specific issues, it is > > best to handle session re-establishment/re-negotiation/maintenance > using > > the protocol(s) that were designed to set up the services in the first > > place. CT should not be stretched into being a general signalling > protocol. > > > > In addition, there is the perhaps greater argument that the most > > effective method of correcting handover issues is not through over > > the air signalling exchanges. Given the nature of the wireless link, > > it will almost always be faster and always be more cost effective, to > > correct any problems with signalling within the infrastructure (if it > is > > needed). > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 11:42 > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Madjid, > > > > > > The issue isn't reliability, it is whether the target AR can > interpret > > > the context intelligably. If not, the MN may need to recover > > > by actually > > > re-initializing whatever feature the context was being transfered > for. > > > But it cannot do this unless it knows that the CT has failed. > > > > > > For some feature contexts, like header compression, this > > > isn't a problem > > > because it will re-initialize automatically, but for AAA or QoS it > > > clearly will be. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 3:00 PM > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > to close without any results. People could not agree on the > > > > reliability needs of CT. We added a reliability mechanism to our > > > > CT proposal that covered both retransmission and updates. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > To: Rajeev Koodli > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Agree. > > > > > > > > But I don't see anything in the CT requirements about handling CT > > > > failure. > > > > > > > > ??? > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "James Kempf" > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > Rajeev, > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > notify > > > the > > > > MN > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > robustness of CT protocol. > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Rajeev Koodli" > > > > > > To: "James Kempf" > > > > > > Cc: "Gary Kenward" ; > > > > > > ; ; > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > after handoff. > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > > negotiation > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > should > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > upstream > > > > > > signaling) > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > > though it > > > > > > may > > > > > > > > be useful for finding a new wireless medium. I also see it > > > > primarily > > > > > > for > > > > > > > > intertechnology handover, or, at best, > > > interprovider handover. > > > > > > > > > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Rajeev Koodli" > > > > > > > > To: "Gary Kenward" > > > > > > > > Cc: ; ; > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > may > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > establishment > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > one of the > > > > > > > > > parameters that might then be fed to a selection > > > algorithm. > > > > Any > > > > > > > > > signaling for actually establishing QoS itself > > > beyond the AR > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > understand CARD > > > > (and > > > > > > > > > > I don't understand it well), it is not a QoS > negotiation > > > > > > > > > > protocol. The main application that you are referring > to > > > > > > primarily > > > > > > > > > > arises out of a perceived need to determine at > > > the MN the > > > > best > > > > > > link > > > > > > > > > > layer to handover over to when inter-technology > > > handovers > > > > are > > > > > > > > > > involved. > > > > > > > > > > It can be applied to intra-technology handovers, but > the > > > > value > > > > > > in > > > > > > > > > > that situation is highly questionable (e.g. > > > since it is a > > > > > > discovery > > > > > > > > > > protocol, the implication is that the purpose is to > > > > determine > > > > > > the > > > > > > > > > > choice of channels available; for intra-technology > > > > handovers, > > > > > > there > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > available). > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > imply NSIS > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > this is not > > > > the > > > > > > > > > > intention > > > > > > > > > > (please correct me if I have this wrong John), in > which > > > case > > > > I > > > > > > think > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS > > > for > > > > an > > > > > > > > > > existing flow after a handover, or is it > > > specifically for > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > boolean: > > > the > > > > > > role > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > believe, > > > and > > > > > > clearly > > > > > > > > > > handover is a dynamic situation that could cause the > QoS > > > > > > provided to > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > frightening > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > transfer has > > > > been > > > > > > used > > > > > > > > > > to > > > > > > > > > > move the QoS context to the new routers (by the > > > > > > requirements > > > > > > > > > > for > > > > > > > > > > CT this could be intra-, or inter- > > > technology. Some > > > > of us > > > > > > > > > > believe > > > > > > > > > > that for "seamless" handovers, the > > > context will be > > > > > > available > > > > > > > > at > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > forwarded. > > > > > > This > > > > > > > > > > implies > > > > > > > > > > that there is a relationship, probabilistic > > > perhaps, > > > > > > between > > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > handover > > > > decision > > > > > > (it > > > > > > > > > > is not clear to me how this happens, but it > seems > > > > clear > > > > > > that > > > > > > > > > > for a more "seamless" handover, the MN > > > should chose > > > > an AR > > > > > > > > that > > > > > > > > > > has received the appropriate context; if > > > not, then > > > > what? > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > QoS because > > > > of > > > > > > > > changes > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > predictable > > > > > > > > > > outcomes? > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > entities > > > > > > > > > > associated > > > > > > > > > > with the three protocols interact before, > > > during and after > > > a > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > entities, > > > the > > > > > > > > > > respective > > > > > > > > > > wg's could declare the issue out of scope, but this > > > approach > > > > > > does > > > > > > > > not > > > > > > > > > > sit well with me, for it seems to defer the > > > problem to the > > > > > > people > > > > > > > > who > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to > > > > whether > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > Seamoby (CAR > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > and not NSIS. > > > > CAR > > > > > > > > > > > discovery is supposed to identify candidate access > > > routers > > > > > > > > > > > for handoff and QoS is an important property for > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > be concerned > > > > with > > > > > > the > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > draft. > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > concerned > > > > > > > > > > > with activity > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing 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 Fri Apr 12 12:19: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 MAA13687 for ; Fri, 12 Apr 2002 12:19:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26424 for seamoby-archive@odin.ietf.org; Fri, 12 Apr 2002 12:19:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26103; Fri, 12 Apr 2002 12:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26072 for ; Fri, 12 Apr 2002 12:08:55 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11873 for ; Fri, 12 Apr 2002 12:08:47 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA22158 for ; Fri, 12 Apr 2002 08:57:16 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA00648 for ; Fri, 12 Apr 2002 09:08:49 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <2NF03AF2>; Fri, 12 Apr 2002 11:08:48 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465006F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" Cc: seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 12 Apr 2002 11:08:48 -0500 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 Cool, a simple Nack might not hurt, Was your proposal based on a different handover proposal than the ones in MIP WG? I remember readin it long time ago and didn't recognize some messages? BR, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Tuesday, April 09, 2002 4:28 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'James Kempf'; Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Nakhjiri Madjid-MNAKHJI1 wrote: > all you have to do is to add a CT-NACK, > please, look at our TEXT proposal. > We even have a CT-NACK for each feature. Right. A simple notification message would suffice. BTW, in our framework we call it CTIN-Ack now (Section 5.2); earlier versions (going back to Pittsburgh IETF) called it SHACK :-) Regards, -Rajeev > > > madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, April 08, 2002 1:32 PM > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). > > In any event, I think there is need for some kind of signaling to > indicate to the MN that context transfer has failed and that the MN > needs to redo signaling to re-establish feature contexts. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > Cc: ; ; > Sent: Monday, April 08, 2002 11:08 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James: > > > > My main problem with the theme in this discussion is that > > CT is a context transfer protocol, not a session management protocol. > > In particular, when there are feature context specific issues, it is > > best to handle session re-establishment/re-negotiation/maintenance > using > > the protocol(s) that were designed to set up the services in the first > > place. CT should not be stretched into being a general signalling > protocol. > > > > In addition, there is the perhaps greater argument that the most > > effective method of correcting handover issues is not through over > > the air signalling exchanges. Given the nature of the wireless link, > > it will almost always be faster and always be more cost effective, to > > correct any problems with signalling within the infrastructure (if it > is > > needed). > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 11:42 > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Madjid, > > > > > > The issue isn't reliability, it is whether the target AR can > interpret > > > the context intelligably. If not, the MN may need to recover > > > by actually > > > re-initializing whatever feature the context was being transfered > for. > > > But it cannot do this unless it knows that the CT has failed. > > > > > > For some feature contexts, like header compression, this > > > isn't a problem > > > because it will re-initialize automatically, but for AAA or QoS it > > > clearly will be. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 3:00 PM > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > to close without any results. People could not agree on the > > > > reliability needs of CT. We added a reliability mechanism to our > > > > CT proposal that covered both retransmission and updates. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > To: Rajeev Koodli > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Agree. > > > > > > > > But I don't see anything in the CT requirements about handling CT > > > > failure. > > > > > > > > ??? > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "James Kempf" > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > Rajeev, > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > notify > > > the > > > > MN > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > robustness of CT protocol. > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Rajeev Koodli" > > > > > > To: "James Kempf" > > > > > > Cc: "Gary Kenward" ; > > > > > > ; ; > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > after handoff. > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > > negotiation > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > should > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > upstream > > > > > > signaling) > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > > though it > > > > > > may > > > > > > > > be useful for finding a new wireless medium. I also see it > > > > primarily > > > > > > for > > > > > > > > intertechnology handover, or, at best, > > > interprovider handover. > > > > > > > > > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Rajeev Koodli" > > > > > > > > To: "Gary Kenward" > > > > > > > > Cc: ; ; > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > may > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > establishment > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > one of the > > > > > > > > > parameters that might then be fed to a selection > > > algorithm. > > > > Any > > > > > > > > > signaling for actually establishing QoS itself > > > beyond the AR > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > understand CARD > > > > (and > > > > > > > > > > I don't understand it well), it is not a QoS > negotiation > > > > > > > > > > protocol. The main application that you are referring > to > > > > > > primarily > > > > > > > > > > arises out of a perceived need to determine at > > > the MN the > > > > best > > > > > > link > > > > > > > > > > layer to handover over to when inter-technology > > > handovers > > > > are > > > > > > > > > > involved. > > > > > > > > > > It can be applied to intra-technology handovers, but > the > > > > value > > > > > > in > > > > > > > > > > that situation is highly questionable (e.g. > > > since it is a > > > > > > discovery > > > > > > > > > > protocol, the implication is that the purpose is to > > > > determine > > > > > > the > > > > > > > > > > choice of channels available; for intra-technology > > > > handovers, > > > > > > there > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > available). > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > imply NSIS > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > this is not > > > > the > > > > > > > > > > intention > > > > > > > > > > (please correct me if I have this wrong John), in > which > > > case > > > > I > > > > > > think > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS > > > for > > > > an > > > > > > > > > > existing flow after a handover, or is it > > > specifically for > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > boolean: > > > the > > > > > > role > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > believe, > > > and > > > > > > clearly > > > > > > > > > > handover is a dynamic situation that could cause the > QoS > > > > > > provided to > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > frightening > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > transfer has > > > > been > > > > > > used > > > > > > > > > > to > > > > > > > > > > move the QoS context to the new routers (by the > > > > > > requirements > > > > > > > > > > for > > > > > > > > > > CT this could be intra-, or inter- > > > technology. Some > > > > of us > > > > > > > > > > believe > > > > > > > > > > that for "seamless" handovers, the > > > context will be > > > > > > available > > > > > > > > at > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > forwarded. > > > > > > This > > > > > > > > > > implies > > > > > > > > > > that there is a relationship, probabilistic > > > perhaps, > > > > > > between > > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > handover > > > > decision > > > > > > (it > > > > > > > > > > is not clear to me how this happens, but it > seems > > > > clear > > > > > > that > > > > > > > > > > for a more "seamless" handover, the MN > > > should chose > > > > an AR > > > > > > > > that > > > > > > > > > > has received the appropriate context; if > > > not, then > > > > what? > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > QoS because > > > > of > > > > > > > > changes > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > predictable > > > > > > > > > > outcomes? > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > entities > > > > > > > > > > associated > > > > > > > > > > with the three protocols interact before, > > > during and after > > > a > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > entities, > > > the > > > > > > > > > > respective > > > > > > > > > > wg's could declare the issue out of scope, but this > > > approach > > > > > > does > > > > > > > > not > > > > > > > > > > sit well with me, for it seems to defer the > > > problem to the > > > > > > people > > > > > > > > who > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to > > > > whether > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > Seamoby (CAR > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > and not NSIS. > > > > CAR > > > > > > > > > > > discovery is supposed to identify candidate access > > > routers > > > > > > > > > > > for handoff and QoS is an important property for > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > be concerned > > > > with > > > > > > the > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > draft. > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > concerned > > > > > > > > > > > with activity > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > nsis mailing list > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing 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 Apr 14 04:43: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 EAA15658 for ; Sun, 14 Apr 2002 04:43:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20180; Sun, 14 Apr 2002 04:36:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20149 for ; Sun, 14 Apr 2002 04:36:05 -0400 (EDT) Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15597 for ; Sun, 14 Apr 2002 04:36:01 -0400 (EDT) From: myyun@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Apr 2002 17:35:59 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A696A4B@cms3.etri.re.kr> To: seamoby@ietf.org Date: Sun, 14 Apr 2002 17:35:53 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E38F.638FC700" Subject: [Seamoby] (no subject) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E38F.638FC700 Content-Type: text/plain; charset="euc-kr" subscribe seamoby myyun@etri.re.kr ------_=_NextPart_001_01C1E38F.638FC700 Content-Type: text/html; charset="euc-kr"

subscribe seamoby myyun@etri.re.kr

------_=_NextPart_001_01C1E38F.638FC700-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Apr 14 04: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 EAA15671 for ; Sun, 14 Apr 2002 04:43:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20336 for seamoby-archive@odin.ietf.org; Sun, 14 Apr 2002 04:43:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20180; Sun, 14 Apr 2002 04:36:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20149 for ; Sun, 14 Apr 2002 04:36:05 -0400 (EDT) Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15597 for ; Sun, 14 Apr 2002 04:36:01 -0400 (EDT) From: myyun@etri.re.kr Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Apr 2002 17:35:59 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A696A4B@cms3.etri.re.kr> To: seamoby@ietf.org Date: Sun, 14 Apr 2002 17:35:53 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E38F.638FC700" Subject: [Seamoby] (no subject) Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E38F.638FC700 Content-Type: text/plain; charset="euc-kr" subscribe seamoby myyun@etri.re.kr ------_=_NextPart_001_01C1E38F.638FC700 Content-Type: text/html; charset="euc-kr"

subscribe seamoby myyun@etri.re.kr

------_=_NextPart_001_01C1E38F.638FC700-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 15 04:13: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 EAA09413 for ; Mon, 15 Apr 2002 04:13:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25367; Mon, 15 Apr 2002 04:10:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25338 for ; Mon, 15 Apr 2002 04:10:20 -0400 (EDT) Received: from DESKTOP (h00207818a19b.ne.client2.attbi.com [24.60.238.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09342 for ; Mon, 15 Apr 2002 04:10:16 -0400 (EDT) Message-Id: <200204150810.EAA09342@ietf.org> From: "Adam Erickson" To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 15 Apr 2002 04:10:45 -0400 Subject: [Seamoby] Resume Writing and Distribution Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Dear Job Seeker,


How can we help you find your DREAM JOB?

Resume Author.com is an established resume writing and distribution firm that specializes in custom-tailored career development. We have a dedicated staff of resume writers and an Opt-In E-mail Distribution Network of over 19,000 recruiters and employers (We can have your professional resume in their hands in a matter of minutes).

We're so confident in the effectiveness of our services that we guarantee job interviews!!!

Learn more about the most effective career marketing services available.

Resume Writing & Editing Services Click Here
Starting at only 79.95

E-mail Resume Distribution Services Click Here
Starting at only 29.95


Best Regards,

Adam Erickson
Client Development,
Resume Author


Would you like to test our quality? We provide a FREE Resume Critique for all interested parties.




CONCERNED ABOUT JUNK MAIL? SO ARE WE.

As a ResumeAuthor.com Sales Representative, I believe you meet the criteria we look for in a resume writing and distribution customer. If, however, you feel that you have received this email in error, I apologize. We will comply with all removal requests. To be removed type "remove" in the subject line and MAIL TO:aerickson@resumeauthor.com this is the only way to be removed. Hitting reply will NOT remove you.

This message is sent in compliance of the new email bill section 301.Per Section 301, Paragraph (a)(2)(C) of S. 1618. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 15 04:13: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 EAA09423 for ; Mon, 15 Apr 2002 04:13:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA25741 for seamoby-archive@odin.ietf.org; Mon, 15 Apr 2002 04:13:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25367; Mon, 15 Apr 2002 04:10:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25338 for ; Mon, 15 Apr 2002 04:10:20 -0400 (EDT) Received: from DESKTOP (h00207818a19b.ne.client2.attbi.com [24.60.238.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09342 for ; Mon, 15 Apr 2002 04:10:16 -0400 (EDT) Message-Id: <200204150810.EAA09342@ietf.org> From: "Adam Erickson" To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 15 Apr 2002 04:10:45 -0400 Subject: [Seamoby] Resume Writing and Distribution Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Dear Job Seeker,


How can we help you find your DREAM JOB?

Resume Author.com is an established resume writing and distribution firm that specializes in custom-tailored career development. We have a dedicated staff of resume writers and an Opt-In E-mail Distribution Network of over 19,000 recruiters and employers (We can have your professional resume in their hands in a matter of minutes).

We're so confident in the effectiveness of our services that we guarantee job interviews!!!

Learn more about the most effective career marketing services available.

Resume Writing & Editing Services Click Here
Starting at only 79.95

E-mail Resume Distribution Services Click Here
Starting at only 29.95


Best Regards,

Adam Erickson
Client Development,
Resume Author


Would you like to test our quality? We provide a FREE Resume Critique for all interested parties.




CONCERNED ABOUT JUNK MAIL? SO ARE WE.

As a ResumeAuthor.com Sales Representative, I believe you meet the criteria we look for in a resume writing and distribution customer. If, however, you feel that you have received this email in error, I apologize. We will comply with all removal requests. To be removed type "remove" in the subject line and MAIL TO:aerickson@resumeauthor.com this is the only way to be removed. Hitting reply will NOT remove you.

This message is sent in compliance of the new email bill section 301.Per Section 301, Paragraph (a)(2)(C) of S. 1618. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 15 12:19: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 MAA22365 for ; Mon, 15 Apr 2002 12:19:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23708; Mon, 15 Apr 2002 12:01:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23661 for ; Mon, 15 Apr 2002 12:01:53 -0400 (EDT) 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 MAA21650 for ; Mon, 15 Apr 2002 12:01:49 -0400 (EDT) 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 g3FG1LI21575 for ; Mon, 15 Apr 2002 09:01:21 -0700 (PDT) Message-ID: <009901c1e496$8fe87c90$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 15 Apr 2002 08:59:45 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0096_01C1E45B.E3836300" 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 Subject: [Seamoby] Minutes for Meeting 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 This is a multi-part message in MIME format. ------=_NextPart_000_0096_01C1E45B.E3836300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0096_01C1E45B.E3836300 Content-Type: text/plain; name="seamoby1.txt" Content-Disposition: attachment; filename="seamoby1.txt" Content-Transfer-Encoding: quoted-printable Seamoby Working Group Thursday, March 21st, 3:30PM - 5:30PM [Editor's note: When I did not know a name, I used someone, or some = guy. When two or more people whose names I did not know were talking, I tried to = be consistent with the tags. I inserted [too fast] where the minute = taker's buffer got full, and subsequently dumped] John L : Wants a hum to ask for consensus that we are happy with the = direction we are going in. (Process), basically. David [IEEE guy]: What direction are we going on, in respect to 802.1f Pat said he would get Bob involved. Jim said he would go to the 802.11 meeting in July to inform them of = what's going on here. [General "Who's going to be on the design team" comments] AD[but not Allison . . ]: If your design team is not the whole WG, = there will be complaints. Jim: I understand. George: Wants information provided to the whole group when standards = bodies or other companies start driving processes that affect us. Allison: If it is going to be an RFC then it will come back here, but = joint ventures usually fail. Chairs: We just don't want to duplicate effort. (As in EAP) Pat: Input was provided to IEEE during the ballot process, but it was = ignored. David: 11f passed ballot, and is going through re-circulation ballot. = Between the two of us (Pat + Bob) and Dave, we will keep up with the = proceedings in 802.11 Heesham wanted a question mark removed. Jim explained what a question = mark was. Allison: [re comments of where things are going] Interest of IESG. = Informational documents. She's going to straighten it out. ******* Marco Liebsch - NEC Heidelberg ******* DMHA design issues & framework discussion (IP Paging) Current Design Issues RFC 3154 requires mobility independence + support for existing = protocols. Proposal 1 Different paging protocol for each mobility protocol Problems: Ignores 4.7 for RFC3154, will have different extensions. Advantages: Takes advantage of mobility specifics for IP paging Proposal 2 Dormant mode location tracking as well as paging trigger packet = detection is part of paging, and independent of the mobility protocol. Problems: Mobile node has to keep track of two bindings of location = information. There are stateful entities in the DMA and TA . . = fail-over becomes complicated. Security between mobile host and TA/DMA Advantages: It's a cellular/VLR like system with active mode location = maintained by the mobility protocol and dormant mode location maintained = by the TA in foreign network. Allows having DMHA separated from = mobility, but has strong requirements on fail-over handling. IP paging = separated from mobility management. Allows flexible deployment of DMA = function. Proposal 3 Partition the protocol into a core mobility protocol independent part = and a separate mobility protocol dependent parts. Problems: Distributed functionality . . . SA is distributed. UNABLE TO UNDERSTAND NAME: Proposal 3 looks simpler, but it really has = higher signaling requirements. He claims to have data to support his = claims. Problems: Mobile may have to leave dormant mode to update SA. What happens if the mobile host has multiple interfaces? Some = which use an IP mobility protocol and others don't? May require the host to wake up from dormant mode when it moves = paging area Additional security association between DMA/TA and PA required. =20 Advantages: Keeps location info and state maintenance in one node Implicit SA between MN and mobility agent could be taken. Easier fail-over handling. ANY COMMENTS? -- none Mode 1: DMA received paging trigger packets (is tunnel end-point) DMA is distributed Heesham: Wanted clarification that DMA could be an alternate CoA. Heesham: Have you considered the security issues of doing that? What = about a return routability test? Speaker: For the registration? Heesham: Will you use the DMA as an alternate CoA? Would it be able to = request another binding? Speaker: We assume that the binding does not exist when it's in dormant = mode. Heesham: I don't think you can take it for granted that this will work. Speaker: I agree with you that we need to take care of this. Problem: Unnatural paging trigger packet processing at DMA having the = HoA as MN identifier within IP-IP encapsulated packets Problem: Is there a risk of getting routing loops in case of not = synchronizing binding caches. Mode 2: DMA in Capturing mode (distributed on routers) Requires a protocol between distributed DMAs and Tracking Agent additional security association between DMAs and TA. More distributed approach, efficient fail-over handling required. Allowing both modes to be deployed would allow high degree of = flexibility. Heesham: [Some question I didn't quite catch] Heesham: If I'm on link A, and I'm dormant and move to link C, how does = it send the packet to me on the link that I'm on? Heesham: So, you're mapping paging areas to links or subnets? Speaker: The mobile node has to send paging area updates to the tracking = agent every time it moves. Heesham: So, if you have to do a paging update, why don't you just send = a binding update? =20 Chairs: We're not doing only mobile IP. This protocol is designed to = work even if you're not using mobile IP. Heesham: [doesn't seem to understand] Speaker: Let's take it to the list. Question: Support for different IP versions? Implementation consideration: What's to be handled in the kernel, what = can be in user space? Some guy: I don't understand either of these questions. Do you mean = application layer? John: Comment about first question: I think most of us realize that = IPv6 will be deployed in mobile environments fairly soon. And = applications should be able to support both v4 and v6 (since v4 will be = around for a while longer) How to handle individual paging areas and meet RFC 3154 requirements. Jim: I think this is a very interesting issue, and worth looking into. = I=20 think it might be like host routes, and very hard to implement, but it's = definitely worth looking at. Speaker: ack. Misc: In General: Allow stationary hosts go dormant and to use paging? More specific: DMHA filtering vs filtering for DMHA Allow routers to enter dormant mode and to use paging? Signaling over UDP equivalent to "application layer signaling" Additional issues: Appropriate mechanism for fail-over handling w.r.t support of robustness Improvement on support of hosts having no explicit L2 paging Security support - as soon as the framework is agreed on, appropriate = solutions should be studied and specified. Next Steps We can discuss all this on the list. We need to start on = draft-ietf-seamoby-dmha-framework-00.txt Comments? ----------- Pat: We've been talking about paging quite a bit Jim: Proposal: =20 If we focus on one topic, we'll get good technical discussion. Example: = Mipv6 security discussion. Relation to seamoby: 3 technical topics currently, all of which are a = significant amount of work. So: we need to focus on one. We're going to drop DMHA. We encourage a DMHA bof at the next ietf. Pat: We're at a point where we're building 3 protocols, and we need to = free up cycles. George: But it's been so much fun. ------- Steve Deering (mystery guest) - CAR discovery I was asked to look at the two drafts on CAR Discovery, and was asked, = as an old IP bigot to look at them (from an IP level). I'm nervous = about this because I have no background in the problems you're trying to = solve. Part of being an IP guy is to avoid contamination about L2 things. (L2s = come and go . . IP is forever) I don't see how network controlled hand-off can handle the technological = and administrative heterogeneity and scale of the Internet. Heesham: I've been trying to say the same thing for so long. A mobile node may have as CARs many different kinds of routers public cellular routers=20 one or more wireless lan ARs one or more ARs accessible over wired links. one or more ARs accessible over satellite links, infrared links, etc. there's a potential for many access routers to be visible The notion that your CAR will look at the list and make the decision for = the mobile is absurd. (It can't possibly scale) No one AR can make the complex multi-dimensional trade-offs entailed in = deciding when to move and where to move. (price / usability / etc) The only entity in a position to know the existence of all the possible = CARs is the MN itself. (It could collect them all and "tell" the AR but = . . ) The only entity in a position to know how to weigh the various = attributes offered by the CARs is the human using or owning the MN Challenging enough to figure out how to teach the MN how to do = automatic selection. Crazy to think about teaching every AR with which the MN establishes = a transitory relationship. Placing authority in the MN, instead of current AR, seems the obvious = solution, and conforms to (at least some) IP "principles" (eg, "smart = host, dumb network", "end-to-end" the effectiveness of the MN's decisions will depend greatly on the = quality of the information that it can acquire about it's CARs An AR or a group of ARs under common or collaborating operators may = well be able to provide info to let the MN take operator's desires into = account. ("please move to ARx ASAP" the "seamlessness" of the hand-off will depend on the willingness of a = current AR to provide context transfer to an MN requested next AR. Comments: CharlieP: I'm curious: couldn't in some cases the AR's decide where = you're going? Deering: Yes, see the sub bullet. But, it can't do anything other than = ask the mobile . .=20 Charlie: What if the AR kicks the node out, and moves it to another AR. Deering: It could, but the mobile doesn't have to accept it. It AR = can't know what all ARs the mobile has access to. Charlie: Yes it does. John: Generally, nodes do not participate in routing. I can see that = that can be a role in CAR discovery. Deering: I wouldn't generalize this as a mobile node participating in = routing. George: I think you're right to ignore the link layers. But, there = could be a link layer that lets you talk to multiple ARs at a time. Or, = there could be a link layer that only lets you talk to one. You can = possible solve the problem at the IP layer, but you can't ignore the = specifics o f the link layer. Someone: Automatic selection very difficult to do, but it really = depends on what the situation is. David: At least in one homogeneous link layer (802.11) You can't have = another access point tell you what to do. What happened last week in = the 802.11 meetings, they're further going down the path that the mobile = is controlling itself (not the network controlling the mobile) Deering: Are the CAR documents intended to allow mobile to 802.11 = networks? If so, then they don't work. Heesham: Network control vs mobile control - the reason from deviating = from the mode where the mobile sent the packet from the router . . . we = should make this a general policy. ------------------ CAR Discovery Requirements Govind Do you still want to hear these requirements? One small note There was a small change to the issues draft. There is = now a time based classification of Anticipated . . . [too fast] The requirements discussed henceforth in this talk are meant to be = satisfied by ANY CAR DISCOVERY solution. These requirements are not = specific to a particular solution. 1) Mapping AP identifiers to IP addresses of ARs. Once an AP identifier is forwarded as an input to the CAR discovery = protocol, it MUST map the identifier to the IP address of the AR which = the AP is connected to. Deering: So, my cellular router is going to tell me the IP address of = an 802.11 AP that I just found? Heesham: We need to clarify this requirement more. Requirement 3: SUPPORT FOR HANDOFFS FROM PRIVATE AND SITE LOCAL ARs Needs to be separated for ipv4 <-> ipv6, sitelocal ipv6 -> ipv6, public = ipv4=20 private ipv4 and combinations of above Comment: Too many combinations. George: Doesn't this degenerate into the problem of communicating = between all these things. This isn't relevant to CAR in particular. Speaker: The discussion started because of the question that [too fast] comment: What about the different cases where the identification is = necessary? And, the ARs could be on different spaces. It just makes = the text longer. how many people are for the requirement? Against? Deering: The mobile needs to be able to identify it's CARS, but whether = or not the ARs need to identify each other isn't clear. So, what do you = mean?" Guy: Must identify IP address won't work because it could be an IP = address in a private space. Heesham: Mention the entities involved, because right now it is too = confusing. =20 Jim: We've talked enough. Let's take it to the list. Pat: We've been going down one path, and Steve's brought up an = alternative. (Try to get the mobile node to participate). Rough = consensus: yes Jim: We need someone who has time to donate to do this. Guy: We already have the problem description. =20 Michael: In San Diego we had a draft called <> with network initiated = and mobile node initiated transfers. What happened? What religion = overtook this group to make it happen now. Pat: Steve is very inspirational. Some guy will do requirements document. John: I do not think the thing Steve was asking for was to have a = document with the union of all possible ideas in it. Jim: Should we drop the network model? (3 hands) John: I'd like to suggest that there are people interested in both = models. We can have a pseudo draft, not a WG draft, to start some = discussion. Michael: most of the applicability of a document like this is for a = homogeneous case. But, our application is probably not going to be = homogeneous . . I just wanted to be very clear that in a particular case = for homogeneous network transfer is probably the best way. I don't want = to preclude that case. Steve: Same thing. There are times when information from the ARs might = help the mobile node make a better decision. I wasn't advocating = killing this work, but it just needs to fit into a basic model. Jim: there is some considerable amount of evidence that information = from the network helps to optimize mobile IP. What I'm saying is that = there is some indication that network assistance is helpful, but in = inter technology situations it may not be available. --- Requirement 6: SCOPE People were not too sure about interdomain. People now want interdomain = to be a must too. Jist of it: Stay a SHOULD. New Requirement 1: PROVIDING MN's REQUIREMENTS FOR DETERMINATION OF CARS: The car discovery solution must provide a means for the MN to express = it's requirements for the determination of CARs. The MN preference = solution should be logically separate from the CAR information = distribution solution in order to maintain separation of security = requirements. Heesham: Something about QOS. So . . . what kind of list will the = mobile node provide to this router? It sounds alright but the = realization sounds quite difficult. Speaker: A simple case would be: "I want to watch a porno site, do you = allow it?" Guy: It gives ultimate control to the mobile node to decide where it's = going .. .=20 Someone: The issues draft matches the requirements . So, that's why = it's here. Pat: Steve is saying the network provides information and the node = selects. This seems opposite. Someone: It doesn't say that there is a transfer of requirements from = one box to another. =20 George: Heesham was right when he said, you need to state "how far are = you willing to go" Heesham: And, what kind of privacy and confidentially. Guy: The line here is that there is a problem and a harder problem. = This as it stands is well worded. too fast. -- New Security Requirements CAR discovery MUST ensure that the AR claiming to be it's GAAR is a = genuine AR CAR discovery MUST/SHOULD ensure that this genuine AR is it's GAAR. Steve: People keep saying that this is neutral as to who is making the = solution, but that says that the AR has to be genuine. Why does it have = to be an AR? It could be a mobile. -- Security Requirement 2 A solution to CAR discovery MUST provide means for secure capability = exchange between AR and it's GAARs. Someone; It would be better to add MN/AR to not bias the solution (like = Steve Said) -- Security Requirement 3 A solution to CAR discovery MUST provide secure means for the expression = of MN requirements to car [too fast] Security Requirement 4 -- too long. Security on CAR information 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 [too fast] Requirement 5 - FORMAT OF CAPABILITIES The capabilities MUST be described in a standard format which is TBD. George: This needs to be modular. but you will probably end up defining = some minimal capabilities. Then you need a VERY big vendor specific = space :) Guy: Time to define the formats? There is already work being done in = this area. We need to start out with a study about what's already = available in the market. -- Requirement 9 DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL CAR discovery MUST NOT depend on a particular mobility [too fast] Requirement 10 EFFECT OF CHANGES IN NETWORK TOPOLOGY A CAR discovery protocol MUST be adaptive to changes in physical = topology as well as logical topology. George: What does it mean? Heesham: I don't understand it either. If ARs are used to handle hot spots. =20 -- New Requirement 2 - RE_USE OF EXISTING PROTOCOLS FOR CAR DISCOVERY The car discovery solution must re-use existing protocols wherever = possible. Contention free requirements [too fast] Anything else? --------------- Jim: Lots of good discussion here. Want to put all the discussion into = the draft and then look at it again. If you have specific wordings, = then post it to the list. Bye ------=_NextPart_000_0096_01C1E45B.E3836300-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Mon Apr 15 12:19: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 MAA22374 for ; Mon, 15 Apr 2002 12:19:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25128 for seamoby-archive@odin.ietf.org; Mon, 15 Apr 2002 12:19:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23708; Mon, 15 Apr 2002 12:01:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23661 for ; Mon, 15 Apr 2002 12:01:53 -0400 (EDT) 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 MAA21650 for ; Mon, 15 Apr 2002 12:01:49 -0400 (EDT) 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 g3FG1LI21575 for ; Mon, 15 Apr 2002 09:01:21 -0700 (PDT) Message-ID: <009901c1e496$8fe87c90$7e6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 15 Apr 2002 08:59:45 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0096_01C1E45B.E3836300" 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 Subject: [Seamoby] Minutes for Meeting 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 This is a multi-part message in MIME format. ------=_NextPart_000_0096_01C1E45B.E3836300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0096_01C1E45B.E3836300 Content-Type: text/plain; name="seamoby1.txt" Content-Disposition: attachment; filename="seamoby1.txt" Content-Transfer-Encoding: quoted-printable Seamoby Working Group Thursday, March 21st, 3:30PM - 5:30PM [Editor's note: When I did not know a name, I used someone, or some = guy. When two or more people whose names I did not know were talking, I tried to = be consistent with the tags. I inserted [too fast] where the minute = taker's buffer got full, and subsequently dumped] John L : Wants a hum to ask for consensus that we are happy with the = direction we are going in. (Process), basically. David [IEEE guy]: What direction are we going on, in respect to 802.1f Pat said he would get Bob involved. Jim said he would go to the 802.11 meeting in July to inform them of = what's going on here. [General "Who's going to be on the design team" comments] AD[but not Allison . . ]: If your design team is not the whole WG, = there will be complaints. Jim: I understand. George: Wants information provided to the whole group when standards = bodies or other companies start driving processes that affect us. Allison: If it is going to be an RFC then it will come back here, but = joint ventures usually fail. Chairs: We just don't want to duplicate effort. (As in EAP) Pat: Input was provided to IEEE during the ballot process, but it was = ignored. David: 11f passed ballot, and is going through re-circulation ballot. = Between the two of us (Pat + Bob) and Dave, we will keep up with the = proceedings in 802.11 Heesham wanted a question mark removed. Jim explained what a question = mark was. Allison: [re comments of where things are going] Interest of IESG. = Informational documents. She's going to straighten it out. ******* Marco Liebsch - NEC Heidelberg ******* DMHA design issues & framework discussion (IP Paging) Current Design Issues RFC 3154 requires mobility independence + support for existing = protocols. Proposal 1 Different paging protocol for each mobility protocol Problems: Ignores 4.7 for RFC3154, will have different extensions. Advantages: Takes advantage of mobility specifics for IP paging Proposal 2 Dormant mode location tracking as well as paging trigger packet = detection is part of paging, and independent of the mobility protocol. Problems: Mobile node has to keep track of two bindings of location = information. There are stateful entities in the DMA and TA . . = fail-over becomes complicated. Security between mobile host and TA/DMA Advantages: It's a cellular/VLR like system with active mode location = maintained by the mobility protocol and dormant mode location maintained = by the TA in foreign network. Allows having DMHA separated from = mobility, but has strong requirements on fail-over handling. IP paging = separated from mobility management. Allows flexible deployment of DMA = function. Proposal 3 Partition the protocol into a core mobility protocol independent part = and a separate mobility protocol dependent parts. Problems: Distributed functionality . . . SA is distributed. UNABLE TO UNDERSTAND NAME: Proposal 3 looks simpler, but it really has = higher signaling requirements. He claims to have data to support his = claims. Problems: Mobile may have to leave dormant mode to update SA. What happens if the mobile host has multiple interfaces? Some = which use an IP mobility protocol and others don't? May require the host to wake up from dormant mode when it moves = paging area Additional security association between DMA/TA and PA required. =20 Advantages: Keeps location info and state maintenance in one node Implicit SA between MN and mobility agent could be taken. Easier fail-over handling. ANY COMMENTS? -- none Mode 1: DMA received paging trigger packets (is tunnel end-point) DMA is distributed Heesham: Wanted clarification that DMA could be an alternate CoA. Heesham: Have you considered the security issues of doing that? What = about a return routability test? Speaker: For the registration? Heesham: Will you use the DMA as an alternate CoA? Would it be able to = request another binding? Speaker: We assume that the binding does not exist when it's in dormant = mode. Heesham: I don't think you can take it for granted that this will work. Speaker: I agree with you that we need to take care of this. Problem: Unnatural paging trigger packet processing at DMA having the = HoA as MN identifier within IP-IP encapsulated packets Problem: Is there a risk of getting routing loops in case of not = synchronizing binding caches. Mode 2: DMA in Capturing mode (distributed on routers) Requires a protocol between distributed DMAs and Tracking Agent additional security association between DMAs and TA. More distributed approach, efficient fail-over handling required. Allowing both modes to be deployed would allow high degree of = flexibility. Heesham: [Some question I didn't quite catch] Heesham: If I'm on link A, and I'm dormant and move to link C, how does = it send the packet to me on the link that I'm on? Heesham: So, you're mapping paging areas to links or subnets? Speaker: The mobile node has to send paging area updates to the tracking = agent every time it moves. Heesham: So, if you have to do a paging update, why don't you just send = a binding update? =20 Chairs: We're not doing only mobile IP. This protocol is designed to = work even if you're not using mobile IP. Heesham: [doesn't seem to understand] Speaker: Let's take it to the list. Question: Support for different IP versions? Implementation consideration: What's to be handled in the kernel, what = can be in user space? Some guy: I don't understand either of these questions. Do you mean = application layer? John: Comment about first question: I think most of us realize that = IPv6 will be deployed in mobile environments fairly soon. And = applications should be able to support both v4 and v6 (since v4 will be = around for a while longer) How to handle individual paging areas and meet RFC 3154 requirements. Jim: I think this is a very interesting issue, and worth looking into. = I=20 think it might be like host routes, and very hard to implement, but it's = definitely worth looking at. Speaker: ack. Misc: In General: Allow stationary hosts go dormant and to use paging? More specific: DMHA filtering vs filtering for DMHA Allow routers to enter dormant mode and to use paging? Signaling over UDP equivalent to "application layer signaling" Additional issues: Appropriate mechanism for fail-over handling w.r.t support of robustness Improvement on support of hosts having no explicit L2 paging Security support - as soon as the framework is agreed on, appropriate = solutions should be studied and specified. Next Steps We can discuss all this on the list. We need to start on = draft-ietf-seamoby-dmha-framework-00.txt Comments? ----------- Pat: We've been talking about paging quite a bit Jim: Proposal: =20 If we focus on one topic, we'll get good technical discussion. Example: = Mipv6 security discussion. Relation to seamoby: 3 technical topics currently, all of which are a = significant amount of work. So: we need to focus on one. We're going to drop DMHA. We encourage a DMHA bof at the next ietf. Pat: We're at a point where we're building 3 protocols, and we need to = free up cycles. George: But it's been so much fun. ------- Steve Deering (mystery guest) - CAR discovery I was asked to look at the two drafts on CAR Discovery, and was asked, = as an old IP bigot to look at them (from an IP level). I'm nervous = about this because I have no background in the problems you're trying to = solve. Part of being an IP guy is to avoid contamination about L2 things. (L2s = come and go . . IP is forever) I don't see how network controlled hand-off can handle the technological = and administrative heterogeneity and scale of the Internet. Heesham: I've been trying to say the same thing for so long. A mobile node may have as CARs many different kinds of routers public cellular routers=20 one or more wireless lan ARs one or more ARs accessible over wired links. one or more ARs accessible over satellite links, infrared links, etc. there's a potential for many access routers to be visible The notion that your CAR will look at the list and make the decision for = the mobile is absurd. (It can't possibly scale) No one AR can make the complex multi-dimensional trade-offs entailed in = deciding when to move and where to move. (price / usability / etc) The only entity in a position to know the existence of all the possible = CARs is the MN itself. (It could collect them all and "tell" the AR but = . . ) The only entity in a position to know how to weigh the various = attributes offered by the CARs is the human using or owning the MN Challenging enough to figure out how to teach the MN how to do = automatic selection. Crazy to think about teaching every AR with which the MN establishes = a transitory relationship. Placing authority in the MN, instead of current AR, seems the obvious = solution, and conforms to (at least some) IP "principles" (eg, "smart = host, dumb network", "end-to-end" the effectiveness of the MN's decisions will depend greatly on the = quality of the information that it can acquire about it's CARs An AR or a group of ARs under common or collaborating operators may = well be able to provide info to let the MN take operator's desires into = account. ("please move to ARx ASAP" the "seamlessness" of the hand-off will depend on the willingness of a = current AR to provide context transfer to an MN requested next AR. Comments: CharlieP: I'm curious: couldn't in some cases the AR's decide where = you're going? Deering: Yes, see the sub bullet. But, it can't do anything other than = ask the mobile . .=20 Charlie: What if the AR kicks the node out, and moves it to another AR. Deering: It could, but the mobile doesn't have to accept it. It AR = can't know what all ARs the mobile has access to. Charlie: Yes it does. John: Generally, nodes do not participate in routing. I can see that = that can be a role in CAR discovery. Deering: I wouldn't generalize this as a mobile node participating in = routing. George: I think you're right to ignore the link layers. But, there = could be a link layer that lets you talk to multiple ARs at a time. Or, = there could be a link layer that only lets you talk to one. You can = possible solve the problem at the IP layer, but you can't ignore the = specifics o f the link layer. Someone: Automatic selection very difficult to do, but it really = depends on what the situation is. David: At least in one homogeneous link layer (802.11) You can't have = another access point tell you what to do. What happened last week in = the 802.11 meetings, they're further going down the path that the mobile = is controlling itself (not the network controlling the mobile) Deering: Are the CAR documents intended to allow mobile to 802.11 = networks? If so, then they don't work. Heesham: Network control vs mobile control - the reason from deviating = from the mode where the mobile sent the packet from the router . . . we = should make this a general policy. ------------------ CAR Discovery Requirements Govind Do you still want to hear these requirements? One small note There was a small change to the issues draft. There is = now a time based classification of Anticipated . . . [too fast] The requirements discussed henceforth in this talk are meant to be = satisfied by ANY CAR DISCOVERY solution. These requirements are not = specific to a particular solution. 1) Mapping AP identifiers to IP addresses of ARs. Once an AP identifier is forwarded as an input to the CAR discovery = protocol, it MUST map the identifier to the IP address of the AR which = the AP is connected to. Deering: So, my cellular router is going to tell me the IP address of = an 802.11 AP that I just found? Heesham: We need to clarify this requirement more. Requirement 3: SUPPORT FOR HANDOFFS FROM PRIVATE AND SITE LOCAL ARs Needs to be separated for ipv4 <-> ipv6, sitelocal ipv6 -> ipv6, public = ipv4=20 private ipv4 and combinations of above Comment: Too many combinations. George: Doesn't this degenerate into the problem of communicating = between all these things. This isn't relevant to CAR in particular. Speaker: The discussion started because of the question that [too fast] comment: What about the different cases where the identification is = necessary? And, the ARs could be on different spaces. It just makes = the text longer. how many people are for the requirement? Against? Deering: The mobile needs to be able to identify it's CARS, but whether = or not the ARs need to identify each other isn't clear. So, what do you = mean?" Guy: Must identify IP address won't work because it could be an IP = address in a private space. Heesham: Mention the entities involved, because right now it is too = confusing. =20 Jim: We've talked enough. Let's take it to the list. Pat: We've been going down one path, and Steve's brought up an = alternative. (Try to get the mobile node to participate). Rough = consensus: yes Jim: We need someone who has time to donate to do this. Guy: We already have the problem description. =20 Michael: In San Diego we had a draft called <> with network initiated = and mobile node initiated transfers. What happened? What religion = overtook this group to make it happen now. Pat: Steve is very inspirational. Some guy will do requirements document. John: I do not think the thing Steve was asking for was to have a = document with the union of all possible ideas in it. Jim: Should we drop the network model? (3 hands) John: I'd like to suggest that there are people interested in both = models. We can have a pseudo draft, not a WG draft, to start some = discussion. Michael: most of the applicability of a document like this is for a = homogeneous case. But, our application is probably not going to be = homogeneous . . I just wanted to be very clear that in a particular case = for homogeneous network transfer is probably the best way. I don't want = to preclude that case. Steve: Same thing. There are times when information from the ARs might = help the mobile node make a better decision. I wasn't advocating = killing this work, but it just needs to fit into a basic model. Jim: there is some considerable amount of evidence that information = from the network helps to optimize mobile IP. What I'm saying is that = there is some indication that network assistance is helpful, but in = inter technology situations it may not be available. --- Requirement 6: SCOPE People were not too sure about interdomain. People now want interdomain = to be a must too. Jist of it: Stay a SHOULD. New Requirement 1: PROVIDING MN's REQUIREMENTS FOR DETERMINATION OF CARS: The car discovery solution must provide a means for the MN to express = it's requirements for the determination of CARs. The MN preference = solution should be logically separate from the CAR information = distribution solution in order to maintain separation of security = requirements. Heesham: Something about QOS. So . . . what kind of list will the = mobile node provide to this router? It sounds alright but the = realization sounds quite difficult. Speaker: A simple case would be: "I want to watch a porno site, do you = allow it?" Guy: It gives ultimate control to the mobile node to decide where it's = going .. .=20 Someone: The issues draft matches the requirements . So, that's why = it's here. Pat: Steve is saying the network provides information and the node = selects. This seems opposite. Someone: It doesn't say that there is a transfer of requirements from = one box to another. =20 George: Heesham was right when he said, you need to state "how far are = you willing to go" Heesham: And, what kind of privacy and confidentially. Guy: The line here is that there is a problem and a harder problem. = This as it stands is well worded. too fast. -- New Security Requirements CAR discovery MUST ensure that the AR claiming to be it's GAAR is a = genuine AR CAR discovery MUST/SHOULD ensure that this genuine AR is it's GAAR. Steve: People keep saying that this is neutral as to who is making the = solution, but that says that the AR has to be genuine. Why does it have = to be an AR? It could be a mobile. -- Security Requirement 2 A solution to CAR discovery MUST provide means for secure capability = exchange between AR and it's GAARs. Someone; It would be better to add MN/AR to not bias the solution (like = Steve Said) -- Security Requirement 3 A solution to CAR discovery MUST provide secure means for the expression = of MN requirements to car [too fast] Security Requirement 4 -- too long. Security on CAR information 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 [too fast] Requirement 5 - FORMAT OF CAPABILITIES The capabilities MUST be described in a standard format which is TBD. George: This needs to be modular. but you will probably end up defining = some minimal capabilities. Then you need a VERY big vendor specific = space :) Guy: Time to define the formats? There is already work being done in = this area. We need to start out with a study about what's already = available in the market. -- Requirement 9 DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL CAR discovery MUST NOT depend on a particular mobility [too fast] Requirement 10 EFFECT OF CHANGES IN NETWORK TOPOLOGY A CAR discovery protocol MUST be adaptive to changes in physical = topology as well as logical topology. George: What does it mean? Heesham: I don't understand it either. If ARs are used to handle hot spots. =20 -- New Requirement 2 - RE_USE OF EXISTING PROTOCOLS FOR CAR DISCOVERY The car discovery solution must re-use existing protocols wherever = possible. Contention free requirements [too fast] Anything else? --------------- Jim: Lots of good discussion here. Want to put all the discussion into = the draft and then look at it again. If you have specific wordings, = then post it to the list. Bye ------=_NextPart_000_0096_01C1E45B.E3836300-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Apr 15 17: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 RAA06651 for ; Mon, 15 Apr 2002 17:02:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13757; Mon, 15 Apr 2002 16:56:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13726 for ; Mon, 15 Apr 2002 16:56:21 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06507 for ; Mon, 15 Apr 2002 16:56:16 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FKtnX04836 for ; Mon, 15 Apr 2002 15:55:49 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TVC8T>; Mon, 15 Apr 2002 15:55:48 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E032A217A@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Mon, 15 Apr 2002 15:55:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4BF.EAB5BD30" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E4BF.EAB5BD30 Content-Type: text/plain; charset="iso-8859-1" Excuse me for not being at the WG meeting due to a conflict but I do have some comments on the meeting minutes. [The Issue] It seems that the minutes indicate that people have somehow come to a conclusion that there is no need for access routers to divulge that they are geographically adjancent to themselves via the IP infrastructure. The minutes also seem to indicate that the mobile alone should be the only way to pass addresses of CARs to source ARs. [Technical Questions] O.K. If this is true then how will a mobile pass this information to their source AR if the mobile only has one NIC and that NIC is only capable of listening to one media at once? Even if the NIC can handle multiple technologies what if it can't do the multiple technologies simulateneously? [Business Questions] What is the legacy NICs are not capable of double-communication as described above? What if there are two or more NICs but it chews up the batteries of the device when both are in use? What about the cost ramification and therefore market potential of devices with more than one or a multimode NIC? Are these devices just destined to have crapy handoff, low battery life, or just be expensive? Of course your existing routers don't do this sort of thing and gee it might cost some money to develop the new functions - ya - that's because IP wasn't never designed to deal with node mobility - ya - that's what this working group is here for, I thought. [Non-technical commentary - atheism] The end to end thing is always a good thing to think of BUT keep in mind that they only reason you do things to the network if to do something the hosts can't do or its less expensive to deploy. Nobody ever wants to add something to the network if they can avoid it. I just think that this might be one of those cases when you can't avoid it. The IP addresses are not L2 stuff. [Administrative Commentary] If the WG just doesn't want to deal with the administrative hassle of making network based CAR discovery automatic or zero-conf-like similar to dynamic routing, then just say all we want to do is make this configurable at this time or spin it off into another WG that does want to agree on a way to dynamically convey this information. Also as I recall, the early antagonists of dynamic routing also said it wouldn't scale. Gee you could also pawn it off on AAA. Whoaa - hot potata - hot patata. Keep in mind the excuses and needs for dynamic routing are analogous to the excuses and needs for dynamic CAR discovery. i.e. sometimes you need it and want it and sometimes ya don't. Hope this helps, Glenn [Solve it for routers and the hosts are a breeze] p.s. you'll probably bump into the same problem again in the Monet WG where the correct thing to do should be pretty blatent. ------_=_NextPart_001_01C1E4BF.EAB5BD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Minutes for Meeting at IETF 53

Excuse me for not being at the WG meeting due to a = conflict but I do have some comments on the meeting minutes.

[The Issue]
It seems that the minutes indicate that people have = somehow come to a conclusion that there is no need for access routers = to divulge that they are geographically adjancent to themselves via the = IP infrastructure. The minutes also seem to indicate that the mobile = alone should be the only way to pass addresses of CARs to source = ARs.

[Technical Questions]
O.K. If this is true then how will a mobile pass = this information to their source AR if the mobile only has one NIC and = that NIC is only capable of listening to one media at once?

Even if the NIC can handle multiple technologies what = if it can't do the multiple technologies simulateneously?

[Business Questions]
What is the legacy NICs are not capable of = double-communication as described above?

What if there are two or more NICs but it chews up = the batteries of the device when both are in use?

What about the cost ramification and therefore market = potential of devices with more than one or a multimode NIC?

Are these devices just destined to have crapy = handoff, low battery life, or just be expensive?

Of course your existing routers don't do this sort of = thing and gee it might cost some money to develop the new functions - = ya - that's because IP wasn't never designed to deal with node mobility = - ya - that's what this working group is here for, I = thought.

[Non-technical commentary - atheism]
The end to end thing is always a good thing to think = of BUT keep in mind that they only reason you do things to the network = if to do something the hosts can't do or its less expensive to deploy. = Nobody ever wants to add something to the network if they can avoid it. = I just think that this might be one of those cases when you can't avoid = it. The IP addresses are not L2 stuff.

[Administrative Commentary]
If the WG just doesn't want to deal with the = administrative hassle of making network based CAR discovery automatic = or zero-conf-like similar to dynamic routing, then just say all we want = to do is make this configurable at this time or spin it off into = another WG that does want to agree on a way to dynamically convey this = information. Also as I recall, the early antagonists of dynamic routing = also said it wouldn't scale. Gee you could also pawn it off on AAA. = Whoaa - hot potata - hot patata.

Keep in mind the excuses and needs for dynamic = routing are analogous to the excuses and needs for dynamic CAR = discovery. i.e. sometimes you need it and want it and sometimes ya = don't.

Hope this helps,

Glenn

[Solve it for routers and the hosts are a = breeze]
p.s. you'll probably bump into the same problem = again in the Monet WG where the correct thing to do should be pretty = blatent.

------_=_NextPart_001_01C1E4BF.EAB5BD30-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Mon Apr 15 17: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 RAA06660 for ; Mon, 15 Apr 2002 17:02:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14690 for seamoby-archive@odin.ietf.org; Mon, 15 Apr 2002 17:02:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13757; Mon, 15 Apr 2002 16:56:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13726 for ; Mon, 15 Apr 2002 16:56:21 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06507 for ; Mon, 15 Apr 2002 16:56:16 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FKtnX04836 for ; Mon, 15 Apr 2002 15:55:49 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TVC8T>; Mon, 15 Apr 2002 15:55:48 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E032A217A@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Mon, 15 Apr 2002 15:55:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4BF.EAB5BD30" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E4BF.EAB5BD30 Content-Type: text/plain; charset="iso-8859-1" Excuse me for not being at the WG meeting due to a conflict but I do have some comments on the meeting minutes. [The Issue] It seems that the minutes indicate that people have somehow come to a conclusion that there is no need for access routers to divulge that they are geographically adjancent to themselves via the IP infrastructure. The minutes also seem to indicate that the mobile alone should be the only way to pass addresses of CARs to source ARs. [Technical Questions] O.K. If this is true then how will a mobile pass this information to their source AR if the mobile only has one NIC and that NIC is only capable of listening to one media at once? Even if the NIC can handle multiple technologies what if it can't do the multiple technologies simulateneously? [Business Questions] What is the legacy NICs are not capable of double-communication as described above? What if there are two or more NICs but it chews up the batteries of the device when both are in use? What about the cost ramification and therefore market potential of devices with more than one or a multimode NIC? Are these devices just destined to have crapy handoff, low battery life, or just be expensive? Of course your existing routers don't do this sort of thing and gee it might cost some money to develop the new functions - ya - that's because IP wasn't never designed to deal with node mobility - ya - that's what this working group is here for, I thought. [Non-technical commentary - atheism] The end to end thing is always a good thing to think of BUT keep in mind that they only reason you do things to the network if to do something the hosts can't do or its less expensive to deploy. Nobody ever wants to add something to the network if they can avoid it. I just think that this might be one of those cases when you can't avoid it. The IP addresses are not L2 stuff. [Administrative Commentary] If the WG just doesn't want to deal with the administrative hassle of making network based CAR discovery automatic or zero-conf-like similar to dynamic routing, then just say all we want to do is make this configurable at this time or spin it off into another WG that does want to agree on a way to dynamically convey this information. Also as I recall, the early antagonists of dynamic routing also said it wouldn't scale. Gee you could also pawn it off on AAA. Whoaa - hot potata - hot patata. Keep in mind the excuses and needs for dynamic routing are analogous to the excuses and needs for dynamic CAR discovery. i.e. sometimes you need it and want it and sometimes ya don't. Hope this helps, Glenn [Solve it for routers and the hosts are a breeze] p.s. you'll probably bump into the same problem again in the Monet WG where the correct thing to do should be pretty blatent. ------_=_NextPart_001_01C1E4BF.EAB5BD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Minutes for Meeting at IETF 53

Excuse me for not being at the WG meeting due to a = conflict but I do have some comments on the meeting minutes.

[The Issue]
It seems that the minutes indicate that people have = somehow come to a conclusion that there is no need for access routers = to divulge that they are geographically adjancent to themselves via the = IP infrastructure. The minutes also seem to indicate that the mobile = alone should be the only way to pass addresses of CARs to source = ARs.

[Technical Questions]
O.K. If this is true then how will a mobile pass = this information to their source AR if the mobile only has one NIC and = that NIC is only capable of listening to one media at once?

Even if the NIC can handle multiple technologies what = if it can't do the multiple technologies simulateneously?

[Business Questions]
What is the legacy NICs are not capable of = double-communication as described above?

What if there are two or more NICs but it chews up = the batteries of the device when both are in use?

What about the cost ramification and therefore market = potential of devices with more than one or a multimode NIC?

Are these devices just destined to have crapy = handoff, low battery life, or just be expensive?

Of course your existing routers don't do this sort of = thing and gee it might cost some money to develop the new functions - = ya - that's because IP wasn't never designed to deal with node mobility = - ya - that's what this working group is here for, I = thought.

[Non-technical commentary - atheism]
The end to end thing is always a good thing to think = of BUT keep in mind that they only reason you do things to the network = if to do something the hosts can't do or its less expensive to deploy. = Nobody ever wants to add something to the network if they can avoid it. = I just think that this might be one of those cases when you can't avoid = it. The IP addresses are not L2 stuff.

[Administrative Commentary]
If the WG just doesn't want to deal with the = administrative hassle of making network based CAR discovery automatic = or zero-conf-like similar to dynamic routing, then just say all we want = to do is make this configurable at this time or spin it off into = another WG that does want to agree on a way to dynamically convey this = information. Also as I recall, the early antagonists of dynamic routing = also said it wouldn't scale. Gee you could also pawn it off on AAA. = Whoaa - hot potata - hot patata.

Keep in mind the excuses and needs for dynamic = routing are analogous to the excuses and needs for dynamic CAR = discovery. i.e. sometimes you need it and want it and sometimes ya = don't.

Hope this helps,

Glenn

[Solve it for routers and the hosts are a = breeze]
p.s. you'll probably bump into the same problem = again in the Monet WG where the correct thing to do should be pretty = blatent.

------_=_NextPart_001_01C1E4BF.EAB5BD30-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 16 11:07: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 LAA07458 for ; Tue, 16 Apr 2002 11:07:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21259; Tue, 16 Apr 2002 10:57:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21232 for ; Tue, 16 Apr 2002 10:57:14 -0400 (EDT) Received: from hotmail.com (f255.law7.hotmail.com [216.33.236.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07190 for ; Tue, 16 Apr 2002 10:57:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 07:56:42 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 16 Apr 2002 14:56:42 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 14:56:42 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2002 14:56:42.0730 (UTC) FILETIME=[EBB154A0:01C1E556] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Glenn: See some comments below: >From: "Glenn Morrow" >To: seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Mon, 15 Apr 2002 15:55:47 -0500 > >Excuse me for not being at the WG meeting due to a conflict but I do have >some comments on the meeting minutes. > >[The Issue] >It seems that the minutes indicate that people have somehow come to a >conclusion that there is no need for access routers to divulge that they >are >geographically adjancent to themselves via the IP infrastructure. The >minutes also seem to indicate that the mobile alone should be the only way >to pass addresses of CARs to source ARs. > >[Technical Questions] >O.K. If this is true then how will a mobile pass this information to their >source AR if the mobile only has one NIC and that NIC is only capable of >listening to one media at once? [HC] I agree that this is a genuine technical problem. What I would really like to understand is whether the above is a relevant case for CAR discovery or we simply neglect it and focus only on two physical interfaces case. I raised this question before, but we have not had much discussion on it. In any case, address translation part of CARD will be required in this case for fast handoff support. > >Even if the NIC can handle multiple technologies what if it can't do the >multiple technologies simulateneously? ----clip----------------------- > >[Non-technical commentary - atheism] >The end to end thing is always a good thing to think of BUT keep in mind >that they only reason you do things to the network if to do something the >hosts can't do or its less expensive to deploy. Nobody ever wants to add >something to the network if they can avoid it. I just think that this might >be one of those cases when you can't avoid it. The IP addresses are not L2 >stuff. [HC] Also, in handoff philosophy in general, access routers do maintain state and transfer it from AR to AR, for example context transfer. If that is OK with end-to-end principle, then it seems that CARD protocol whose operations are confined to ARs (and of course MNs) on the periphery of the network should fit in the principle as well. > >[Administrative Commentary] >If the WG just doesn't want to deal with the administrative hassle of >making >network based CAR discovery automatic or zero-conf-like similar to dynamic >routing, then just say all we want to do is make this configurable at this >time or spin it off into another WG that does want to agree on a way to >dynamically convey this information. Also as I recall, the early >antagonists >of dynamic routing also said it wouldn't scale. Gee you could also pawn it >off on AAA. Whoaa - hot potata - hot patata. > >Keep in mind the excuses and needs for dynamic routing are analogous to the >excuses and needs for dynamic CAR discovery. i.e. sometimes you need it and >want it and sometimes ya don't. > >Hope this helps, > >Glenn > >[Solve it for routers and the hosts are a breeze] >p.s. you'll probably bump into the same problem again in the Monet WG where >the correct thing to do should be pretty blatent. _________________________________________________________________ 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 Apr 16 11:07: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 LAA07471 for ; Tue, 16 Apr 2002 11:07:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22146 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 11:07:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21259; Tue, 16 Apr 2002 10:57:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21232 for ; Tue, 16 Apr 2002 10:57:14 -0400 (EDT) Received: from hotmail.com (f255.law7.hotmail.com [216.33.236.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07190 for ; Tue, 16 Apr 2002 10:57:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 07:56:42 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 16 Apr 2002 14:56:42 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 14:56:42 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2002 14:56:42.0730 (UTC) FILETIME=[EBB154A0:01C1E556] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Glenn: See some comments below: >From: "Glenn Morrow" >To: seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Mon, 15 Apr 2002 15:55:47 -0500 > >Excuse me for not being at the WG meeting due to a conflict but I do have >some comments on the meeting minutes. > >[The Issue] >It seems that the minutes indicate that people have somehow come to a >conclusion that there is no need for access routers to divulge that they >are >geographically adjancent to themselves via the IP infrastructure. The >minutes also seem to indicate that the mobile alone should be the only way >to pass addresses of CARs to source ARs. > >[Technical Questions] >O.K. If this is true then how will a mobile pass this information to their >source AR if the mobile only has one NIC and that NIC is only capable of >listening to one media at once? [HC] I agree that this is a genuine technical problem. What I would really like to understand is whether the above is a relevant case for CAR discovery or we simply neglect it and focus only on two physical interfaces case. I raised this question before, but we have not had much discussion on it. In any case, address translation part of CARD will be required in this case for fast handoff support. > >Even if the NIC can handle multiple technologies what if it can't do the >multiple technologies simulateneously? ----clip----------------------- > >[Non-technical commentary - atheism] >The end to end thing is always a good thing to think of BUT keep in mind >that they only reason you do things to the network if to do something the >hosts can't do or its less expensive to deploy. Nobody ever wants to add >something to the network if they can avoid it. I just think that this might >be one of those cases when you can't avoid it. The IP addresses are not L2 >stuff. [HC] Also, in handoff philosophy in general, access routers do maintain state and transfer it from AR to AR, for example context transfer. If that is OK with end-to-end principle, then it seems that CARD protocol whose operations are confined to ARs (and of course MNs) on the periphery of the network should fit in the principle as well. > >[Administrative Commentary] >If the WG just doesn't want to deal with the administrative hassle of >making >network based CAR discovery automatic or zero-conf-like similar to dynamic >routing, then just say all we want to do is make this configurable at this >time or spin it off into another WG that does want to agree on a way to >dynamically convey this information. Also as I recall, the early >antagonists >of dynamic routing also said it wouldn't scale. Gee you could also pawn it >off on AAA. Whoaa - hot potata - hot patata. > >Keep in mind the excuses and needs for dynamic routing are analogous to the >excuses and needs for dynamic CAR discovery. i.e. sometimes you need it and >want it and sometimes ya don't. > >Hope this helps, > >Glenn > >[Solve it for routers and the hosts are a breeze] >p.s. you'll probably bump into the same problem again in the Monet WG where >the correct thing to do should be pretty blatent. _________________________________________________________________ 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 Apr 16 11:41: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 LAA08565 for ; Tue, 16 Apr 2002 11:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23727; Tue, 16 Apr 2002 11:32:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23654 for ; Tue, 16 Apr 2002 11:32:02 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08333 for ; Tue, 16 Apr 2002 11:31:56 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GFTaB07191; Tue, 16 Apr 2002 10:29:36 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TVXM3>; Tue, 16 Apr 2002 10:29:36 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03310027@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 10:29:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E55B.82D730D0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E55B.82D730D0 Content-Type: text/plain; charset="iso-8859-1" Hemant - you snipped the business rationale for why it is relavant. Keep in mind that no one wants to or can prevent the mobile from doing the selection when it can. The problem is that there is a plethora of existing host NICs that can't for even intra-technology handoff. Also keep in mind that smooth handoff uses a network resource. It is therefore pretty evident that the owners of the facilities may wish to have a say in how those resources are used. If the mobile is capable of seeing things the without the help of the network or rather resource policy of the network, the mobile still has the option to not use the resources. Are you saying the IETF should only deal with smooth handover and CAR discovery for inter-access-technology handoffs? This would mean that every single access technology would have to re-invent smooth handoff and access specific CAR discovery. It would also eliminate the possibility of cost-reduced multimode NICs. If people are concerned about duplication of standardized IEEE technologies then bring these technologies into the IETF if they can be made to work for all access technologies. If you just handle the double NIC case then you have not really solved the whole problem and so vendors will make incompatible proprietary solutions. All you will have succeeded in doing is protecting marketshare of the proprietary solutions. I hope you see the point. To not handle these other "deployed" cases would be seen by me as a protectionist tactic to delay standardization. Thanks, Glenn > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Tuesday, April 16, 2002 9:57 AM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > Hi Glenn: > > See some comments below: > > > >From: "Glenn Morrow" > >To: seamoby@ietf.org > >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Mon, 15 Apr 2002 15:55:47 -0500 > > > >Excuse me for not being at the WG meeting due to a conflict > but I do have > >some comments on the meeting minutes. > > > >[The Issue] > >It seems that the minutes indicate that people have somehow come to a > >conclusion that there is no need for access routers to > divulge that they > >are > >geographically adjancent to themselves via the IP infrastructure. The > >minutes also seem to indicate that the mobile alone should > be the only way > >to pass addresses of CARs to source ARs. > > > >[Technical Questions] > >O.K. If this is true then how will a mobile pass this > information to their > >source AR if the mobile only has one NIC and that NIC is > only capable of > >listening to one media at once? > > [HC] I agree that this is a genuine technical problem. What I > would really > like to understand is whether the above is a relevant case > for CAR discovery > or we simply neglect it and focus only on two physical > interfaces case. I > raised this question before, but we have not had much > discussion on it. In > any case, address translation part of CARD will be required > in this case for > fast handoff support. > > > > >Even if the NIC can handle multiple technologies what if it > can't do the > >multiple technologies simulateneously? > > ----clip----------------------- > > > >[Non-technical commentary - atheism] > >The end to end thing is always a good thing to think of BUT > keep in mind > >that they only reason you do things to the network if to do > something the > >hosts can't do or its less expensive to deploy. Nobody ever > wants to add > >something to the network if they can avoid it. I just think > that this might > >be one of those cases when you can't avoid it. The IP > addresses are not L2 > >stuff. > > [HC] Also, in handoff philosophy in general, access routers > do maintain > state and transfer it from AR to AR, for example context > transfer. If that > is OK with end-to-end principle, then it seems that CARD > protocol whose > operations are confined to ARs (and of course MNs) on the > periphery of the > network should fit in the principle as well. > > > > >[Administrative Commentary] > >If the WG just doesn't want to deal with the administrative > hassle of > >making > >network based CAR discovery automatic or zero-conf-like > similar to dynamic > >routing, then just say all we want to do is make this > configurable at this > >time or spin it off into another WG that does want to agree > on a way to > >dynamically convey this information. Also as I recall, the early > >antagonists > >of dynamic routing also said it wouldn't scale. Gee you > could also pawn it > >off on AAA. Whoaa - hot potata - hot patata. > > > >Keep in mind the excuses and needs for dynamic routing are > analogous to the > >excuses and needs for dynamic CAR discovery. i.e. sometimes > you need it and > >want it and sometimes ya don't. > > > >Hope this helps, > > > >Glenn > > > >[Solve it for routers and the hosts are a breeze] > >p.s. you'll probably bump into the same problem again in the > Monet WG where > >the correct thing to do should be pretty blatent. > > > _________________________________________________________________ > 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 > ------_=_NextPart_001_01C1E55B.82D730D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Minutes for Meeting at IETF 53

Hemant - you snipped the business rationale for why = it is relavant. Keep in mind that no one wants to or can prevent the = mobile from doing the selection when it can. The problem is that there = is a plethora of existing host NICs that can't for even = intra-technology handoff. Also keep in mind that smooth handoff uses a = network resource. It is therefore pretty evident that the owners of the = facilities may wish to have a say in how those resources are used. If = the mobile is capable of seeing things the without the help of the = network or rather resource policy of the network, the mobile still has = the option to not use the resources.

Are you saying the IETF should only deal with smooth = handover and CAR discovery for inter-access-technology handoffs? This = would mean that every single access technology would have to re-invent = smooth handoff and access specific CAR discovery. It would also = eliminate the possibility of cost-reduced multimode NICs.

If people are concerned about duplication of = standardized IEEE technologies then bring these technologies into the = IETF if they can be made to work for all access = technologies.

If you just handle the double NIC case then you have = not really solved the whole problem and so vendors will make = incompatible proprietary solutions. All you will have succeeded in = doing is protecting marketshare of the proprietary solutions. =

I hope you see the point. To not handle these other = "deployed" cases would be seen by me as a protectionist = tactic to delay standardization.

Thanks,

Glenn

> -----Original Message-----
> From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> Sent: Tuesday, April 16, 2002 9:57 AM
> To: seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes for Meeting at = IETF 53
>
>
> Hi Glenn:
>
> See some comments below:
>
>
> >From: "Glenn = Morrow"<gmorrow@nortelnetworks.com>
> >To: seamoby@ietf.org
> >Subject: RE: [Seamoby] Minutes for Meeting = at IETF 53
> >Date: Mon, 15 Apr 2002 15:55:47 = -0500
> >
> >Excuse me for not being at the WG meeting = due to a conflict
> but I do have
> >some comments on the meeting = minutes.
> >
> >[The Issue]
> >It seems that the minutes indicate that = people have somehow come to a
> >conclusion that there is no need for access = routers to
> divulge that they
> >are
> >geographically adjancent to themselves via = the IP infrastructure. The
> >minutes also seem to indicate that the = mobile alone should
> be the only way
> >to pass addresses of CARs to source = ARs.
> >
> >[Technical Questions]
> >O.K. If this is true then how will a mobile = pass this
> information to their
> >source AR if the mobile only has one NIC = and that NIC is
> only capable of
> >listening to one media at once?
>
> [HC] I agree that this is a genuine technical = problem. What I
> would really
> like to understand is whether the above is a = relevant case
> for CAR discovery
> or we simply neglect it and focus only on two = physical
> interfaces case. I
> raised this question before, but we have not = had much
> discussion on it. In
> any case, address translation part of CARD will = be required
> in this case for
> fast handoff support.
>
> >
> >Even if the NIC can handle multiple = technologies what if it
> can't do the
> >multiple technologies = simulateneously?
>
> ----clip-----------------------
> >
> >[Non-technical commentary - atheism]
> >The end to end thing is always a good thing = to think of BUT
> keep in mind
> >that they only reason you do things to the = network if to do
> something the
> >hosts can't do or its less expensive to = deploy. Nobody ever
> wants to add
> >something to the network if they can avoid = it. I just think
> that this might
> >be one of those cases when you can't avoid = it. The IP
> addresses are not L2
> >stuff.
>
> [HC] Also, in handoff philosophy in general, = access routers
> do maintain
> state and transfer it from AR to AR, for = example context
> transfer. If that
> is OK with end-to-end principle, then it seems = that CARD
> protocol whose
> operations are confined to ARs (and of course = MNs) on the
> periphery of the
> network should fit in the principle as = well.
>
> >
> >[Administrative Commentary]
> >If the WG just doesn't want to deal with = the administrative
> hassle of
> >making
> >network based CAR discovery automatic or = zero-conf-like
> similar to dynamic
> >routing, then just say all we want to do is = make this
> configurable at this
> >time or spin it off into another WG that = does want to agree
> on a way to
> >dynamically convey this information. Also = as I recall, the early
> >antagonists
> >of dynamic routing also said it wouldn't = scale. Gee you
> could also pawn it
> >off on AAA. Whoaa - hot potata - hot = patata.
> >
> >Keep in mind the excuses and needs for = dynamic routing are
> analogous to the
> >excuses and needs for dynamic CAR = discovery. i.e. sometimes
> you need it and
> >want it and sometimes ya don't.
> >
> >Hope this helps,
> >
> >Glenn
> >
> >[Solve it for routers and the hosts are a = breeze]
> >p.s. you'll probably bump into the same = problem again in the
> Monet WG where
> >the correct thing to do should be pretty = blatent.
>
>
> = _________________________________________________________________=
> 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
>

------_=_NextPart_001_01C1E55B.82D730D0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 16 11:41: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 LAA08601 for ; Tue, 16 Apr 2002 11:41:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24109 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 11:41:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23727; Tue, 16 Apr 2002 11:32:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23654 for ; Tue, 16 Apr 2002 11:32:02 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08333 for ; Tue, 16 Apr 2002 11:31:56 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GFTaB07191; Tue, 16 Apr 2002 10:29:36 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TVXM3>; Tue, 16 Apr 2002 10:29:36 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03310027@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 10:29:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E55B.82D730D0" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E55B.82D730D0 Content-Type: text/plain; charset="iso-8859-1" Hemant - you snipped the business rationale for why it is relavant. Keep in mind that no one wants to or can prevent the mobile from doing the selection when it can. The problem is that there is a plethora of existing host NICs that can't for even intra-technology handoff. Also keep in mind that smooth handoff uses a network resource. It is therefore pretty evident that the owners of the facilities may wish to have a say in how those resources are used. If the mobile is capable of seeing things the without the help of the network or rather resource policy of the network, the mobile still has the option to not use the resources. Are you saying the IETF should only deal with smooth handover and CAR discovery for inter-access-technology handoffs? This would mean that every single access technology would have to re-invent smooth handoff and access specific CAR discovery. It would also eliminate the possibility of cost-reduced multimode NICs. If people are concerned about duplication of standardized IEEE technologies then bring these technologies into the IETF if they can be made to work for all access technologies. If you just handle the double NIC case then you have not really solved the whole problem and so vendors will make incompatible proprietary solutions. All you will have succeeded in doing is protecting marketshare of the proprietary solutions. I hope you see the point. To not handle these other "deployed" cases would be seen by me as a protectionist tactic to delay standardization. Thanks, Glenn > -----Original Message----- > From: Hemant Chaskar [mailto:hchaskar@hotmail.com] > Sent: Tuesday, April 16, 2002 9:57 AM > To: seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > Hi Glenn: > > See some comments below: > > > >From: "Glenn Morrow" > >To: seamoby@ietf.org > >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Mon, 15 Apr 2002 15:55:47 -0500 > > > >Excuse me for not being at the WG meeting due to a conflict > but I do have > >some comments on the meeting minutes. > > > >[The Issue] > >It seems that the minutes indicate that people have somehow come to a > >conclusion that there is no need for access routers to > divulge that they > >are > >geographically adjancent to themselves via the IP infrastructure. The > >minutes also seem to indicate that the mobile alone should > be the only way > >to pass addresses of CARs to source ARs. > > > >[Technical Questions] > >O.K. If this is true then how will a mobile pass this > information to their > >source AR if the mobile only has one NIC and that NIC is > only capable of > >listening to one media at once? > > [HC] I agree that this is a genuine technical problem. What I > would really > like to understand is whether the above is a relevant case > for CAR discovery > or we simply neglect it and focus only on two physical > interfaces case. I > raised this question before, but we have not had much > discussion on it. In > any case, address translation part of CARD will be required > in this case for > fast handoff support. > > > > >Even if the NIC can handle multiple technologies what if it > can't do the > >multiple technologies simulateneously? > > ----clip----------------------- > > > >[Non-technical commentary - atheism] > >The end to end thing is always a good thing to think of BUT > keep in mind > >that they only reason you do things to the network if to do > something the > >hosts can't do or its less expensive to deploy. Nobody ever > wants to add > >something to the network if they can avoid it. I just think > that this might > >be one of those cases when you can't avoid it. The IP > addresses are not L2 > >stuff. > > [HC] Also, in handoff philosophy in general, access routers > do maintain > state and transfer it from AR to AR, for example context > transfer. If that > is OK with end-to-end principle, then it seems that CARD > protocol whose > operations are confined to ARs (and of course MNs) on the > periphery of the > network should fit in the principle as well. > > > > >[Administrative Commentary] > >If the WG just doesn't want to deal with the administrative > hassle of > >making > >network based CAR discovery automatic or zero-conf-like > similar to dynamic > >routing, then just say all we want to do is make this > configurable at this > >time or spin it off into another WG that does want to agree > on a way to > >dynamically convey this information. Also as I recall, the early > >antagonists > >of dynamic routing also said it wouldn't scale. Gee you > could also pawn it > >off on AAA. Whoaa - hot potata - hot patata. > > > >Keep in mind the excuses and needs for dynamic routing are > analogous to the > >excuses and needs for dynamic CAR discovery. i.e. sometimes > you need it and > >want it and sometimes ya don't. > > > >Hope this helps, > > > >Glenn > > > >[Solve it for routers and the hosts are a breeze] > >p.s. you'll probably bump into the same problem again in the > Monet WG where > >the correct thing to do should be pretty blatent. > > > _________________________________________________________________ > 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 > ------_=_NextPart_001_01C1E55B.82D730D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Minutes for Meeting at IETF 53

Hemant - you snipped the business rationale for why = it is relavant. Keep in mind that no one wants to or can prevent the = mobile from doing the selection when it can. The problem is that there = is a plethora of existing host NICs that can't for even = intra-technology handoff. Also keep in mind that smooth handoff uses a = network resource. It is therefore pretty evident that the owners of the = facilities may wish to have a say in how those resources are used. If = the mobile is capable of seeing things the without the help of the = network or rather resource policy of the network, the mobile still has = the option to not use the resources.

Are you saying the IETF should only deal with smooth = handover and CAR discovery for inter-access-technology handoffs? This = would mean that every single access technology would have to re-invent = smooth handoff and access specific CAR discovery. It would also = eliminate the possibility of cost-reduced multimode NICs.

If people are concerned about duplication of = standardized IEEE technologies then bring these technologies into the = IETF if they can be made to work for all access = technologies.

If you just handle the double NIC case then you have = not really solved the whole problem and so vendors will make = incompatible proprietary solutions. All you will have succeeded in = doing is protecting marketshare of the proprietary solutions. =

I hope you see the point. To not handle these other = "deployed" cases would be seen by me as a protectionist = tactic to delay standardization.

Thanks,

Glenn

> -----Original Message-----
> From: Hemant Chaskar [mailto:hchaskar@hotmail.com]
> Sent: Tuesday, April 16, 2002 9:57 AM
> To: seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes for Meeting at = IETF 53
>
>
> Hi Glenn:
>
> See some comments below:
>
>
> >From: "Glenn = Morrow"<gmorrow@nortelnetworks.com>
> >To: seamoby@ietf.org
> >Subject: RE: [Seamoby] Minutes for Meeting = at IETF 53
> >Date: Mon, 15 Apr 2002 15:55:47 = -0500
> >
> >Excuse me for not being at the WG meeting = due to a conflict
> but I do have
> >some comments on the meeting = minutes.
> >
> >[The Issue]
> >It seems that the minutes indicate that = people have somehow come to a
> >conclusion that there is no need for access = routers to
> divulge that they
> >are
> >geographically adjancent to themselves via = the IP infrastructure. The
> >minutes also seem to indicate that the = mobile alone should
> be the only way
> >to pass addresses of CARs to source = ARs.
> >
> >[Technical Questions]
> >O.K. If this is true then how will a mobile = pass this
> information to their
> >source AR if the mobile only has one NIC = and that NIC is
> only capable of
> >listening to one media at once?
>
> [HC] I agree that this is a genuine technical = problem. What I
> would really
> like to understand is whether the above is a = relevant case
> for CAR discovery
> or we simply neglect it and focus only on two = physical
> interfaces case. I
> raised this question before, but we have not = had much
> discussion on it. In
> any case, address translation part of CARD will = be required
> in this case for
> fast handoff support.
>
> >
> >Even if the NIC can handle multiple = technologies what if it
> can't do the
> >multiple technologies = simulateneously?
>
> ----clip-----------------------
> >
> >[Non-technical commentary - atheism]
> >The end to end thing is always a good thing = to think of BUT
> keep in mind
> >that they only reason you do things to the = network if to do
> something the
> >hosts can't do or its less expensive to = deploy. Nobody ever
> wants to add
> >something to the network if they can avoid = it. I just think
> that this might
> >be one of those cases when you can't avoid = it. The IP
> addresses are not L2
> >stuff.
>
> [HC] Also, in handoff philosophy in general, = access routers
> do maintain
> state and transfer it from AR to AR, for = example context
> transfer. If that
> is OK with end-to-end principle, then it seems = that CARD
> protocol whose
> operations are confined to ARs (and of course = MNs) on the
> periphery of the
> network should fit in the principle as = well.
>
> >
> >[Administrative Commentary]
> >If the WG just doesn't want to deal with = the administrative
> hassle of
> >making
> >network based CAR discovery automatic or = zero-conf-like
> similar to dynamic
> >routing, then just say all we want to do is = make this
> configurable at this
> >time or spin it off into another WG that = does want to agree
> on a way to
> >dynamically convey this information. Also = as I recall, the early
> >antagonists
> >of dynamic routing also said it wouldn't = scale. Gee you
> could also pawn it
> >off on AAA. Whoaa - hot potata - hot = patata.
> >
> >Keep in mind the excuses and needs for = dynamic routing are
> analogous to the
> >excuses and needs for dynamic CAR = discovery. i.e. sometimes
> you need it and
> >want it and sometimes ya don't.
> >
> >Hope this helps,
> >
> >Glenn
> >
> >[Solve it for routers and the hosts are a = breeze]
> >p.s. you'll probably bump into the same = problem again in the
> Monet WG where
> >the correct thing to do should be pretty = blatent.
>
>
> = _________________________________________________________________=
> 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
>

------_=_NextPart_001_01C1E55B.82D730D0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 16 13:36: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 NAA23955 for ; Tue, 16 Apr 2002 13:36:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01060; Tue, 16 Apr 2002 13:28:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01029 for ; Tue, 16 Apr 2002 13:28:55 -0400 (EDT) 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 NAA22893 for ; Tue, 16 Apr 2002 13:28:52 -0400 (EDT) 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 g3GHSMI27814; Tue, 16 Apr 2002 10:28:22 -0700 (PDT) Message-ID: <011001c1e56b$e203b640$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 10:26:45 -0700 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 Issue] > >It seems that the minutes indicate that people have somehow come to a > >conclusion that there is no need for access routers to divulge that they > >are > >geographically adjancent to themselves via the IP infrastructure. The > >minutes also seem to indicate that the mobile alone should be the only way > >to pass addresses of CARs to source ARs. > > > >[Technical Questions] > >O.K. If this is true then how will a mobile pass this information to their > >source AR if the mobile only has one NIC and that NIC is only capable of > >listening to one media at once? > > [HC] I agree that this is a genuine technical problem. What I would really > like to understand is whether the above is a relevant case for CAR discovery > or we simply neglect it and focus only on two physical interfaces case. I > raised this question before, but we have not had much discussion on it. In > any case, address translation part of CARD will be required in this case for > fast handoff support. > In a single interface handoff situation, Layer 2 typically delivers the AP or AR L2 identifier to which the MN will be handed over. This information is required (by the MIP fast handover algorithms) at the MN's AR. So the issue is fairly simple: the AR must be able to do reverse address translation in order that it can contact the other AR. Capabilities aren't involved, except to the extent that the MN can hear multiple L2s and make the decision. But this is exactly the same as for the intertechnology case. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 16 13:36: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 NAA23998 for ; Tue, 16 Apr 2002 13:36:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01842 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 13:36:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01060; Tue, 16 Apr 2002 13:28:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01029 for ; Tue, 16 Apr 2002 13:28:55 -0400 (EDT) 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 NAA22893 for ; Tue, 16 Apr 2002 13:28:52 -0400 (EDT) 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 g3GHSMI27814; Tue, 16 Apr 2002 10:28:22 -0700 (PDT) Message-ID: <011001c1e56b$e203b640$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 10:26:45 -0700 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 Issue] > >It seems that the minutes indicate that people have somehow come to a > >conclusion that there is no need for access routers to divulge that they > >are > >geographically adjancent to themselves via the IP infrastructure. The > >minutes also seem to indicate that the mobile alone should be the only way > >to pass addresses of CARs to source ARs. > > > >[Technical Questions] > >O.K. If this is true then how will a mobile pass this information to their > >source AR if the mobile only has one NIC and that NIC is only capable of > >listening to one media at once? > > [HC] I agree that this is a genuine technical problem. What I would really > like to understand is whether the above is a relevant case for CAR discovery > or we simply neglect it and focus only on two physical interfaces case. I > raised this question before, but we have not had much discussion on it. In > any case, address translation part of CARD will be required in this case for > fast handoff support. > In a single interface handoff situation, Layer 2 typically delivers the AP or AR L2 identifier to which the MN will be handed over. This information is required (by the MIP fast handover algorithms) at the MN's AR. So the issue is fairly simple: the AR must be able to do reverse address translation in order that it can contact the other AR. Capabilities aren't involved, except to the extent that the MN can hear multiple L2s and make the decision. But this is exactly the same as for the intertechnology case. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 16 15:06: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 PAA04958 for ; Tue, 16 Apr 2002 15:05:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07003; Tue, 16 Apr 2002 14:57:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06974 for ; Tue, 16 Apr 2002 14:57:08 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03588 for ; Tue, 16 Apr 2002 14:57:04 -0400 (EDT) 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 g3GIv53G028336 for ; Tue, 16 Apr 2002 20:57:05 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 20:57:04 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTM4ZK>; Tue, 16 Apr 2002 20:57:05 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF082@esealnt117> From: "Karim El-Malki (ERA)" To: "'James Kempf'" , Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 20:55:09 +0200 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 Issue] > > >It seems that the minutes indicate that people have > somehow come to a > > >conclusion that there is no need for access routers to > divulge that > they > > >are > > >geographically adjancent to themselves via the IP > infrastructure. The > > >minutes also seem to indicate that the mobile alone should be the > only way > > >to pass addresses of CARs to source ARs. > > > > > >[Technical Questions] > > >O.K. If this is true then how will a mobile pass this > information to > their > > >source AR if the mobile only has one NIC and that NIC is > only capable > of > > >listening to one media at once? > > > > [HC] I agree that this is a genuine technical problem. What I would > really > > like to understand is whether the above is a relevant case for CAR > discovery > > or we simply neglect it and focus only on two physical interfaces > case. I > > raised this question before, but we have not had much discussion on > it. In > > any case, address translation part of CARD will be required in this > case for > > fast handoff support. > > > > In a single interface handoff situation, Layer 2 typically > delivers the > AP or AR L2 identifier to which the MN will be handed over. This > information is required (by the MIP fast handover algorithms) at the > MN's AR. So the issue is fairly simple: the AR must be able to do > reverse address translation in order that it can contact the > other AR. This is not really applicable to Mobile-Initiated MIP Fast Handoff. In Mobile-initiated we consider the useful case where the MN can recover the CAR IP address/es from the L2 trigger. The MN then sends a Proxy Router Solicitation (RtSolPr) to its curent AR containing one or more CAR IP addresses. This means that the source AR already gets the CAR addresses. So we can do without the AR doing translation or discovering geographical adjacency. The MN can pass these CAR address/es to the source AR for both single and multiple-interface MNs. So I think that the conclusion from the meeting is compatible with MIP Fast Handoffs. /Karim _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 16 15:06: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 PAA04974 for ; Tue, 16 Apr 2002 15:06:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07798 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 15:06:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07003; Tue, 16 Apr 2002 14:57:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06974 for ; Tue, 16 Apr 2002 14:57:08 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03588 for ; Tue, 16 Apr 2002 14:57:04 -0400 (EDT) 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 g3GIv53G028336 for ; Tue, 16 Apr 2002 20:57:05 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 20:57:04 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTM4ZK>; Tue, 16 Apr 2002 20:57:05 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF082@esealnt117> From: "Karim El-Malki (ERA)" To: "'James Kempf'" , Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 20:55:09 +0200 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 Issue] > > >It seems that the minutes indicate that people have > somehow come to a > > >conclusion that there is no need for access routers to > divulge that > they > > >are > > >geographically adjancent to themselves via the IP > infrastructure. The > > >minutes also seem to indicate that the mobile alone should be the > only way > > >to pass addresses of CARs to source ARs. > > > > > >[Technical Questions] > > >O.K. If this is true then how will a mobile pass this > information to > their > > >source AR if the mobile only has one NIC and that NIC is > only capable > of > > >listening to one media at once? > > > > [HC] I agree that this is a genuine technical problem. What I would > really > > like to understand is whether the above is a relevant case for CAR > discovery > > or we simply neglect it and focus only on two physical interfaces > case. I > > raised this question before, but we have not had much discussion on > it. In > > any case, address translation part of CARD will be required in this > case for > > fast handoff support. > > > > In a single interface handoff situation, Layer 2 typically > delivers the > AP or AR L2 identifier to which the MN will be handed over. This > information is required (by the MIP fast handover algorithms) at the > MN's AR. So the issue is fairly simple: the AR must be able to do > reverse address translation in order that it can contact the > other AR. This is not really applicable to Mobile-Initiated MIP Fast Handoff. In Mobile-initiated we consider the useful case where the MN can recover the CAR IP address/es from the L2 trigger. The MN then sends a Proxy Router Solicitation (RtSolPr) to its curent AR containing one or more CAR IP addresses. This means that the source AR already gets the CAR addresses. So we can do without the AR doing translation or discovering geographical adjacency. The MN can pass these CAR address/es to the source AR for both single and multiple-interface MNs. So I think that the conclusion from the meeting is compatible with MIP Fast Handoffs. /Karim _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 16 15:24: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 PAA07302 for ; Tue, 16 Apr 2002 15:24:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08911; Tue, 16 Apr 2002 15:21:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08884 for ; Tue, 16 Apr 2002 15:21:26 -0400 (EDT) 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 PAA06963 for ; Tue, 16 Apr 2002 15:21:22 -0400 (EDT) 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 g3GJKpI03846; Tue, 16 Apr 2002 12:20:51 -0700 (PDT) Message-ID: <025e01c1e57b$98bdacb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Karim El-Malki \(ERA\)" , "Hemant Chaskar" , References: <795A014AF92DD21182AF0008C7A404320DFBF082@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 12:19:14 -0700 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 Karim, But it is applicable to network initiated handoff. And there are two algorithms, one in which the access router sends a PrxyRtAdv to the MN and one in which the MN is switched (for FMIPv4). jak ----- Original Message ----- From: "Karim El-Malki (ERA)" To: "'James Kempf'" ; "Hemant Chaskar" ; Sent: Tuesday, April 16, 2002 11:55 AM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > >[The Issue] > > > >It seems that the minutes indicate that people have > > somehow come to a > > > >conclusion that there is no need for access routers to > > divulge that > > they > > > >are > > > >geographically adjancent to themselves via the IP > > infrastructure. The > > > >minutes also seem to indicate that the mobile alone should be the > > only way > > > >to pass addresses of CARs to source ARs. > > > > > > > >[Technical Questions] > > > >O.K. If this is true then how will a mobile pass this > > information to > > their > > > >source AR if the mobile only has one NIC and that NIC is > > only capable > > of > > > >listening to one media at once? > > > > > > [HC] I agree that this is a genuine technical problem. What I would > > really > > > like to understand is whether the above is a relevant case for CAR > > discovery > > > or we simply neglect it and focus only on two physical interfaces > > case. I > > > raised this question before, but we have not had much discussion on > > it. In > > > any case, address translation part of CARD will be required in this > > case for > > > fast handoff support. > > > > > > > In a single interface handoff situation, Layer 2 typically > > delivers the > > AP or AR L2 identifier to which the MN will be handed over. This > > information is required (by the MIP fast handover algorithms) at the > > MN's AR. So the issue is fairly simple: the AR must be able to do > > reverse address translation in order that it can contact the > > other AR. > > This is not really applicable to Mobile-Initiated MIP Fast Handoff. > In Mobile-initiated we consider the useful case where the MN can recover > the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > Router Solicitation (RtSolPr) to its curent AR containing one or more CAR > IP addresses. This means that the source AR already gets the CAR addresses. > So we can do without the AR doing translation or discovering geographical > adjacency. The MN can pass these CAR address/es to the source AR for both > single and multiple-interface MNs. So I think that the conclusion from the > meeting is compatible with MIP Fast Handoffs. > > /Karim > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 16 15: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 PAA07312 for ; Tue, 16 Apr 2002 15:24:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09014 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 15:24:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08911; Tue, 16 Apr 2002 15:21:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08884 for ; Tue, 16 Apr 2002 15:21:26 -0400 (EDT) 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 PAA06963 for ; Tue, 16 Apr 2002 15:21:22 -0400 (EDT) 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 g3GJKpI03846; Tue, 16 Apr 2002 12:20:51 -0700 (PDT) Message-ID: <025e01c1e57b$98bdacb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Karim El-Malki \(ERA\)" , "Hemant Chaskar" , References: <795A014AF92DD21182AF0008C7A404320DFBF082@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 12:19:14 -0700 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 Karim, But it is applicable to network initiated handoff. And there are two algorithms, one in which the access router sends a PrxyRtAdv to the MN and one in which the MN is switched (for FMIPv4). jak ----- Original Message ----- From: "Karim El-Malki (ERA)" To: "'James Kempf'" ; "Hemant Chaskar" ; Sent: Tuesday, April 16, 2002 11:55 AM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > >[The Issue] > > > >It seems that the minutes indicate that people have > > somehow come to a > > > >conclusion that there is no need for access routers to > > divulge that > > they > > > >are > > > >geographically adjancent to themselves via the IP > > infrastructure. The > > > >minutes also seem to indicate that the mobile alone should be the > > only way > > > >to pass addresses of CARs to source ARs. > > > > > > > >[Technical Questions] > > > >O.K. If this is true then how will a mobile pass this > > information to > > their > > > >source AR if the mobile only has one NIC and that NIC is > > only capable > > of > > > >listening to one media at once? > > > > > > [HC] I agree that this is a genuine technical problem. What I would > > really > > > like to understand is whether the above is a relevant case for CAR > > discovery > > > or we simply neglect it and focus only on two physical interfaces > > case. I > > > raised this question before, but we have not had much discussion on > > it. In > > > any case, address translation part of CARD will be required in this > > case for > > > fast handoff support. > > > > > > > In a single interface handoff situation, Layer 2 typically > > delivers the > > AP or AR L2 identifier to which the MN will be handed over. This > > information is required (by the MIP fast handover algorithms) at the > > MN's AR. So the issue is fairly simple: the AR must be able to do > > reverse address translation in order that it can contact the > > other AR. > > This is not really applicable to Mobile-Initiated MIP Fast Handoff. > In Mobile-initiated we consider the useful case where the MN can recover > the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > Router Solicitation (RtSolPr) to its curent AR containing one or more CAR > IP addresses. This means that the source AR already gets the CAR addresses. > So we can do without the AR doing translation or discovering geographical > adjacency. The MN can pass these CAR address/es to the source AR for both > single and multiple-interface MNs. So I think that the conclusion from the > meeting is compatible with MIP Fast Handoffs. > > /Karim > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 16 17:23: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 RAA21606 for ; Tue, 16 Apr 2002 17:23:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15237; Tue, 16 Apr 2002 17:18:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15206 for ; Tue, 16 Apr 2002 17:18:13 -0400 (EDT) Received: from hotmail.com (f232.law7.hotmail.com [216.33.237.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20984 for ; Tue, 16 Apr 2002 17:18:08 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 14:17:38 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 16 Apr 2002 21:17:38 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 21:17:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2002 21:17:38.0749 (UTC) FILETIME=[22F10ED0:01C1E58C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: What do you mean when you say that hearing multiple L2 is equivalent to inter-technology case? I do not get the point. Why can't the MN listen to different L2 beacons of the same technology? I guess it can, and hence, it still needs to chose one among them for handoff. Then the issue is exactly the same as Glenn raised for single NIC case: How to get capabilities without letting go the old connection? Of course, I am assuming that these L2's have comparable signal strengths. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > >[The Issue] > > >It seems that the minutes indicate that people have somehow come to a > > >conclusion that there is no need for access routers to divulge that >they > > >are > > >geographically adjancent to themselves via the IP infrastructure. The > > >minutes also seem to indicate that the mobile alone should be the >only way > > >to pass addresses of CARs to source ARs. > > > > > >[Technical Questions] > > >O.K. If this is true then how will a mobile pass this information to >their > > >source AR if the mobile only has one NIC and that NIC is only capable >of > > >listening to one media at once? > > > > [HC] I agree that this is a genuine technical problem. What I would >really > > like to understand is whether the above is a relevant case for CAR >discovery > > or we simply neglect it and focus only on two physical interfaces >case. I > > raised this question before, but we have not had much discussion on >it. In > > any case, address translation part of CARD will be required in this >case for > > fast handoff support. > > > >In a single interface handoff situation, Layer 2 typically delivers the >AP or AR L2 identifier to which the MN will be handed over. This >information is required (by the MIP fast handover algorithms) at the >MN's AR. So the issue is fairly simple: the AR must be able to do >reverse address translation in order that it can contact the other AR. >Capabilities aren't involved, except to the extent that the MN can hear >multiple L2s and make the decision. But this is exactly the same as for >the intertechnology case. > > 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 Tue Apr 16 17:23: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 RAA21617 for ; Tue, 16 Apr 2002 17:23:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15364 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 17:23:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15237; Tue, 16 Apr 2002 17:18:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15206 for ; Tue, 16 Apr 2002 17:18:13 -0400 (EDT) Received: from hotmail.com (f232.law7.hotmail.com [216.33.237.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20984 for ; Tue, 16 Apr 2002 17:18:08 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 14:17:38 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 16 Apr 2002 21:17:38 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 21:17:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2002 21:17:38.0749 (UTC) FILETIME=[22F10ED0:01C1E58C] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: What do you mean when you say that hearing multiple L2 is equivalent to inter-technology case? I do not get the point. Why can't the MN listen to different L2 beacons of the same technology? I guess it can, and hence, it still needs to chose one among them for handoff. Then the issue is exactly the same as Glenn raised for single NIC case: How to get capabilities without letting go the old connection? Of course, I am assuming that these L2's have comparable signal strengths. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > >[The Issue] > > >It seems that the minutes indicate that people have somehow come to a > > >conclusion that there is no need for access routers to divulge that >they > > >are > > >geographically adjancent to themselves via the IP infrastructure. The > > >minutes also seem to indicate that the mobile alone should be the >only way > > >to pass addresses of CARs to source ARs. > > > > > >[Technical Questions] > > >O.K. If this is true then how will a mobile pass this information to >their > > >source AR if the mobile only has one NIC and that NIC is only capable >of > > >listening to one media at once? > > > > [HC] I agree that this is a genuine technical problem. What I would >really > > like to understand is whether the above is a relevant case for CAR >discovery > > or we simply neglect it and focus only on two physical interfaces >case. I > > raised this question before, but we have not had much discussion on >it. In > > any case, address translation part of CARD will be required in this >case for > > fast handoff support. > > > >In a single interface handoff situation, Layer 2 typically delivers the >AP or AR L2 identifier to which the MN will be handed over. This >information is required (by the MIP fast handover algorithms) at the >MN's AR. So the issue is fairly simple: the AR must be able to do >reverse address translation in order that it can contact the other AR. >Capabilities aren't involved, except to the extent that the MN can hear >multiple L2s and make the decision. But this is exactly the same as for >the intertechnology case. > > 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 Tue Apr 16 17:39: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 RAA23450 for ; Tue, 16 Apr 2002 17:39:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15544; Tue, 16 Apr 2002 17:25:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15518 for ; Tue, 16 Apr 2002 17:25:44 -0400 (EDT) Received: from hotmail.com (f198.law7.hotmail.com [216.33.237.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21893 for ; Tue, 16 Apr 2002 17:25:40 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 14:25:13 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 16 Apr 2002 21:25:12 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: Karim.El-Malki@era.ericsson.se, kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 21:25:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2002 21:25:13.0009 (UTC) FILETIME=[31B3A210:01C1E58D] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim: See at the end of email: >From: "Karim El-Malki (ERA)" >To: "'James Kempf'" , Hemant Chaskar >, seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Tue, 16 Apr 2002 20:55:09 +0200 > > > > >[The Issue] > > > >It seems that the minutes indicate that people have > > somehow come to a > > > >conclusion that there is no need for access routers to > > divulge that > > they > > > >are > > > >geographically adjancent to themselves via the IP > > infrastructure. The > > > >minutes also seem to indicate that the mobile alone should be the > > only way > > > >to pass addresses of CARs to source ARs. > > > > > > > >[Technical Questions] > > > >O.K. If this is true then how will a mobile pass this > > information to > > their > > > >source AR if the mobile only has one NIC and that NIC is > > only capable > > of > > > >listening to one media at once? > > > > > > [HC] I agree that this is a genuine technical problem. What I would > > really > > > like to understand is whether the above is a relevant case for CAR > > discovery > > > or we simply neglect it and focus only on two physical interfaces > > case. I > > > raised this question before, but we have not had much discussion on > > it. In > > > any case, address translation part of CARD will be required in this > > case for > > > fast handoff support. > > > > > > > In a single interface handoff situation, Layer 2 typically > > delivers the > > AP or AR L2 identifier to which the MN will be handed over. This > > information is required (by the MIP fast handover algorithms) at the > > MN's AR. So the issue is fairly simple: the AR must be able to do > > reverse address translation in order that it can contact the > > other AR. > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. >In Mobile-initiated we consider the useful case where the MN can recover >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy >Router Solicitation (RtSolPr) to its curent AR containing one or more CAR >IP addresses. This means that the source AR already gets the CAR addresses. >So we can do without the AR doing translation or discovering geographical >adjacency. The MN can pass these CAR address/es to the source AR for both >single and multiple-interface MNs. So I think that the conclusion from the >meeting is compatible with MIP Fast Handoffs. > >/Karim [HC] I am wondering, if this useful case is genral enough. In other words, can MN always get IP addresses from AP beacons (or L2 triggers) without having to acquire connectivity with AP. More so, in single NIC case. Also, could you please say what conclusion you are referring to. 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@ns.ietf.org Tue Apr 16 17:39: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 RAA23486 for ; Tue, 16 Apr 2002 17:39:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16293 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 17:39:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15544; Tue, 16 Apr 2002 17:25:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15518 for ; Tue, 16 Apr 2002 17:25:44 -0400 (EDT) Received: from hotmail.com (f198.law7.hotmail.com [216.33.237.198]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21893 for ; Tue, 16 Apr 2002 17:25:40 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 14:25:13 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 16 Apr 2002 21:25:12 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: Karim.El-Malki@era.ericsson.se, kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 21:25:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2002 21:25:13.0009 (UTC) FILETIME=[31B3A210:01C1E58D] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim: See at the end of email: >From: "Karim El-Malki (ERA)" >To: "'James Kempf'" , Hemant Chaskar >, seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Tue, 16 Apr 2002 20:55:09 +0200 > > > > >[The Issue] > > > >It seems that the minutes indicate that people have > > somehow come to a > > > >conclusion that there is no need for access routers to > > divulge that > > they > > > >are > > > >geographically adjancent to themselves via the IP > > infrastructure. The > > > >minutes also seem to indicate that the mobile alone should be the > > only way > > > >to pass addresses of CARs to source ARs. > > > > > > > >[Technical Questions] > > > >O.K. If this is true then how will a mobile pass this > > information to > > their > > > >source AR if the mobile only has one NIC and that NIC is > > only capable > > of > > > >listening to one media at once? > > > > > > [HC] I agree that this is a genuine technical problem. What I would > > really > > > like to understand is whether the above is a relevant case for CAR > > discovery > > > or we simply neglect it and focus only on two physical interfaces > > case. I > > > raised this question before, but we have not had much discussion on > > it. In > > > any case, address translation part of CARD will be required in this > > case for > > > fast handoff support. > > > > > > > In a single interface handoff situation, Layer 2 typically > > delivers the > > AP or AR L2 identifier to which the MN will be handed over. This > > information is required (by the MIP fast handover algorithms) at the > > MN's AR. So the issue is fairly simple: the AR must be able to do > > reverse address translation in order that it can contact the > > other AR. > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. >In Mobile-initiated we consider the useful case where the MN can recover >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy >Router Solicitation (RtSolPr) to its curent AR containing one or more CAR >IP addresses. This means that the source AR already gets the CAR addresses. >So we can do without the AR doing translation or discovering geographical >adjacency. The MN can pass these CAR address/es to the source AR for both >single and multiple-interface MNs. So I think that the conclusion from the >meeting is compatible with MIP Fast Handoffs. > >/Karim [HC] I am wondering, if this useful case is genral enough. In other words, can MN always get IP addresses from AP beacons (or L2 triggers) without having to acquire connectivity with AP. More so, in single NIC case. Also, could you please say what conclusion you are referring to. 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 Apr 16 18:17: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 SAA27587 for ; Tue, 16 Apr 2002 18:17:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17566; Tue, 16 Apr 2002 18:13:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17537 for ; Tue, 16 Apr 2002 18:13:56 -0400 (EDT) Received: from inesc.inesc.pt (inesc.inesc.pt [146.193.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27239 for ; Tue, 16 Apr 2002 18:13:51 -0400 (EDT) Received: from cray.inesc.pt (IDENT:root@cray.inesc.pt [146.193.3.253]) by inesc.inesc.pt (8.9.3/8.9.3) with ESMTP id XAA33625; Tue, 16 Apr 2002 23:13:40 +0100 (WEST) (envelope-from pedro.estrela@inesc.pt) Received: from moicane1 (moicane1.inesc.pt [146.193.0.37]) by cray.inesc.pt (8.11.6/8.11.6) with SMTP id g3GMDHc28634; Tue, 16 Apr 2002 23:13:18 +0100 Message-ID: <001501c1e5d6$dacffb70$2500c192@inesc.pt> From: "Pedro Estrela" To: , Date: Tue, 16 Apr 2002 23:12:29 -0700 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit Subject: [Seamoby] ANNOUNCE: new individual submission - draft-estrela-timip-00.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 Content-Transfer-Encoding: 8bit A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is an Individual Submission regarding a new micro-mobility approach for legacy terminals. Title : Terminal Independent Mobile IP (TIMIP) Author(s) : P. Estrela, A. Grilo, T. Vazão, M. Nunes Filename : draft-estrela-timip-00.txt Pages : 10 Date : March 2002 Abstract: IP mobility protocols usually assume that the mobile nodes have a mobility-aware IP stack, which is still a scenario that can seldom be found nowadays. Most terminals, including laptops and PDAs, still use legacy IP stacks, limiting their use to layer-2 mobility between Access Points (APs) connected to the same Access Router (AR) within a single IP subnet. This document presents Terminal Independent Mobile IP (TIMIP), which supports IP mobility of mobility-unaware mobile nodes with legacy IP stacks, while fully interoperating with Mobile IP to provide macromobility across IP subnets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-estrela-timip-00.txt All comments, reviews and suggestions are welcome; please send them directly to pedro.estrela@inesc.pt , and not to these mailing lists. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 16 18:17: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 SAA27599 for ; Tue, 16 Apr 2002 18:17:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17659 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 18:17:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17566; Tue, 16 Apr 2002 18:13:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17537 for ; Tue, 16 Apr 2002 18:13:56 -0400 (EDT) Received: from inesc.inesc.pt (inesc.inesc.pt [146.193.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27239 for ; Tue, 16 Apr 2002 18:13:51 -0400 (EDT) Received: from cray.inesc.pt (IDENT:root@cray.inesc.pt [146.193.3.253]) by inesc.inesc.pt (8.9.3/8.9.3) with ESMTP id XAA33625; Tue, 16 Apr 2002 23:13:40 +0100 (WEST) (envelope-from pedro.estrela@inesc.pt) Received: from moicane1 (moicane1.inesc.pt [146.193.0.37]) by cray.inesc.pt (8.11.6/8.11.6) with SMTP id g3GMDHc28634; Tue, 16 Apr 2002 23:13:18 +0100 Message-ID: <001501c1e5d6$dacffb70$2500c192@inesc.pt> From: "Pedro Estrela" To: , Date: Tue, 16 Apr 2002 23:12:29 -0700 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit Subject: [Seamoby] ANNOUNCE: new individual submission - draft-estrela-timip-00.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 Content-Transfer-Encoding: 8bit A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is an Individual Submission regarding a new micro-mobility approach for legacy terminals. Title : Terminal Independent Mobile IP (TIMIP) Author(s) : P. Estrela, A. Grilo, T. Vazão, M. Nunes Filename : draft-estrela-timip-00.txt Pages : 10 Date : March 2002 Abstract: IP mobility protocols usually assume that the mobile nodes have a mobility-aware IP stack, which is still a scenario that can seldom be found nowadays. Most terminals, including laptops and PDAs, still use legacy IP stacks, limiting their use to layer-2 mobility between Access Points (APs) connected to the same Access Router (AR) within a single IP subnet. This document presents Terminal Independent Mobile IP (TIMIP), which supports IP mobility of mobility-unaware mobile nodes with legacy IP stacks, while fully interoperating with Mobile IP to provide macromobility across IP subnets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-estrela-timip-00.txt All comments, reviews and suggestions are welcome; please send them directly to pedro.estrela@inesc.pt , and not to these mailing lists. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 16 19:01: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 TAA01571 for ; Tue, 16 Apr 2002 19:01:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18882; Tue, 16 Apr 2002 18:47:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18851 for ; Tue, 16 Apr 2002 18:47:00 -0400 (EDT) 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 SAA00083 for ; Tue, 16 Apr 2002 18:46:56 -0400 (EDT) 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 g3GMkQI13586; Tue, 16 Apr 2002 15:46:27 -0700 (PDT) Message-ID: <032001c1e598$5138ef40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 15:44:48 -0700 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, that's what I'm saying. There is one case where the MN needs to choose, and the other where the MN and AR get an L2 address and don't have a choice. The handover happens because, if not, the power will fade and the MN loses link connectivity. The former case might require capabilities, the latter just requires cross link ARP. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Tuesday, April 16, 2002 2:17 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > What do you mean when you say that hearing multiple L2 is equivalent to > inter-technology case? I do not get the point. Why can't the MN listen to > different L2 beacons of the same technology? I guess it can, and hence, it > still needs to chose one among them for handoff. Then the issue is exactly > the same as Glenn raised for single NIC case: How to get capabilities > without letting go the old connection? Of course, I am assuming that these > L2's have comparable signal strengths. > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > >[The Issue] > > > >It seems that the minutes indicate that people have somehow come to a > > > >conclusion that there is no need for access routers to divulge that > >they > > > >are > > > >geographically adjancent to themselves via the IP infrastructure. The > > > >minutes also seem to indicate that the mobile alone should be the > >only way > > > >to pass addresses of CARs to source ARs. > > > > > > > >[Technical Questions] > > > >O.K. If this is true then how will a mobile pass this information to > >their > > > >source AR if the mobile only has one NIC and that NIC is only capable > >of > > > >listening to one media at once? > > > > > > [HC] I agree that this is a genuine technical problem. What I would > >really > > > like to understand is whether the above is a relevant case for CAR > >discovery > > > or we simply neglect it and focus only on two physical interfaces > >case. I > > > raised this question before, but we have not had much discussion on > >it. In > > > any case, address translation part of CARD will be required in this > >case for > > > fast handoff support. > > > > > > >In a single interface handoff situation, Layer 2 typically delivers the > >AP or AR L2 identifier to which the MN will be handed over. This > >information is required (by the MIP fast handover algorithms) at the > >MN's AR. So the issue is fairly simple: the AR must be able to do > >reverse address translation in order that it can contact the other AR. > >Capabilities aren't involved, except to the extent that the MN can hear > >multiple L2s and make the decision. But this is exactly the same as for > >the intertechnology case. > > > > 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 Tue Apr 16 19: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 TAA01592 for ; Tue, 16 Apr 2002 19:01:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19547 for seamoby-archive@odin.ietf.org; Tue, 16 Apr 2002 19:01:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18882; Tue, 16 Apr 2002 18:47:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18851 for ; Tue, 16 Apr 2002 18:47:00 -0400 (EDT) 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 SAA00083 for ; Tue, 16 Apr 2002 18:46:56 -0400 (EDT) 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 g3GMkQI13586; Tue, 16 Apr 2002 15:46:27 -0700 (PDT) Message-ID: <032001c1e598$5138ef40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 16 Apr 2002 15:44:48 -0700 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, that's what I'm saying. There is one case where the MN needs to choose, and the other where the MN and AR get an L2 address and don't have a choice. The handover happens because, if not, the power will fade and the MN loses link connectivity. The former case might require capabilities, the latter just requires cross link ARP. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Tuesday, April 16, 2002 2:17 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > What do you mean when you say that hearing multiple L2 is equivalent to > inter-technology case? I do not get the point. Why can't the MN listen to > different L2 beacons of the same technology? I guess it can, and hence, it > still needs to chose one among them for handoff. Then the issue is exactly > the same as Glenn raised for single NIC case: How to get capabilities > without letting go the old connection? Of course, I am assuming that these > L2's have comparable signal strengths. > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > >[The Issue] > > > >It seems that the minutes indicate that people have somehow come to a > > > >conclusion that there is no need for access routers to divulge that > >they > > > >are > > > >geographically adjancent to themselves via the IP infrastructure. The > > > >minutes also seem to indicate that the mobile alone should be the > >only way > > > >to pass addresses of CARs to source ARs. > > > > > > > >[Technical Questions] > > > >O.K. If this is true then how will a mobile pass this information to > >their > > > >source AR if the mobile only has one NIC and that NIC is only capable > >of > > > >listening to one media at once? > > > > > > [HC] I agree that this is a genuine technical problem. What I would > >really > > > like to understand is whether the above is a relevant case for CAR > >discovery > > > or we simply neglect it and focus only on two physical interfaces > >case. I > > > raised this question before, but we have not had much discussion on > >it. In > > > any case, address translation part of CARD will be required in this > >case for > > > fast handoff support. > > > > > > >In a single interface handoff situation, Layer 2 typically delivers the > >AP or AR L2 identifier to which the MN will be handed over. This > >information is required (by the MIP fast handover algorithms) at the > >MN's AR. So the issue is fairly simple: the AR must be able to do > >reverse address translation in order that it can contact the other AR. > >Capabilities aren't involved, except to the extent that the MN can hear > >multiple L2s and make the decision. But this is exactly the same as for > >the intertechnology case. > > > > 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 Wed Apr 17 06:10: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 GAA13660 for ; Wed, 17 Apr 2002 06:10:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28569; Wed, 17 Apr 2002 05:52:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28537 for ; Wed, 17 Apr 2002 05:52:53 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13418 for ; Wed, 17 Apr 2002 05:52:48 -0400 (EDT) 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 g3H9qps7010350 for ; Wed, 17 Apr 2002 11:52:51 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Apr 17 11:49:34 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 11:41:44 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF084@esealnt117> From: "Karim El-Malki (ERA)" To: "'James Kempf'" , Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 11:50:13 +0200 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 reason I sent my previous email was that I got the feeling from this thread that there is focus on providing a solution for the network-centric case (i.e. the network handles CAR discovery and the MN isn't involved). I wanted to point out that this solution would not be applicable to the mobile-centric case and clarify that this case is supported by MIP (v4 and v6) fast handoffs. From the IETF meeting there was a majority who wanted to go for the mobile-centric case (i.e. where the mobile is involved and decides). Following Steve's presentation I think that became quite clear. So, why are there discussions about doing a solution which is meant for the network-centric case only? This solution wouldn't apply to the mobile-centric case. That's what I was meant to ask in my last email. /Karim > Karim, > > But it is applicable to network initiated handoff. And there are two > algorithms, one in which the access router sends a PrxyRtAdv > to the MN > and one in which the MN is switched (for FMIPv4). > > jak > > ----- Original Message ----- > From: "Karim El-Malki (ERA)" > To: "'James Kempf'" ; "Hemant Chaskar" > ; > Sent: Tuesday, April 16, 2002 11:55 AM > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > >[The Issue] > > > > >It seems that the minutes indicate that people have > > > somehow come to a > > > > >conclusion that there is no need for access routers to > > > divulge that > > > they > > > > >are > > > > >geographically adjancent to themselves via the IP > > > infrastructure. The > > > > >minutes also seem to indicate that the mobile alone should be > the > > > only way > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > >[Technical Questions] > > > > >O.K. If this is true then how will a mobile pass this > > > information to > > > their > > > > >source AR if the mobile only has one NIC and that NIC is > > > only capable > > > of > > > > >listening to one media at once? > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > would > > > really > > > > like to understand is whether the above is a relevant case for > CAR > > > discovery > > > > or we simply neglect it and focus only on two > physical interfaces > > > case. I > > > > raised this question before, but we have not had much > discussion > on > > > it. In > > > > any case, address translation part of CARD will be required in > this > > > case for > > > > fast handoff support. > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > delivers the > > > AP or AR L2 identifier to which the MN will be handed over. This > > > information is required (by the MIP fast handover algorithms) at > the > > > MN's AR. So the issue is fairly simple: the AR must be > able to do > > > reverse address translation in order that it can contact the > > > other AR. > > > > This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > In Mobile-initiated we consider the useful case where the MN can > recover > > the CAR IP address/es from the L2 trigger. The MN then > sends a Proxy > > Router Solicitation (RtSolPr) to its curent AR containing > one or more > CAR > > IP addresses. This means that the source AR already gets the CAR > addresses. > > So we can do without the AR doing translation or discovering > geographical > > adjacency. The MN can pass these CAR address/es to the > source AR for > both > > single and multiple-interface MNs. So I think that the > conclusion from > the > > meeting is compatible with MIP Fast Handoffs. > > > > /Karim > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 17 06:10: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 GAA13670 for ; Wed, 17 Apr 2002 06:10:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29534 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 06:10:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28569; Wed, 17 Apr 2002 05:52:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28537 for ; Wed, 17 Apr 2002 05:52:53 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13418 for ; Wed, 17 Apr 2002 05:52:48 -0400 (EDT) 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 g3H9qps7010350 for ; Wed, 17 Apr 2002 11:52:51 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Apr 17 11:49:34 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 11:41:44 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF084@esealnt117> From: "Karim El-Malki (ERA)" To: "'James Kempf'" , Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 11:50:13 +0200 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 reason I sent my previous email was that I got the feeling from this thread that there is focus on providing a solution for the network-centric case (i.e. the network handles CAR discovery and the MN isn't involved). I wanted to point out that this solution would not be applicable to the mobile-centric case and clarify that this case is supported by MIP (v4 and v6) fast handoffs. From the IETF meeting there was a majority who wanted to go for the mobile-centric case (i.e. where the mobile is involved and decides). Following Steve's presentation I think that became quite clear. So, why are there discussions about doing a solution which is meant for the network-centric case only? This solution wouldn't apply to the mobile-centric case. That's what I was meant to ask in my last email. /Karim > Karim, > > But it is applicable to network initiated handoff. And there are two > algorithms, one in which the access router sends a PrxyRtAdv > to the MN > and one in which the MN is switched (for FMIPv4). > > jak > > ----- Original Message ----- > From: "Karim El-Malki (ERA)" > To: "'James Kempf'" ; "Hemant Chaskar" > ; > Sent: Tuesday, April 16, 2002 11:55 AM > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > >[The Issue] > > > > >It seems that the minutes indicate that people have > > > somehow come to a > > > > >conclusion that there is no need for access routers to > > > divulge that > > > they > > > > >are > > > > >geographically adjancent to themselves via the IP > > > infrastructure. The > > > > >minutes also seem to indicate that the mobile alone should be > the > > > only way > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > >[Technical Questions] > > > > >O.K. If this is true then how will a mobile pass this > > > information to > > > their > > > > >source AR if the mobile only has one NIC and that NIC is > > > only capable > > > of > > > > >listening to one media at once? > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > would > > > really > > > > like to understand is whether the above is a relevant case for > CAR > > > discovery > > > > or we simply neglect it and focus only on two > physical interfaces > > > case. I > > > > raised this question before, but we have not had much > discussion > on > > > it. In > > > > any case, address translation part of CARD will be required in > this > > > case for > > > > fast handoff support. > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > delivers the > > > AP or AR L2 identifier to which the MN will be handed over. This > > > information is required (by the MIP fast handover algorithms) at > the > > > MN's AR. So the issue is fairly simple: the AR must be > able to do > > > reverse address translation in order that it can contact the > > > other AR. > > > > This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > In Mobile-initiated we consider the useful case where the MN can > recover > > the CAR IP address/es from the L2 trigger. The MN then > sends a Proxy > > Router Solicitation (RtSolPr) to its curent AR containing > one or more > CAR > > IP addresses. This means that the source AR already gets the CAR > addresses. > > So we can do without the AR doing translation or discovering > geographical > > adjacency. The MN can pass these CAR address/es to the > source AR for > both > > single and multiple-interface MNs. So I think that the > conclusion from > the > > meeting is compatible with MIP Fast Handoffs. > > > > /Karim > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 17 06:21: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 GAA13790 for ; Wed, 17 Apr 2002 06:21:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29709; Wed, 17 Apr 2002 06:16:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29668 for ; Wed, 17 Apr 2002 06:16:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13754 for ; Wed, 17 Apr 2002 06:15:58 -0400 (EDT) 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 g3HAFx3G017050 for ; Wed, 17 Apr 2002 12:15:59 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Apr 17 12:13:21 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTNKX2>; Wed, 17 Apr 2002 12:17:51 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> From: "Karim El-Malki (ERA)" To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 12:13:57 +0200 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 > > > In a single interface handoff situation, Layer 2 typically > > > delivers the > > > AP or AR L2 identifier to which the MN will be handed over. This > > > information is required (by the MIP fast handover > algorithms) at the > > > MN's AR. So the issue is fairly simple: the AR must be > able to do > > > reverse address translation in order that it can contact the > > > other AR. > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > >In Mobile-initiated we consider the useful case where the > MN can recover > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > >Router Solicitation (RtSolPr) to its curent AR containing > one or more CAR > >IP addresses. This means that the source AR already gets > the CAR addresses. > >So we can do without the AR doing translation or > discovering geographical > >adjacency. The MN can pass these CAR address/es to the > source AR for both > >single and multiple-interface MNs. So I think that the > conclusion from the > >meeting is compatible with MIP Fast Handoffs. > > > >/Karim > > [HC] I am wondering, if this useful case is genral enough. > In other words, > can MN always get IP addresses from AP beacons (or L2 > triggers) without > having to acquire connectivity with AP. More so, in single NIC case. [KEM] If you get a trigger at the MN you are somehow told that you have to move and this could contain the network's desired place where you should move (if it's multi-technology then one network may not know all that is possible). Here it is assumed that these are IP addresses or that the IP addresses can be easily recovered. The MN collects the full list of CAR addresses and decides. At least that's what I understood people wanted at the last meeting. Do you think it is not generic enough since it relies on IP addresses recovered from triggers? > > Also, could you please say what conclusion you are referring to. [KEM] I'm referring to the discussion about mobile-centric vs network-centric approaches related to Steve's presentation. I believe there was a consensus on mobile-centric, which favours a CAR discovery solution where the MN is involved and takes the decisions. /Karim _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 17 06:21: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 GAA13800 for ; Wed, 17 Apr 2002 06:21:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29785 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 06:21:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29709; Wed, 17 Apr 2002 06:16:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29668 for ; Wed, 17 Apr 2002 06:16:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13754 for ; Wed, 17 Apr 2002 06:15:58 -0400 (EDT) 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 g3HAFx3G017050 for ; Wed, 17 Apr 2002 12:15:59 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Apr 17 12:13:21 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTNKX2>; Wed, 17 Apr 2002 12:17:51 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> From: "Karim El-Malki (ERA)" To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 12:13:57 +0200 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 > > > In a single interface handoff situation, Layer 2 typically > > > delivers the > > > AP or AR L2 identifier to which the MN will be handed over. This > > > information is required (by the MIP fast handover > algorithms) at the > > > MN's AR. So the issue is fairly simple: the AR must be > able to do > > > reverse address translation in order that it can contact the > > > other AR. > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > >In Mobile-initiated we consider the useful case where the > MN can recover > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > >Router Solicitation (RtSolPr) to its curent AR containing > one or more CAR > >IP addresses. This means that the source AR already gets > the CAR addresses. > >So we can do without the AR doing translation or > discovering geographical > >adjacency. The MN can pass these CAR address/es to the > source AR for both > >single and multiple-interface MNs. So I think that the > conclusion from the > >meeting is compatible with MIP Fast Handoffs. > > > >/Karim > > [HC] I am wondering, if this useful case is genral enough. > In other words, > can MN always get IP addresses from AP beacons (or L2 > triggers) without > having to acquire connectivity with AP. More so, in single NIC case. [KEM] If you get a trigger at the MN you are somehow told that you have to move and this could contain the network's desired place where you should move (if it's multi-technology then one network may not know all that is possible). Here it is assumed that these are IP addresses or that the IP addresses can be easily recovered. The MN collects the full list of CAR addresses and decides. At least that's what I understood people wanted at the last meeting. Do you think it is not generic enough since it relies on IP addresses recovered from triggers? > > Also, could you please say what conclusion you are referring to. [KEM] I'm referring to the discussion about mobile-centric vs network-centric approaches related to Steve's presentation. I believe there was a consensus on mobile-centric, which favours a CAR discovery solution where the MN is involved and takes the decisions. /Karim _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 17 07:29: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 HAA14655 for ; Wed, 17 Apr 2002 07:29:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02402; Wed, 17 Apr 2002 07:22:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02375 for ; Wed, 17 Apr 2002 07:22:40 -0400 (EDT) Received: from hotmail.com (oe25.law4.hotmail.com [216.33.148.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14601 for ; Wed, 17 Apr 2002 07:22:36 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 04:22:08 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "Karim El-Malki \(ERA\)" , "'Hemant Chaskar'" , , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 20:27:13 -0700 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: 17 Apr 2002 11:22:08.0633 (UTC) FILETIME=[1C8BC690:01C1E602] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Karim, What kind of L2 triggers provide the IP address(es) of the target (candidate) access routers? Would you mind providing some examples? Thanks. Eunsoo ----- Original Message ----- From: "Karim El-Malki (ERA)" To: "'Hemant Chaskar'" ; ; Sent: Wednesday, April 17, 2002 3:13 AM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > In a single interface handoff situation, Layer 2 typically > > > > delivers the > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > information is required (by the MIP fast handover > > algorithms) at the > > > > MN's AR. So the issue is fairly simple: the AR must be > > able to do > > > > reverse address translation in order that it can contact the > > > > other AR. > > > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > >In Mobile-initiated we consider the useful case where the > > MN can recover > > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > > >Router Solicitation (RtSolPr) to its curent AR containing > > one or more CAR > > >IP addresses. This means that the source AR already gets > > the CAR addresses. > > >So we can do without the AR doing translation or > > discovering geographical > > >adjacency. The MN can pass these CAR address/es to the > > source AR for both > > >single and multiple-interface MNs. So I think that the > > conclusion from the > > >meeting is compatible with MIP Fast Handoffs. > > > > > >/Karim > > > > [HC] I am wondering, if this useful case is genral enough. > > In other words, > > can MN always get IP addresses from AP beacons (or L2 > > triggers) without > > having to acquire connectivity with AP. More so, in single NIC case. > > [KEM] If you get a trigger at the MN you are somehow told > that you have to move and this could contain the network's desired > place where you should move (if it's multi-technology then one network > may not know all that is possible). Here it is assumed that these are > IP addresses or that the IP addresses can be easily recovered. The MN > collects the full list of CAR addresses and decides. At least that's > what I understood people wanted at the last meeting. Do you think it > is not generic enough since it relies on IP addresses recovered from > triggers? > > > > > Also, could you please say what conclusion you are referring to. > > [KEM] I'm referring to the discussion about mobile-centric vs network-centric > approaches related to Steve's presentation. I believe there was a > consensus on mobile-centric, which favours a CAR discovery solution where the > MN is involved and takes the decisions. > > /Karim > > _______________________________________________ > Seamoby mailing 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 Apr 17 07:29: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 HAA14665 for ; Wed, 17 Apr 2002 07:29:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA02561 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 07:29:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02402; Wed, 17 Apr 2002 07:22:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02375 for ; Wed, 17 Apr 2002 07:22:40 -0400 (EDT) Received: from hotmail.com (oe25.law4.hotmail.com [216.33.148.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14601 for ; Wed, 17 Apr 2002 07:22:36 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 04:22:08 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "Karim El-Malki \(ERA\)" , "'Hemant Chaskar'" , , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 20:27:13 -0700 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: 17 Apr 2002 11:22:08.0633 (UTC) FILETIME=[1C8BC690:01C1E602] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Karim, What kind of L2 triggers provide the IP address(es) of the target (candidate) access routers? Would you mind providing some examples? Thanks. Eunsoo ----- Original Message ----- From: "Karim El-Malki (ERA)" To: "'Hemant Chaskar'" ; ; Sent: Wednesday, April 17, 2002 3:13 AM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > In a single interface handoff situation, Layer 2 typically > > > > delivers the > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > information is required (by the MIP fast handover > > algorithms) at the > > > > MN's AR. So the issue is fairly simple: the AR must be > > able to do > > > > reverse address translation in order that it can contact the > > > > other AR. > > > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > >In Mobile-initiated we consider the useful case where the > > MN can recover > > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > > >Router Solicitation (RtSolPr) to its curent AR containing > > one or more CAR > > >IP addresses. This means that the source AR already gets > > the CAR addresses. > > >So we can do without the AR doing translation or > > discovering geographical > > >adjacency. The MN can pass these CAR address/es to the > > source AR for both > > >single and multiple-interface MNs. So I think that the > > conclusion from the > > >meeting is compatible with MIP Fast Handoffs. > > > > > >/Karim > > > > [HC] I am wondering, if this useful case is genral enough. > > In other words, > > can MN always get IP addresses from AP beacons (or L2 > > triggers) without > > having to acquire connectivity with AP. More so, in single NIC case. > > [KEM] If you get a trigger at the MN you are somehow told > that you have to move and this could contain the network's desired > place where you should move (if it's multi-technology then one network > may not know all that is possible). Here it is assumed that these are > IP addresses or that the IP addresses can be easily recovered. The MN > collects the full list of CAR addresses and decides. At least that's > what I understood people wanted at the last meeting. Do you think it > is not generic enough since it relies on IP addresses recovered from > triggers? > > > > > Also, could you please say what conclusion you are referring to. > > [KEM] I'm referring to the discussion about mobile-centric vs network-centric > approaches related to Steve's presentation. I believe there was a > consensus on mobile-centric, which favours a CAR discovery solution where the > MN is involved and takes the decisions. > > /Karim > > _______________________________________________ > Seamoby mailing 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 Apr 17 10:22: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 KAA19576 for ; Wed, 17 Apr 2002 10:22:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11978; Wed, 17 Apr 2002 10:07:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11910 for ; Wed, 17 Apr 2002 10:07:47 -0400 (EDT) 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 KAA18675 for ; Wed, 17 Apr 2002 10:07:42 -0400 (EDT) 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 g3HEAOH04880 for ; Wed, 17 Apr 2002 09:10:24 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 09:07:40 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 09:06:23 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 10:06:22 -0400 Message-ID: Thread-Topic: [Seamoby] Minutes for Meeting at IETF 53 Thread-Index: AcHl+PNuS8RTkTeeQQeOOOzY1ETz5QAHYqxQ To: , , , X-OriginalArrivalTime: 17 Apr 2002 14:06:23.0535 (UTC) FILETIME=[0E867BF0:01C1E619] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA11911 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Karim, -----Original Message----- From: ext Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Wednesday, April 17, 2002 6:14 AM To: 'Hemant Chaskar'; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > In a single interface handoff situation, Layer 2 typically > > > delivers the > > > AP or AR L2 identifier to which the MN will be handed over. This > > > information is required (by the MIP fast handover > algorithms) at the > > > MN's AR. So the issue is fairly simple: the AR must be > able to do > > > reverse address translation in order that it can contact the > > > other AR. > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > >In Mobile-initiated we consider the useful case where the > MN can recover > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > >Router Solicitation (RtSolPr) to its curent AR containing > one or more CAR > >IP addresses. This means that the source AR already gets > the CAR addresses. > >So we can do without the AR doing translation or > discovering geographical > >adjacency. The MN can pass these CAR address/es to the > source AR for both > >single and multiple-interface MNs. So I think that the > conclusion from the > >meeting is compatible with MIP Fast Handoffs. > > > >/Karim > > [HC] I am wondering, if this useful case is genral enough. > In other words, > can MN always get IP addresses from AP beacons (or L2 > triggers) without > having to acquire connectivity with AP. More so, in single NIC case. [KEM] If you get a trigger at the MN you are somehow told that you have to move and this could contain the network's desired place where you should move (if it's multi-technology then one network may not know all that is possible). Here it is assumed that these are IP addresses or that the IP addresses can be easily recovered. The MN collects the full list of CAR addresses and decides. At least that's what I understood people wanted at the last meeting. Do you think it is not generic enough since it relies on IP addresses recovered from triggers? [DOT] How did the trigger get the IP addresses? Is this also possible in the inter-technology/inter-domain case? If so, is CAR discovery then still necessary? Or in other words, isn't your magic trigger with the IP addresses of places the network wants me to go not exactly the list of possible GAARs from a network point of view? Though it is still not clear to me how this trigger is provided. > > Also, could you please say what conclusion you are referring to. [KEM] I'm referring to the discussion about mobile-centric vs network-centric approaches related to Steve's presentation. I believe there was a consensus on mobile-centric, which favours a CAR discovery solution where the MN is involved and takes the decisions. [DOT] Steve's presentation has already had a large influence on the requirements discussion regarding the involvement of the MN, which has been emphasized in the requirements. However, concluding now further from his presentation that the WG is in favour regarding certain network-centric (what is that exactly BTW?) or mobile-centric approaches does not put the WG in the position it is supposed to be. More precisely, believing in consensus doesn't make it a consensus. I cannot remember that there was a consensus call during the meeting or after. There was explicitly a question whether to let go the network case, which was only supported by three hands. There was also a comment from Steve's side that "There are times when information from the ARs might help the mobile node make a better decision. I wasn't advocating killing this work, but it just needs to fit into a basic model.". Let us simply see whether network assistance (if that's what you mean with network-centric) solutions would fly under the constraint of the current requirements (which emphasizes MN's role in this process). Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Wed Apr 17 10:22: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 KAA19589 for ; Wed, 17 Apr 2002 10:22:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12859 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 10:22:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11978; Wed, 17 Apr 2002 10:07:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11910 for ; Wed, 17 Apr 2002 10:07:47 -0400 (EDT) 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 KAA18675 for ; Wed, 17 Apr 2002 10:07:42 -0400 (EDT) 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 g3HEAOH04880 for ; Wed, 17 Apr 2002 09:10:24 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Apr 2002 09:07:40 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 17 Apr 2002 09:06:23 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 10:06:22 -0400 Message-ID: Thread-Topic: [Seamoby] Minutes for Meeting at IETF 53 Thread-Index: AcHl+PNuS8RTkTeeQQeOOOzY1ETz5QAHYqxQ To: , , , X-OriginalArrivalTime: 17 Apr 2002 14:06:23.0535 (UTC) FILETIME=[0E867BF0:01C1E619] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA11911 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 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 Karim, -----Original Message----- From: ext Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Wednesday, April 17, 2002 6:14 AM To: 'Hemant Chaskar'; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > In a single interface handoff situation, Layer 2 typically > > > delivers the > > > AP or AR L2 identifier to which the MN will be handed over. This > > > information is required (by the MIP fast handover > algorithms) at the > > > MN's AR. So the issue is fairly simple: the AR must be > able to do > > > reverse address translation in order that it can contact the > > > other AR. > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > >In Mobile-initiated we consider the useful case where the > MN can recover > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > >Router Solicitation (RtSolPr) to its curent AR containing > one or more CAR > >IP addresses. This means that the source AR already gets > the CAR addresses. > >So we can do without the AR doing translation or > discovering geographical > >adjacency. The MN can pass these CAR address/es to the > source AR for both > >single and multiple-interface MNs. So I think that the > conclusion from the > >meeting is compatible with MIP Fast Handoffs. > > > >/Karim > > [HC] I am wondering, if this useful case is genral enough. > In other words, > can MN always get IP addresses from AP beacons (or L2 > triggers) without > having to acquire connectivity with AP. More so, in single NIC case. [KEM] If you get a trigger at the MN you are somehow told that you have to move and this could contain the network's desired place where you should move (if it's multi-technology then one network may not know all that is possible). Here it is assumed that these are IP addresses or that the IP addresses can be easily recovered. The MN collects the full list of CAR addresses and decides. At least that's what I understood people wanted at the last meeting. Do you think it is not generic enough since it relies on IP addresses recovered from triggers? [DOT] How did the trigger get the IP addresses? Is this also possible in the inter-technology/inter-domain case? If so, is CAR discovery then still necessary? Or in other words, isn't your magic trigger with the IP addresses of places the network wants me to go not exactly the list of possible GAARs from a network point of view? Though it is still not clear to me how this trigger is provided. > > Also, could you please say what conclusion you are referring to. [KEM] I'm referring to the discussion about mobile-centric vs network-centric approaches related to Steve's presentation. I believe there was a consensus on mobile-centric, which favours a CAR discovery solution where the MN is involved and takes the decisions. [DOT] Steve's presentation has already had a large influence on the requirements discussion regarding the involvement of the MN, which has been emphasized in the requirements. However, concluding now further from his presentation that the WG is in favour regarding certain network-centric (what is that exactly BTW?) or mobile-centric approaches does not put the WG in the position it is supposed to be. More precisely, believing in consensus doesn't make it a consensus. I cannot remember that there was a consensus call during the meeting or after. There was explicitly a question whether to let go the network case, which was only supported by three hands. There was also a comment from Steve's side that "There are times when information from the ARs might help the mobile node make a better decision. I wasn't advocating killing this work, but it just needs to fit into a basic model.". Let us simply see whether network assistance (if that's what you mean with network-centric) solutions would fly under the constraint of the current requirements (which emphasizes MN's role in this process). Regards, Dirk _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 17 10:52: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 KAA21466 for ; Wed, 17 Apr 2002 10:52:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14770; Wed, 17 Apr 2002 10:46:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14737 for ; Wed, 17 Apr 2002 10:46:11 -0400 (EDT) Received: from hotmail.com (f255.law7.hotmail.com [216.33.236.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21135 for ; Wed, 17 Apr 2002 10:46:06 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 07:45:39 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 14:45:38 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 14:45:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 14:45:39.0007 (UTC) FILETIME=[8A7EFCF0:01C1E61E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: If there are more than one L2 beacons available (of comparable signal strength), probably governed by different ARs, how do we choose? I do not have problem choosing randomly, but just want to confirm if this is the way we want to proceed. There is no doubt that handoff is necessary as old link will fade, but you still have choice as to which new beacon to hold on to. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Tue, 16 Apr 2002 15:44:48 -0700 > >Right, that's what I'm saying. There is one case where the MN needs to >choose, and the other where the MN and AR get an L2 address and don't >have a choice. The handover happens because, if not, the power will fade >and the MN loses link connectivity. > >The former case might require capabilities, the latter just requires >cross link ARP. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Tuesday, April 16, 2002 2:17 PM >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James: > > > > What do you mean when you say that hearing multiple L2 is equivalent >to > > inter-technology case? I do not get the point. Why can't the MN listen >to > > different L2 beacons of the same technology? I guess it can, and >hence, it > > still needs to chose one among them for handoff. Then the issue is >exactly > > the same as Glenn raised for single NIC case: How to get capabilities > > without letting go the old connection? Of course, I am assuming that >these > > L2's have comparable signal strengths. > > > > Hemant > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > >[The Issue] > > > > >It seems that the minutes indicate that people have somehow come >to a > > > > >conclusion that there is no need for access routers to divulge >that > > >they > > > > >are > > > > >geographically adjancent to themselves via the IP infrastructure. >The > > > > >minutes also seem to indicate that the mobile alone should be the > > >only way > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > >[Technical Questions] > > > > >O.K. If this is true then how will a mobile pass this information >to > > >their > > > > >source AR if the mobile only has one NIC and that NIC is only >capable > > >of > > > > >listening to one media at once? > > > > > > > > [HC] I agree that this is a genuine technical problem. What I >would > > >really > > > > like to understand is whether the above is a relevant case for CAR > > >discovery > > > > or we simply neglect it and focus only on two physical interfaces > > >case. I > > > > raised this question before, but we have not had much discussion >on > > >it. In > > > > any case, address translation part of CARD will be required in >this > > >case for > > > > fast handoff support. > > > > > > > > > >In a single interface handoff situation, Layer 2 typically delivers >the > > >AP or AR L2 identifier to which the MN will be handed over. This > > >information is required (by the MIP fast handover algorithms) at the > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > >reverse address translation in order that it can contact the other >AR. > > >Capabilities aren't involved, except to the extent that the MN can >hear > > >multiple L2s and make the decision. But this is exactly the same as >for > > >the intertechnology case. > > > > > > jak > > > > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > _________________________________________________________________ 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 Apr 17 10:52: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 KAA21478 for ; Wed, 17 Apr 2002 10:52:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16482 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 10:52:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14770; Wed, 17 Apr 2002 10:46:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14737 for ; Wed, 17 Apr 2002 10:46:11 -0400 (EDT) Received: from hotmail.com (f255.law7.hotmail.com [216.33.236.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21135 for ; Wed, 17 Apr 2002 10:46:06 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 07:45:39 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 14:45:38 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 14:45:38 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 14:45:39.0007 (UTC) FILETIME=[8A7EFCF0:01C1E61E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: If there are more than one L2 beacons available (of comparable signal strength), probably governed by different ARs, how do we choose? I do not have problem choosing randomly, but just want to confirm if this is the way we want to proceed. There is no doubt that handoff is necessary as old link will fade, but you still have choice as to which new beacon to hold on to. Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Tue, 16 Apr 2002 15:44:48 -0700 > >Right, that's what I'm saying. There is one case where the MN needs to >choose, and the other where the MN and AR get an L2 address and don't >have a choice. The handover happens because, if not, the power will fade >and the MN loses link connectivity. > >The former case might require capabilities, the latter just requires >cross link ARP. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Tuesday, April 16, 2002 2:17 PM >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James: > > > > What do you mean when you say that hearing multiple L2 is equivalent >to > > inter-technology case? I do not get the point. Why can't the MN listen >to > > different L2 beacons of the same technology? I guess it can, and >hence, it > > still needs to chose one among them for handoff. Then the issue is >exactly > > the same as Glenn raised for single NIC case: How to get capabilities > > without letting go the old connection? Of course, I am assuming that >these > > L2's have comparable signal strengths. > > > > Hemant > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > >[The Issue] > > > > >It seems that the minutes indicate that people have somehow come >to a > > > > >conclusion that there is no need for access routers to divulge >that > > >they > > > > >are > > > > >geographically adjancent to themselves via the IP infrastructure. >The > > > > >minutes also seem to indicate that the mobile alone should be the > > >only way > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > >[Technical Questions] > > > > >O.K. If this is true then how will a mobile pass this information >to > > >their > > > > >source AR if the mobile only has one NIC and that NIC is only >capable > > >of > > > > >listening to one media at once? > > > > > > > > [HC] I agree that this is a genuine technical problem. What I >would > > >really > > > > like to understand is whether the above is a relevant case for CAR > > >discovery > > > > or we simply neglect it and focus only on two physical interfaces > > >case. I > > > > raised this question before, but we have not had much discussion >on > > >it. In > > > > any case, address translation part of CARD will be required in >this > > >case for > > > > fast handoff support. > > > > > > > > > >In a single interface handoff situation, Layer 2 typically delivers >the > > >AP or AR L2 identifier to which the MN will be handed over. This > > >information is required (by the MIP fast handover algorithms) at the > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > >reverse address translation in order that it can contact the other >AR. > > >Capabilities aren't involved, except to the extent that the MN can >hear > > >multiple L2s and make the decision. But this is exactly the same as >for > > >the intertechnology case. > > > > > > jak > > > > > > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > _________________________________________________________________ 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 Apr 17 11:08: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 LAA22236 for ; Wed, 17 Apr 2002 11:08:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17613; Wed, 17 Apr 2002 10:57:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17577 for ; Wed, 17 Apr 2002 10:57:04 -0400 (EDT) Received: from hotmail.com (f4.law7.hotmail.com [216.33.237.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21718 for ; Wed, 17 Apr 2002 10:56:58 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 07:56:31 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 14:56:31 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: Karim.El-Malki@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 14:56:31 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 14:56:31.0634 (UTC) FILETIME=[0F7DF720:01C1E620] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim: >From: "Karim El-Malki (ERA)" >To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com, >seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Wed, 17 Apr 2002 12:13:57 +0200 > > > > > In a single interface handoff situation, Layer 2 typically > > > > delivers the > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > information is required (by the MIP fast handover > > algorithms) at the > > > > MN's AR. So the issue is fairly simple: the AR must be > > able to do > > > > reverse address translation in order that it can contact the > > > > other AR. > > > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > >In Mobile-initiated we consider the useful case where the > > MN can recover > > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > > >Router Solicitation (RtSolPr) to its curent AR containing > > one or more CAR > > >IP addresses. This means that the source AR already gets > > the CAR addresses. > > >So we can do without the AR doing translation or > > discovering geographical > > >adjacency. The MN can pass these CAR address/es to the > > source AR for both > > >single and multiple-interface MNs. So I think that the > > conclusion from the > > >meeting is compatible with MIP Fast Handoffs. > > > > > >/Karim > > > > [HC] I am wondering, if this useful case is genral enough. > > In other words, > > can MN always get IP addresses from AP beacons (or L2 > > triggers) without > > having to acquire connectivity with AP. More so, in single NIC case. > >[KEM] If you get a trigger at the MN you are somehow told >that you have to move and this could contain the network's desired >place where you should move (if it's multi-technology then one network >may not know all that is possible). Here it is assumed that these are >IP addresses or that the IP addresses can be easily recovered. The MN >collects the full list of CAR addresses and decides. At least that's >what I understood people wanted at the last meeting. Do you think it >is not generic enough since it relies on IP addresses recovered from >triggers? [HC]I think the issue was raised about single NIC case. So, if you are saying that in general single NIC case, IP addresses will always be available in beacons (L2 triggers), then our problem becomes simpler, that is great. I am still looking for answer to question: Is capability discovery required in this case and how to do this? When you receive multiple L2 becons (and hence multiple IP addresses from those beacons from L2 triggers that you have in mind), which one to choose still remains a question. Or, will L2 triggers also include capability set of ARs? Also, another issue that was raised for both single and multiple NIC case was about power and bandwidth considerations in receiving capabilities at MN. Again, if that is not a concern then our problem becomes simpler. > > > > > Also, could you please say what conclusion you are referring to. > >[KEM] I'm referring to the discussion about mobile-centric vs >network-centric >approaches related to Steve's presentation. I believe there was a >consensus on mobile-centric, which favours a CAR discovery solution where >the >MN is involved and takes the decisions. > >/Karim _________________________________________________________________ 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 Apr 17 11:08: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 LAA22249 for ; Wed, 17 Apr 2002 11:08:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19966 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 11:08:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17613; Wed, 17 Apr 2002 10:57:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17577 for ; Wed, 17 Apr 2002 10:57:04 -0400 (EDT) Received: from hotmail.com (f4.law7.hotmail.com [216.33.237.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21718 for ; Wed, 17 Apr 2002 10:56:58 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 07:56:31 -0700 Received: from 63.78.179.6 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 14:56:31 GMT X-Originating-IP: [63.78.179.6] From: "Hemant Chaskar" To: Karim.El-Malki@era.ericsson.se, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 14:56:31 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 14:56:31.0634 (UTC) FILETIME=[0F7DF720:01C1E620] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim: >From: "Karim El-Malki (ERA)" >To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com, >seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Wed, 17 Apr 2002 12:13:57 +0200 > > > > > In a single interface handoff situation, Layer 2 typically > > > > delivers the > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > information is required (by the MIP fast handover > > algorithms) at the > > > > MN's AR. So the issue is fairly simple: the AR must be > > able to do > > > > reverse address translation in order that it can contact the > > > > other AR. > > > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > >In Mobile-initiated we consider the useful case where the > > MN can recover > > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > > >Router Solicitation (RtSolPr) to its curent AR containing > > one or more CAR > > >IP addresses. This means that the source AR already gets > > the CAR addresses. > > >So we can do without the AR doing translation or > > discovering geographical > > >adjacency. The MN can pass these CAR address/es to the > > source AR for both > > >single and multiple-interface MNs. So I think that the > > conclusion from the > > >meeting is compatible with MIP Fast Handoffs. > > > > > >/Karim > > > > [HC] I am wondering, if this useful case is genral enough. > > In other words, > > can MN always get IP addresses from AP beacons (or L2 > > triggers) without > > having to acquire connectivity with AP. More so, in single NIC case. > >[KEM] If you get a trigger at the MN you are somehow told >that you have to move and this could contain the network's desired >place where you should move (if it's multi-technology then one network >may not know all that is possible). Here it is assumed that these are >IP addresses or that the IP addresses can be easily recovered. The MN >collects the full list of CAR addresses and decides. At least that's >what I understood people wanted at the last meeting. Do you think it >is not generic enough since it relies on IP addresses recovered from >triggers? [HC]I think the issue was raised about single NIC case. So, if you are saying that in general single NIC case, IP addresses will always be available in beacons (L2 triggers), then our problem becomes simpler, that is great. I am still looking for answer to question: Is capability discovery required in this case and how to do this? When you receive multiple L2 becons (and hence multiple IP addresses from those beacons from L2 triggers that you have in mind), which one to choose still remains a question. Or, will L2 triggers also include capability set of ARs? Also, another issue that was raised for both single and multiple NIC case was about power and bandwidth considerations in receiving capabilities at MN. Again, if that is not a concern then our problem becomes simpler. > > > > > Also, could you please say what conclusion you are referring to. > >[KEM] I'm referring to the discussion about mobile-centric vs >network-centric >approaches related to Steve's presentation. I believe there was a >consensus on mobile-centric, which favours a CAR discovery solution where >the >MN is involved and takes the decisions. > >/Karim _________________________________________________________________ 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 Apr 17 14:49: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 OAA01397 for ; Wed, 17 Apr 2002 14:48:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06319; Wed, 17 Apr 2002 14:30:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06262 for ; Wed, 17 Apr 2002 14:29:59 -0400 (EDT) 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 OAA00623 for ; Wed, 17 Apr 2002 14:29:55 -0400 (EDT) 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 LAA02104; Wed, 17 Apr 2002 11:29:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3HITQp29295; Wed, 17 Apr 2002 11:29:26 -0700 X-mProtect: <200204171829> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnSQy9S; Wed, 17 Apr 2002 11:29:24 PDT Message-ID: <3CBDBF04.587140C5@iprg.nokia.com> Date: Wed, 17 Apr 2002 11:29:24 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@ietf.org Subject: Re: CT-Notify, Was [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465006F@IL27EXM10.cig.mot.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 Hello Madjid, just got back from a break.. Thank you for your note. Our proposal was to enhance basic MIP handover with context transfers, and to do CT gratuitously (aka proactively). Back then, there was no other proposal (e.g., fast handover) to enhance MIP handovers. The draft (then and now) is independent of MIP protocol itself. However, we think that it is highly beneficial to time-synchronize CT with IP handover. And, our implemenation experience with performing CT along-with MIP supports this. Regards, -Rajeev Nakhjiri Madjid-MNAKHJI1 wrote: > Cool, a simple Nack might not hurt, > Was your proposal based on a different handover proposal than > the ones in MIP WG? I remember readin it long time ago and didn't > recognize some messages? > > BR, > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Tuesday, April 09, 2002 4:28 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'James Kempf'; Gary Kenward; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > all you have to do is to add a CT-NACK, > > please, look at our TEXT proposal. > > We even have a CT-NACK for each feature. > > Right. A simple notification message would suffice. > > BTW, in our framework we call it CTIN-Ack now (Section 5.2); > earlier versions (going back to Pittsburgh IETF) called > it SHACK :-) > > Regards, > > -Rajeev > > > > > > > madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Monday, April 08, 2002 1:32 PM > > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Gary, > > > > I agree about session establishment, but the fact remains that if > > failure of a context transfer for some reason leaves the MN without any > > indication that it should proceed to re-establish the feature, then the > > MN can't know when it should redo signaling to set up its new state. We > > faced this issue with BETH/FMIPv6 and the solution we found there was to > > have routers on the border of a fast handover coverage area inform the > > MN what handover algorithm was supported by routers in the other > > coverage area. While I think this could be done for the cases involving > > router configuration, such as where the next access router can't > > interpret the context, I am not so sure about failure due to dynamic > > conditions, such as that the router currently has all its Gold Class > > service bandwidth allocated (a QoS failure). > > > > In any event, I think there is need for some kind of signaling to > > indicate to the MN that context transfer has failed and that the MN > > needs to redo signaling to re-establish feature contexts. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; "Nakhjiri > > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > > > Cc: ; ; > > Sent: Monday, April 08, 2002 11:08 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James: > > > > > > My main problem with the theme in this discussion is that > > > CT is a context transfer protocol, not a session management protocol. > > > In particular, when there are feature context specific issues, it is > > > best to handle session re-establishment/re-negotiation/maintenance > > using > > > the protocol(s) that were designed to set up the services in the first > > > place. CT should not be stretched into being a general signalling > > protocol. > > > > > > In addition, there is the perhaps greater argument that the most > > > effective method of correcting handover issues is not through over > > > the air signalling exchanges. Given the nature of the wireless link, > > > it will almost always be faster and always be more cost effective, to > > > correct any problems with signalling within the infrastructure (if it > > is > > > needed). > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: April 8, 2002 11:42 > > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Madjid, > > > > > > > > The issue isn't reliability, it is whether the target AR can > > interpret > > > > the context intelligably. If not, the MN may need to recover > > > > by actually > > > > re-initializing whatever feature the context was being transfered > > for. > > > > But it cannot do this unless it knows that the CT has failed. > > > > > > > > For some feature contexts, like header compression, this > > > > isn't a problem > > > > because it will re-initialize automatically, but for AAA or QoS it > > > > clearly will be. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 3:00 PM > > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > > to close without any results. People could not agree on the > > > > > reliability needs of CT. We added a reliability mechanism to our > > > > > CT proposal that covered both retransmission and updates. > > > > > > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > > To: Rajeev Koodli > > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Agree. > > > > > > > > > > But I don't see anything in the CT requirements about handling CT > > > > > failure. > > > > > > > > > > ??? > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > Rajeev, > > > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > > notify > > > > the > > > > > MN > > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > > robustness of CT protocol. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "James Kempf" > > > > > > > Cc: "Gary Kenward" ; > > > > > > > ; ; > > > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > > > negotiation > > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > > should > > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > > upstream > > > > > > > signaling) > > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > > > though it > > > > > > > may > > > > > > > > > be useful for finding a new wireless medium. I also see it > > > > > primarily > > > > > > > for > > > > > > > > > intertechnology handover, or, at best, > > > > interprovider handover. > > > > > > > > > > > > > > > > > > jak > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Rajeev Koodli" > > > > > > > > > To: "Gary Kenward" > > > > > > > > > Cc: ; ; > > > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > > may > > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > > establishment > > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > > one of the > > > > > > > > > > parameters that might then be fed to a selection > > > > algorithm. > > > > > Any > > > > > > > > > > signaling for actually establishing QoS itself > > > > beyond the AR > > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > > understand CARD > > > > > (and > > > > > > > > > > > I don't understand it well), it is not a QoS > > negotiation > > > > > > > > > > > protocol. The main application that you are referring > > to > > > > > > > primarily > > > > > > > > > > > arises out of a perceived need to determine at > > > > the MN the > > > > > best > > > > > > > link > > > > > > > > > > > layer to handover over to when inter-technology > > > > handovers > > > > > are > > > > > > > > > > > involved. > > > > > > > > > > > It can be applied to intra-technology handovers, but > > the > > > > > value > > > > > > > in > > > > > > > > > > > that situation is highly questionable (e.g. > > > > since it is a > > > > > > > discovery > > > > > > > > > > > protocol, the implication is that the purpose is to > > > > > determine > > > > > > > the > > > > > > > > > > > choice of channels available; for intra-technology > > > > > handovers, > > > > > > > there > > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > > available). > > > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > > imply NSIS > > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > > this is not > > > > > the > > > > > > > > > > > intention > > > > > > > > > > > (please correct me if I have this wrong John), in > > which > > > > case > > > > > I > > > > > > > think > > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS > > > > for > > > > > an > > > > > > > > > > > existing flow after a handover, or is it > > > > specifically for > > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > > boolean: > > > > the > > > > > > > role > > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > > believe, > > > > and > > > > > > > clearly > > > > > > > > > > > handover is a dynamic situation that could cause the > > QoS > > > > > > > provided to > > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > > frightening > > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > > transfer has > > > > > been > > > > > > > used > > > > > > > > > > > to > > > > > > > > > > > move the QoS context to the new routers (by the > > > > > > > requirements > > > > > > > > > > > for > > > > > > > > > > > CT this could be intra-, or inter- > > > > technology. Some > > > > > of us > > > > > > > > > > > believe > > > > > > > > > > > that for "seamless" handovers, the > > > > context will be > > > > > > > available > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > > forwarded. > > > > > > > This > > > > > > > > > > > implies > > > > > > > > > > > that there is a relationship, probabilistic > > > > perhaps, > > > > > > > between > > > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > > handover > > > > > decision > > > > > > > (it > > > > > > > > > > > is not clear to me how this happens, but it > > seems > > > > > clear > > > > > > > that > > > > > > > > > > > for a more "seamless" handover, the MN > > > > should chose > > > > > an AR > > > > > > > > > that > > > > > > > > > > > has received the appropriate context; if > > > > not, then > > > > > what? > > > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > > QoS because > > > > > of > > > > > > > > > changes > > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > > predictable > > > > > > > > > > > outcomes? > > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > > entities > > > > > > > > > > > associated > > > > > > > > > > > with the three protocols interact before, > > > > during and after > > > > a > > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > > entities, > > > > the > > > > > > > > > > > respective > > > > > > > > > > > wg's could declare the issue out of scope, but this > > > > approach > > > > > > > does > > > > > > > > > not > > > > > > > > > > > sit well with me, for it seems to defer the > > > > problem to the > > > > > > > people > > > > > > > > > who > > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to > > > > > whether > > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > > Seamoby (CAR > > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > > and not NSIS. > > > > > CAR > > > > > > > > > > > > discovery is supposed to identify candidate access > > > > routers > > > > > > > > > > > > for handoff and QoS is an important property for > > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > > be concerned > > > > > with > > > > > > > the > > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > > draft. > > > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > > concerned > > > > > > > > > > > > with activity > > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Seamoby mailing 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 Wed Apr 17 14:49: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 OAA01427 for ; Wed, 17 Apr 2002 14:49:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA08039 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 14:49:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06319; Wed, 17 Apr 2002 14:30:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06262 for ; Wed, 17 Apr 2002 14:29:59 -0400 (EDT) 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 OAA00623 for ; Wed, 17 Apr 2002 14:29:55 -0400 (EDT) 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 LAA02104; Wed, 17 Apr 2002 11:29:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3HITQp29295; Wed, 17 Apr 2002 11:29:26 -0700 X-mProtect: <200204171829> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnSQy9S; Wed, 17 Apr 2002 11:29:24 PDT Message-ID: <3CBDBF04.587140C5@iprg.nokia.com> Date: Wed, 17 Apr 2002 11:29:24 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@ietf.org Subject: Re: CT-Notify, Was [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465006F@IL27EXM10.cig.mot.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 Hello Madjid, just got back from a break.. Thank you for your note. Our proposal was to enhance basic MIP handover with context transfers, and to do CT gratuitously (aka proactively). Back then, there was no other proposal (e.g., fast handover) to enhance MIP handovers. The draft (then and now) is independent of MIP protocol itself. However, we think that it is highly beneficial to time-synchronize CT with IP handover. And, our implemenation experience with performing CT along-with MIP supports this. Regards, -Rajeev Nakhjiri Madjid-MNAKHJI1 wrote: > Cool, a simple Nack might not hurt, > Was your proposal based on a different handover proposal than > the ones in MIP WG? I remember readin it long time ago and didn't > recognize some messages? > > BR, > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Tuesday, April 09, 2002 4:28 PM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'James Kempf'; Gary Kenward; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > all you have to do is to add a CT-NACK, > > please, look at our TEXT proposal. > > We even have a CT-NACK for each feature. > > Right. A simple notification message would suffice. > > BTW, in our framework we call it CTIN-Ack now (Section 5.2); > earlier versions (going back to Pittsburgh IETF) called > it SHACK :-) > > Regards, > > -Rajeev > > > > > > > madjid > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Monday, April 08, 2002 1:32 PM > > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Gary, > > > > I agree about session establishment, but the fact remains that if > > failure of a context transfer for some reason leaves the MN without any > > indication that it should proceed to re-establish the feature, then the > > MN can't know when it should redo signaling to set up its new state. We > > faced this issue with BETH/FMIPv6 and the solution we found there was to > > have routers on the border of a fast handover coverage area inform the > > MN what handover algorithm was supported by routers in the other > > coverage area. While I think this could be done for the cases involving > > router configuration, such as where the next access router can't > > interpret the context, I am not so sure about failure due to dynamic > > conditions, such as that the router currently has all its Gold Class > > service bandwidth allocated (a QoS failure). > > > > In any event, I think there is need for some kind of signaling to > > indicate to the MN that context transfer has failed and that the MN > > needs to redo signaling to re-establish feature contexts. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; "Nakhjiri > > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > > > Cc: ; ; > > Sent: Monday, April 08, 2002 11:08 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > James: > > > > > > My main problem with the theme in this discussion is that > > > CT is a context transfer protocol, not a session management protocol. > > > In particular, when there are feature context specific issues, it is > > > best to handle session re-establishment/re-negotiation/maintenance > > using > > > the protocol(s) that were designed to set up the services in the first > > > place. CT should not be stretched into being a general signalling > > protocol. > > > > > > In addition, there is the perhaps greater argument that the most > > > effective method of correcting handover issues is not through over > > > the air signalling exchanges. Given the nature of the wireless link, > > > it will almost always be faster and always be more cost effective, to > > > correct any problems with signalling within the infrastructure (if it > > is > > > needed). > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: April 8, 2002 11:42 > > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Madjid, > > > > > > > > The issue isn't reliability, it is whether the target AR can > > interpret > > > > the context intelligably. If not, the MN may need to recover > > > > by actually > > > > re-initializing whatever feature the context was being transfered > > for. > > > > But it cannot do this unless it knows that the CT has failed. > > > > > > > > For some feature contexts, like header compression, this > > > > isn't a problem > > > > because it will re-initialize automatically, but for AAA or QoS it > > > > clearly will be. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 3:00 PM > > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > > to close without any results. People could not agree on the > > > > > reliability needs of CT. We added a reliability mechanism to our > > > > > CT proposal that covered both retransmission and updates. > > > > > > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > > To: Rajeev Koodli > > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Agree. > > > > > > > > > > But I don't see anything in the CT requirements about handling CT > > > > > failure. > > > > > > > > > > ??? > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > Rajeev, > > > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > > notify > > > > the > > > > > MN > > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > > robustness of CT protocol. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "James Kempf" > > > > > > > Cc: "Gary Kenward" ; > > > > > > > ; ; > > > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > > > negotiation > > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > > should > > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > > upstream > > > > > > > signaling) > > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > > > though it > > > > > > > may > > > > > > > > > be useful for finding a new wireless medium. I also see it > > > > > primarily > > > > > > > for > > > > > > > > > intertechnology handover, or, at best, > > > > interprovider handover. > > > > > > > > > > > > > > > > > > jak > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Rajeev Koodli" > > > > > > > > > To: "Gary Kenward" > > > > > > > > > Cc: ; ; > > > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > > may > > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > > establishment > > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > > one of the > > > > > > > > > > parameters that might then be fed to a selection > > > > algorithm. > > > > > Any > > > > > > > > > > signaling for actually establishing QoS itself > > > > beyond the AR > > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > > understand CARD > > > > > (and > > > > > > > > > > > I don't understand it well), it is not a QoS > > negotiation > > > > > > > > > > > protocol. The main application that you are referring > > to > > > > > > > primarily > > > > > > > > > > > arises out of a perceived need to determine at > > > > the MN the > > > > > best > > > > > > > link > > > > > > > > > > > layer to handover over to when inter-technology > > > > handovers > > > > > are > > > > > > > > > > > involved. > > > > > > > > > > > It can be applied to intra-technology handovers, but > > the > > > > > value > > > > > > > in > > > > > > > > > > > that situation is highly questionable (e.g. > > > > since it is a > > > > > > > discovery > > > > > > > > > > > protocol, the implication is that the purpose is to > > > > > determine > > > > > > > the > > > > > > > > > > > choice of channels available; for intra-technology > > > > > handovers, > > > > > > > there > > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > > available). > > > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > > imply NSIS > > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > > this is not > > > > > the > > > > > > > > > > > intention > > > > > > > > > > > (please correct me if I have this wrong John), in > > which > > > > case > > > > > I > > > > > > > think > > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS > > > > for > > > > > an > > > > > > > > > > > existing flow after a handover, or is it > > > > specifically for > > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > > boolean: > > > > the > > > > > > > role > > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > > believe, > > > > and > > > > > > > clearly > > > > > > > > > > > handover is a dynamic situation that could cause the > > QoS > > > > > > > provided to > > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > > frightening > > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > > transfer has > > > > > been > > > > > > > used > > > > > > > > > > > to > > > > > > > > > > > move the QoS context to the new routers (by the > > > > > > > requirements > > > > > > > > > > > for > > > > > > > > > > > CT this could be intra-, or inter- > > > > technology. Some > > > > > of us > > > > > > > > > > > believe > > > > > > > > > > > that for "seamless" handovers, the > > > > context will be > > > > > > > available > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > > forwarded. > > > > > > > This > > > > > > > > > > > implies > > > > > > > > > > > that there is a relationship, probabilistic > > > > perhaps, > > > > > > > between > > > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > > handover > > > > > decision > > > > > > > (it > > > > > > > > > > > is not clear to me how this happens, but it > > seems > > > > > clear > > > > > > > that > > > > > > > > > > > for a more "seamless" handover, the MN > > > > should chose > > > > > an AR > > > > > > > > > that > > > > > > > > > > > has received the appropriate context; if > > > > not, then > > > > > what? > > > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > > QoS because > > > > > of > > > > > > > > > changes > > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > > predictable > > > > > > > > > > > outcomes? > > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > > entities > > > > > > > > > > > associated > > > > > > > > > > > with the three protocols interact before, > > > > during and after > > > > a > > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > > entities, > > > > the > > > > > > > > > > > respective > > > > > > > > > > > wg's could declare the issue out of scope, but this > > > > approach > > > > > > > does > > > > > > > > > not > > > > > > > > > > > sit well with me, for it seems to defer the > > > > problem to the > > > > > > > people > > > > > > > > > who > > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to > > > > > whether > > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > > Seamoby (CAR > > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > > and not NSIS. > > > > > CAR > > > > > > > > > > > > discovery is supposed to identify candidate access > > > > routers > > > > > > > > > > > > for handoff and QoS is an important property for > > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > > be concerned > > > > > with > > > > > > > the > > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > > draft. > > > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > > concerned > > > > > > > > > > > > with activity > > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > nsis mailing list > > > > > > > > > > > > nsis@ietf.org > > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Seamoby mailing 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 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Seamoby mailing 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 Apr 17 15:32: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 PAA03345 for ; Wed, 17 Apr 2002 15:32:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09878; Wed, 17 Apr 2002 15:22:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09844 for ; Wed, 17 Apr 2002 15:22:11 -0400 (EDT) Received: from hotmail.com (f52.law9.hotmail.com [64.4.9.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02793 for ; Wed, 17 Apr 2002 15:22:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 12:21:39 -0700 Received: from 63.78.179.6 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 19:21:39 GMT X-Originating-IP: [63.78.179.6] From: "Govind Krishnamurthi" To: Karim.El-Malki@era.ericsson.se, kempf@docomolabs-usa.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 15:21:39 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 19:21:39.0822 (UTC) FILETIME=[1982D0E0:01C1E645] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim, First, I don't think that Steve Deering said anything about excluding the network from CAR discovery. All he said (AFAIK) was that the MN's preferences must be satisfied in the decision of selecting the TAR. Now that doesn't imply MN based CAR discovery: that the MN should receive all the capabilities and GAAR IDs and then make the decision. Regards, Govind. > >The reason I sent my previous email was that I got the feeling >from this thread that there is focus on providing a solution for >the network-centric case (i.e. the network handles CAR discovery >and the MN isn't involved). I wanted to point out that this >solution would not be applicable to the mobile-centric case and >clarify that this case is supported by MIP (v4 and v6) fast >handoffs. > >From the IETF meeting there was a majority who wanted to go for >the mobile-centric case (i.e. where the mobile is involved and >decides). Following Steve's presentation I think that became >quite clear. So, why are there discussions about doing a solution >which is meant for the network-centric case only? This solution >wouldn't apply to the mobile-centric case. That's what I was meant >to ask in my last email. > >/Karim > > > Karim, > > > > But it is applicable to network initiated handoff. And there are two > > algorithms, one in which the access router sends a PrxyRtAdv > > to the MN > > and one in which the MN is switched (for FMIPv4). > > > > jak > > > > ----- Original Message ----- > > From: "Karim El-Malki (ERA)" > > To: "'James Kempf'" ; "Hemant Chaskar" > > ; > > Sent: Tuesday, April 16, 2002 11:55 AM > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > >[The Issue] > > > > > >It seems that the minutes indicate that people have > > > > somehow come to a > > > > > >conclusion that there is no need for access routers to > > > > divulge that > > > > they > > > > > >are > > > > > >geographically adjancent to themselves via the IP > > > > infrastructure. The > > > > > >minutes also seem to indicate that the mobile alone should be > > the > > > > only way > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > >[Technical Questions] > > > > > >O.K. If this is true then how will a mobile pass this > > > > information to > > > > their > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > only capable > > > > of > > > > > >listening to one media at once? > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > > would > > > > really > > > > > like to understand is whether the above is a relevant case for > > CAR > > > > discovery > > > > > or we simply neglect it and focus only on two > > physical interfaces > > > > case. I > > > > > raised this question before, but we have not had much > > discussion > > on > > > > it. In > > > > > any case, address translation part of CARD will be required in > > this > > > > case for > > > > > fast handoff support. > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > delivers the > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > information is required (by the MIP fast handover algorithms) at > > the > > > > MN's AR. So the issue is fairly simple: the AR must be > > able to do > > > > reverse address translation in order that it can contact the > > > > other AR. > > > > > > This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > > In Mobile-initiated we consider the useful case where the MN can > > recover > > > the CAR IP address/es from the L2 trigger. The MN then > > sends a Proxy > > > Router Solicitation (RtSolPr) to its curent AR containing > > one or more > > CAR > > > IP addresses. This means that the source AR already gets the CAR > > addresses. > > > So we can do without the AR doing translation or discovering > > geographical > > > adjacency. The MN can pass these CAR address/es to the > > source AR for > > both > > > single and multiple-interface MNs. So I think that the > > conclusion from > > the > > > meeting is compatible with MIP Fast Handoffs. > > > > > > /Karim > > > > > > >_______________________________________________ >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 Apr 17 15:32: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 PAA03355 for ; Wed, 17 Apr 2002 15:32:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10997 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 15:32:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09878; Wed, 17 Apr 2002 15:22:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09844 for ; Wed, 17 Apr 2002 15:22:11 -0400 (EDT) Received: from hotmail.com (f52.law9.hotmail.com [64.4.9.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02793 for ; Wed, 17 Apr 2002 15:22:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 12:21:39 -0700 Received: from 63.78.179.6 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 19:21:39 GMT X-Originating-IP: [63.78.179.6] From: "Govind Krishnamurthi" To: Karim.El-Malki@era.ericsson.se, kempf@docomolabs-usa.com, hchaskar@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 17 Apr 2002 15:21:39 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 19:21:39.0822 (UTC) FILETIME=[1982D0E0:01C1E645] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim, First, I don't think that Steve Deering said anything about excluding the network from CAR discovery. All he said (AFAIK) was that the MN's preferences must be satisfied in the decision of selecting the TAR. Now that doesn't imply MN based CAR discovery: that the MN should receive all the capabilities and GAAR IDs and then make the decision. Regards, Govind. > >The reason I sent my previous email was that I got the feeling >from this thread that there is focus on providing a solution for >the network-centric case (i.e. the network handles CAR discovery >and the MN isn't involved). I wanted to point out that this >solution would not be applicable to the mobile-centric case and >clarify that this case is supported by MIP (v4 and v6) fast >handoffs. > >From the IETF meeting there was a majority who wanted to go for >the mobile-centric case (i.e. where the mobile is involved and >decides). Following Steve's presentation I think that became >quite clear. So, why are there discussions about doing a solution >which is meant for the network-centric case only? This solution >wouldn't apply to the mobile-centric case. That's what I was meant >to ask in my last email. > >/Karim > > > Karim, > > > > But it is applicable to network initiated handoff. And there are two > > algorithms, one in which the access router sends a PrxyRtAdv > > to the MN > > and one in which the MN is switched (for FMIPv4). > > > > jak > > > > ----- Original Message ----- > > From: "Karim El-Malki (ERA)" > > To: "'James Kempf'" ; "Hemant Chaskar" > > ; > > Sent: Tuesday, April 16, 2002 11:55 AM > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > >[The Issue] > > > > > >It seems that the minutes indicate that people have > > > > somehow come to a > > > > > >conclusion that there is no need for access routers to > > > > divulge that > > > > they > > > > > >are > > > > > >geographically adjancent to themselves via the IP > > > > infrastructure. The > > > > > >minutes also seem to indicate that the mobile alone should be > > the > > > > only way > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > >[Technical Questions] > > > > > >O.K. If this is true then how will a mobile pass this > > > > information to > > > > their > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > only capable > > > > of > > > > > >listening to one media at once? > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > > would > > > > really > > > > > like to understand is whether the above is a relevant case for > > CAR > > > > discovery > > > > > or we simply neglect it and focus only on two > > physical interfaces > > > > case. I > > > > > raised this question before, but we have not had much > > discussion > > on > > > > it. In > > > > > any case, address translation part of CARD will be required in > > this > > > > case for > > > > > fast handoff support. > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > delivers the > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > information is required (by the MIP fast handover algorithms) at > > the > > > > MN's AR. So the issue is fairly simple: the AR must be > > able to do > > > > reverse address translation in order that it can contact the > > > > other AR. > > > > > > This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > > In Mobile-initiated we consider the useful case where the MN can > > recover > > > the CAR IP address/es from the L2 trigger. The MN then > > sends a Proxy > > > Router Solicitation (RtSolPr) to its curent AR containing > > one or more > > CAR > > > IP addresses. This means that the source AR already gets the CAR > > addresses. > > > So we can do without the AR doing translation or discovering > > geographical > > > adjacency. The MN can pass these CAR address/es to the > > source AR for > > both > > > single and multiple-interface MNs. So I think that the > > conclusion from > > the > > > meeting is compatible with MIP Fast Handoffs. > > > > > > /Karim > > > > > > >_______________________________________________ >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 Apr 17 17:22: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 RAA08375 for ; Wed, 17 Apr 2002 17:22:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18826; Wed, 17 Apr 2002 17:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18789 for ; Wed, 17 Apr 2002 17:09:52 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08112 for ; Wed, 17 Apr 2002 17:09:48 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3HL9Lx22174 for ; Wed, 17 Apr 2002 16:09:21 -0500 (CDT) Message-ID: <3CBDE497.4000809@alcatel.com> Date: Wed, 17 Apr 2002 16:09:43 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> 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 Eunsoo Shim wrote: >Hi, Karim, > >What kind of L2 triggers provide the IP address(es) of the target >(candidate) access routers? > http://ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt states that the triggers L2-MT and L2-ST and L2-LU have nFA IP address as parameters. Hope this helps. --behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 17 17:22: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 RAA08385 for ; Wed, 17 Apr 2002 17:22:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19282 for seamoby-archive@odin.ietf.org; Wed, 17 Apr 2002 17:22:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18826; Wed, 17 Apr 2002 17:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18789 for ; Wed, 17 Apr 2002 17:09:52 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08112 for ; Wed, 17 Apr 2002 17:09:48 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3HL9Lx22174 for ; Wed, 17 Apr 2002 16:09:21 -0500 (CDT) Message-ID: <3CBDE497.4000809@alcatel.com> Date: Wed, 17 Apr 2002 16:09:43 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> 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 Eunsoo Shim wrote: >Hi, Karim, > >What kind of L2 triggers provide the IP address(es) of the target >(candidate) access routers? > http://ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt states that the triggers L2-MT and L2-ST and L2-LU have nFA IP address as parameters. Hope this helps. --behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 18 01:21: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 BAA18006 for ; Thu, 18 Apr 2002 01:21:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15819; Thu, 18 Apr 2002 01:08:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15764 for ; Thu, 18 Apr 2002 01:08:21 -0400 (EDT) Received: from hotmail.com (oe22.law4.hotmail.com [216.33.148.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17838 for ; Thu, 18 Apr 2002 01:08:18 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 22:07:50 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "Behcet Sarikaya" , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <3CBDE497.4000809@alcatel.com> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 14:12:54 -0700 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: 18 Apr 2002 05:07:50.0529 (UTC) FILETIME=[FCE2CF10:01C1E696] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Behcet, Thanks for the information. My understanding is that the low latency handoff proposal ASSUMES or REQUIRES that such L2 triggers are available. Then the question would be how such L2 triggers containing the IP address of the nFA could be generated. I don't think we have a general solution for the problem yet. So I don't think we can say "Look! we have L2 triggers that provide the IP address of the target access router." yet. I understand the need to design a way to get L2 ID to IP address mapping was one of the major motivations for the CAR discovery protocol while we know that the MN can get the L2 ID of the new base station from the L2 beacons. Actually the CAR discovery protocol could be used to construct the L2 trigger message required/assumed in the draft. Regards, Eunsoo ----- Original Message ----- From: "Behcet Sarikaya" To: Sent: Wednesday, April 17, 2002 2:09 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > Eunsoo Shim wrote: > > >Hi, Karim, > > > >What kind of L2 triggers provide the IP address(es) of the target > >(candidate) access routers? > > > http://ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-0 3.txt > states that the triggers L2-MT and L2-ST and L2-LU have nFA IP address > as parameters. > Hope this helps. > > --behcet > > > > > _______________________________________________ > Seamoby mailing 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 Apr 18 01:21: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 BAA18016 for ; Thu, 18 Apr 2002 01:21:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA23997 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 01:21:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15819; Thu, 18 Apr 2002 01:08:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15764 for ; Thu, 18 Apr 2002 01:08:21 -0400 (EDT) Received: from hotmail.com (oe22.law4.hotmail.com [216.33.148.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17838 for ; Thu, 18 Apr 2002 01:08:18 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 22:07:50 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "Behcet Sarikaya" , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <3CBDE497.4000809@alcatel.com> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 14:12:54 -0700 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: 18 Apr 2002 05:07:50.0529 (UTC) FILETIME=[FCE2CF10:01C1E696] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Behcet, Thanks for the information. My understanding is that the low latency handoff proposal ASSUMES or REQUIRES that such L2 triggers are available. Then the question would be how such L2 triggers containing the IP address of the nFA could be generated. I don't think we have a general solution for the problem yet. So I don't think we can say "Look! we have L2 triggers that provide the IP address of the target access router." yet. I understand the need to design a way to get L2 ID to IP address mapping was one of the major motivations for the CAR discovery protocol while we know that the MN can get the L2 ID of the new base station from the L2 beacons. Actually the CAR discovery protocol could be used to construct the L2 trigger message required/assumed in the draft. Regards, Eunsoo ----- Original Message ----- From: "Behcet Sarikaya" To: Sent: Wednesday, April 17, 2002 2:09 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > Eunsoo Shim wrote: > > >Hi, Karim, > > > >What kind of L2 triggers provide the IP address(es) of the target > >(candidate) access routers? > > > http://ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-0 3.txt > states that the triggers L2-MT and L2-ST and L2-LU have nFA IP address > as parameters. > Hope this helps. > > --behcet > > > > > _______________________________________________ > Seamoby mailing 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 Apr 18 10:26: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 KAA07907 for ; Thu, 18 Apr 2002 10:26:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29175; Thu, 18 Apr 2002 10:15:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29110 for ; Thu, 18 Apr 2002 10:15:17 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07122 for ; Thu, 18 Apr 2002 10:15:12 -0400 (EDT) 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 g3IEFC3G003766 for ; Thu, 18 Apr 2002 16:15:12 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 18 16:10:41 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTP2KD>; Thu, 18 Apr 2002 16:10:41 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> From: "Karim El-Malki (ERA)" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 16:08:39 +0200 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 Since a couple of emails disagreed with me about this point, I'm sending one email reply to clarify. As in the minutes, the concept was that the only entity which can find out all the possible CARs is the MN (that's what I mean by mobile-centric). The network could give hints, but it is the MN that has the complete view and decides. That's what I understood from the meeting and there seemed to be consensus on this. Hope we agree so far. The network could assist in CAR discovery (e.g. it's L2 can help in anticipating the movement). That's also somewhere in the minutes. In fact what I said below was that I couldn't understand why there was focus on a network-centric solution (i.e. where the MN is NOT involved). I wasn't ruling out network involvement, but I couldn't understand why there was work on ARs only doing CAR discovery. Hope my point is more clear now. Maybe I misinterpreted some emails and people are in agreement with this. I think Dirk's email at least was in line with what I have above (i.e. we need to focus on the MN's role and allow the network to assist where needed). Rgds /Karim > -----Original Message----- > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > Sent: den 17 april 2002 21:22 > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > hchaskar@hotmail.com; seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > Hello Karim, > First, I don't think that Steve Deering said anything about excluding > the network from CAR discovery. All he said (AFAIK) was that the MN's > preferences must be satisfied in the decision of selecting the TAR. > Now that doesn't imply MN based CAR discovery: that the MN > should receive > all the capabilities and GAAR IDs and then make the decision. > > > Regards, > Govind. > > > > >The reason I sent my previous email was that I got the feeling > >from this thread that there is focus on providing a solution for > >the network-centric case (i.e. the network handles CAR discovery > >and the MN isn't involved). I wanted to point out that this > >solution would not be applicable to the mobile-centric case and > >clarify that this case is supported by MIP (v4 and v6) fast > >handoffs. > > > >From the IETF meeting there was a majority who wanted to go for > >the mobile-centric case (i.e. where the mobile is involved and > >decides). Following Steve's presentation I think that became > >quite clear. So, why are there discussions about doing a solution > >which is meant for the network-centric case only? This solution > >wouldn't apply to the mobile-centric case. That's what I was meant > >to ask in my last email. > > > >/Karim > > > > > Karim, > > > > > > But it is applicable to network initiated handoff. And > there are two > > > algorithms, one in which the access router sends a PrxyRtAdv > > > to the MN > > > and one in which the MN is switched (for FMIPv4). > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Karim El-Malki (ERA)" > > > To: "'James Kempf'" ; "Hemant Chaskar" > > > ; > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > >[The Issue] > > > > > > >It seems that the minutes indicate that people have > > > > > somehow come to a > > > > > > >conclusion that there is no need for access routers to > > > > > divulge that > > > > > they > > > > > > >are > > > > > > >geographically adjancent to themselves via the IP > > > > > infrastructure. The > > > > > > >minutes also seem to indicate that the mobile > alone should be > > > the > > > > > only way > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > >[Technical Questions] > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > information to > > > > > their > > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > > only capable > > > > > of > > > > > > >listening to one media at once? > > > > > > > > > > > > [HC] I agree that this is a genuine technical > problem. What I > > > would > > > > > really > > > > > > like to understand is whether the above is a > relevant case for > > > CAR > > > > > discovery > > > > > > or we simply neglect it and focus only on two > > > physical interfaces > > > > > case. I > > > > > > raised this question before, but we have not had much > > > discussion > > > on > > > > > it. In > > > > > > any case, address translation part of CARD will > be required in > > > this > > > > > case for > > > > > > fast handoff support. > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > delivers the > > > > > AP or AR L2 identifier to which the MN will be > handed over. This > > > > > information is required (by the MIP fast handover > algorithms) at > > > the > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > able to do > > > > > reverse address translation in order that it can > contact the > > > > > other AR. > > > > > > > > This is not really applicable to Mobile-Initiated MIP > Fast Handoff. > > > > In Mobile-initiated we consider the useful case where > the MN can > > > recover > > > > the CAR IP address/es from the L2 trigger. The MN then > > > sends a Proxy > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > one or more > > > CAR > > > > IP addresses. This means that the source AR already > gets the CAR > > > addresses. > > > > So we can do without the AR doing translation or discovering > > > geographical > > > > adjacency. The MN can pass these CAR address/es to the > > > source AR for > > > both > > > > single and multiple-interface MNs. So I think that the > > > conclusion from > > > the > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > /Karim > > > > > > > > > > >_______________________________________________ > >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 Thu Apr 18 10:26: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 KAA07920 for ; Thu, 18 Apr 2002 10:26:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00024 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 10:26:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29175; Thu, 18 Apr 2002 10:15:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29110 for ; Thu, 18 Apr 2002 10:15:17 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07122 for ; Thu, 18 Apr 2002 10:15:12 -0400 (EDT) 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 g3IEFC3G003766 for ; Thu, 18 Apr 2002 16:15:12 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 18 16:10:41 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTP2KD>; Thu, 18 Apr 2002 16:10:41 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> From: "Karim El-Malki (ERA)" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 16:08:39 +0200 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 Since a couple of emails disagreed with me about this point, I'm sending one email reply to clarify. As in the minutes, the concept was that the only entity which can find out all the possible CARs is the MN (that's what I mean by mobile-centric). The network could give hints, but it is the MN that has the complete view and decides. That's what I understood from the meeting and there seemed to be consensus on this. Hope we agree so far. The network could assist in CAR discovery (e.g. it's L2 can help in anticipating the movement). That's also somewhere in the minutes. In fact what I said below was that I couldn't understand why there was focus on a network-centric solution (i.e. where the MN is NOT involved). I wasn't ruling out network involvement, but I couldn't understand why there was work on ARs only doing CAR discovery. Hope my point is more clear now. Maybe I misinterpreted some emails and people are in agreement with this. I think Dirk's email at least was in line with what I have above (i.e. we need to focus on the MN's role and allow the network to assist where needed). Rgds /Karim > -----Original Message----- > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > Sent: den 17 april 2002 21:22 > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > hchaskar@hotmail.com; seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > Hello Karim, > First, I don't think that Steve Deering said anything about excluding > the network from CAR discovery. All he said (AFAIK) was that the MN's > preferences must be satisfied in the decision of selecting the TAR. > Now that doesn't imply MN based CAR discovery: that the MN > should receive > all the capabilities and GAAR IDs and then make the decision. > > > Regards, > Govind. > > > > >The reason I sent my previous email was that I got the feeling > >from this thread that there is focus on providing a solution for > >the network-centric case (i.e. the network handles CAR discovery > >and the MN isn't involved). I wanted to point out that this > >solution would not be applicable to the mobile-centric case and > >clarify that this case is supported by MIP (v4 and v6) fast > >handoffs. > > > >From the IETF meeting there was a majority who wanted to go for > >the mobile-centric case (i.e. where the mobile is involved and > >decides). Following Steve's presentation I think that became > >quite clear. So, why are there discussions about doing a solution > >which is meant for the network-centric case only? This solution > >wouldn't apply to the mobile-centric case. That's what I was meant > >to ask in my last email. > > > >/Karim > > > > > Karim, > > > > > > But it is applicable to network initiated handoff. And > there are two > > > algorithms, one in which the access router sends a PrxyRtAdv > > > to the MN > > > and one in which the MN is switched (for FMIPv4). > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Karim El-Malki (ERA)" > > > To: "'James Kempf'" ; "Hemant Chaskar" > > > ; > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > >[The Issue] > > > > > > >It seems that the minutes indicate that people have > > > > > somehow come to a > > > > > > >conclusion that there is no need for access routers to > > > > > divulge that > > > > > they > > > > > > >are > > > > > > >geographically adjancent to themselves via the IP > > > > > infrastructure. The > > > > > > >minutes also seem to indicate that the mobile > alone should be > > > the > > > > > only way > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > >[Technical Questions] > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > information to > > > > > their > > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > > only capable > > > > > of > > > > > > >listening to one media at once? > > > > > > > > > > > > [HC] I agree that this is a genuine technical > problem. What I > > > would > > > > > really > > > > > > like to understand is whether the above is a > relevant case for > > > CAR > > > > > discovery > > > > > > or we simply neglect it and focus only on two > > > physical interfaces > > > > > case. I > > > > > > raised this question before, but we have not had much > > > discussion > > > on > > > > > it. In > > > > > > any case, address translation part of CARD will > be required in > > > this > > > > > case for > > > > > > fast handoff support. > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > delivers the > > > > > AP or AR L2 identifier to which the MN will be > handed over. This > > > > > information is required (by the MIP fast handover > algorithms) at > > > the > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > able to do > > > > > reverse address translation in order that it can > contact the > > > > > other AR. > > > > > > > > This is not really applicable to Mobile-Initiated MIP > Fast Handoff. > > > > In Mobile-initiated we consider the useful case where > the MN can > > > recover > > > > the CAR IP address/es from the L2 trigger. The MN then > > > sends a Proxy > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > one or more > > > CAR > > > > IP addresses. This means that the source AR already > gets the CAR > > > addresses. > > > > So we can do without the AR doing translation or discovering > > > geographical > > > > adjacency. The MN can pass these CAR address/es to the > > > source AR for > > > both > > > > single and multiple-interface MNs. So I think that the > > > conclusion from > > > the > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > /Karim > > > > > > > > > > >_______________________________________________ > >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 Thu Apr 18 11:13: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 LAA09788 for ; Thu, 18 Apr 2002 11:13:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02557; Thu, 18 Apr 2002 10:58:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02530 for ; Thu, 18 Apr 2002 10:58:56 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09288 for ; Thu, 18 Apr 2002 10:58:52 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IEwPx22591 for ; Thu, 18 Apr 2002 09:58:25 -0500 (CDT) Message-ID: <3CBEDF29.2050707@alcatel.com> Date: Thu, 18 Apr 2002 09:58:49 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> 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 Karim et al., It seems to me that what Karim is arguing is MIPv4/v6 fast handover drafts do provide a solution to CARD. And he is saying that these are MN centric solutions and bode well with Steve's arguments and the end-to-end arguments in system design first presented by Saltzer, Reed and Clark in as early as 1984. Maybe the question is what business Seamoby has here? Regards, Karim El-Malki (ERA) wrote: >Since a couple of emails disagreed with me about this point, >I'm sending one email reply to clarify. As in the minutes, >the concept was that the only entity which can find out >all the possible CARs is the MN (that's what I mean by mobile-centric). >The network could give hints, but it is the MN that has the complete >view and decides. That's what I understood from the meeting and there >seemed to be consensus on this. Hope we agree so far. The network >could assist in CAR discovery (e.g. it's L2 can help in anticipating >the movement). That's also somewhere in the minutes. In fact what I >said below was that I couldn't understand why there was focus on a >network-centric solution (i.e. where the MN is NOT involved). I wasn't >ruling out network involvement, but I couldn't understand why there >was work on ARs only doing CAR discovery. Hope my point is more clear >now. Maybe I misinterpreted some emails and people are in agreement >with this. I think Dirk's email at least was in line with what I >have above (i.e. we need to focus on the MN's role and allow the >network to assist where needed). >Rgds >/Karim > > > -----Original Message----- > > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > > Sent: den 17 april 2002 21:22 > > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > > hchaskar@hotmail.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > Hello Karim, > > First, I don't think that Steve Deering said anything about excluding > > the network from CAR discovery. All he said (AFAIK) was that the MN's > > preferences must be satisfied in the decision of selecting the TAR. > > Now that doesn't imply MN based CAR discovery: that the MN > > should receive > > all the capabilities and GAAR IDs and then make the decision. > > > > > > Regards, > > Govind. > > > > > > > >The reason I sent my previous email was that I got the feeling > > >from this thread that there is focus on providing a solution for > > >the network-centric case (i.e. the network handles CAR discovery > > >and the MN isn't involved). I wanted to point out that this > > >solution would not be applicable to the mobile-centric case and > > >clarify that this case is supported by MIP (v4 and v6) fast > > >handoffs. > > > > > >From the IETF meeting there was a majority who wanted to go for > > >the mobile-centric case (i.e. where the mobile is involved and > > >decides). Following Steve's presentation I think that became > > >quite clear. So, why are there discussions about doing a solution > > >which is meant for the network-centric case only? This solution > > >wouldn't apply to the mobile-centric case. That's what I was meant > > >to ask in my last email. > > > > > >/Karim > > > > > > > Karim, > > > > > > > > But it is applicable to network initiated handoff. And > > there are two > > > > algorithms, one in which the access router sends a PrxyRtAdv > > > > to the MN > > > > and one in which the MN is switched (for FMIPv4). > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Karim El-Malki (ERA)" > > > > To: "'James Kempf'" ; "Hemant Chaskar" > > > > ; > > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have > > > > > > somehow come to a > > > > > > > >conclusion that there is no need for access routers to > > > > > > divulge that > > > > > > they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > > > > > > infrastructure. The > > > > > > > >minutes also seem to indicate that the mobile > > alone should be > > > > the > > > > > > only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > > information to > > > > > > their > > > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > > > only capable > > > > > > of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical > > problem. What I > > > > would > > > > > > really > > > > > > > like to understand is whether the above is a > > relevant case for > > > > CAR > > > > > > discovery > > > > > > > or we simply neglect it and focus only on two > > > > physical interfaces > > > > > > case. I > > > > > > > raised this question before, but we have not had much > > > > discussion > > > > on > > > > > > it. In > > > > > > > any case, address translation part of CARD will > > be required in > > > > this > > > > > > case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > > delivers the > > > > > > AP or AR L2 identifier to which the MN will be > > handed over. This > > > > > > information is required (by the MIP fast handover > > algorithms) at > > > > the > > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > > able to do > > > > > > reverse address translation in order that it can > > contact the > > > > > > other AR. > > > > > > > > > > This is not really applicable to Mobile-Initiated MIP > > Fast Handoff. > > > > > In Mobile-initiated we consider the useful case where > > the MN can > > > > recover > > > > > the CAR IP address/es from the L2 trigger. The MN then > > > > sends a Proxy > > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > > one or more > > > > CAR > > > > > IP addresses. This means that the source AR already > > gets the CAR > > > > addresses. > > > > > So we can do without the AR doing translation or discovering > > > > geographical > > > > > adjacency. The MN can pass these CAR address/es to the > > > > source AR for > > > > both > > > > > single and multiple-interface MNs. So I think that the > > > > conclusion from > > > > the > > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > > > /Karim > > > > > > > > > > > > > > >_______________________________________________ > > >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 > --behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 18 11:25: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 LAA10447 for ; Thu, 18 Apr 2002 11:25:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04261; Thu, 18 Apr 2002 11:19:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04193 for ; Thu, 18 Apr 2002 11:19:18 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10096 for ; Thu, 18 Apr 2002 11:19:12 -0400 (EDT) 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 g3IFIiA20302 for ; Thu, 18 Apr 2002 11:18:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 11:18:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A48@zcard031.ca.nortel.com> From: "Gary Kenward" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 11:18:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E6EC.53E49848" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E6EC.53E49848 Content-Type: text/plain; charset="ISO-8859-1" My observation on this MN centric approach is that, to me, there are logical flaws. Let me present these flaws in two cases; I will refer to the "old and candidate" networks, meaning the network that was supporting the MN, and a network that is a possible candidate network for handover of the MN's traffic. Each has an AR, AP, etc. 1. The old and candidate networks have an interworking capability: in this case, the networks have a more complete, and current view of the services available before and after handover. The proposal is to use CAR to ship information describing this view to the MN. At best, this implies using wireless bandwidth, and MN CPU cycles and battery power to make a decision that can be made by two networks that have relatively unlimited link bandwidth, CPU cycles, and power. Note that if the two networks are under the same administration, it would seem reasonable to assume that the networks are deployed with some sort of interworking capability. 2. The old and candidate networks have no interworking capability, e.g. they know nothing of each other. In this opposite extreme, the primary model is essentially one of an IP service running over two wireless access networks. Since, by definition, the MN is the main common element between the two networks, it would appear to make sense to have it make the handover decision. There are then three alternatives to how the MN can access the information from the candidate network: the candidate network broadcasts capability information "regularly" over the wireless channel; the candidate network responds to all requests for capability information; and, the candidate network responds to authorized requests from a specific MN (implying that the MN is authenticated). Now, at this point, I will assume that each network has an operator that wishes to recover his/her investment in spectrum, equipment, backhaul links, operating costs, etc. In a commercial operation, it is reasonable to assume competition: what operator would be willing to promiscuously broadcast capability information about their network that could be used by a competitor to lure away customers? Wireline network operators are leery of exposing any information that might identify their network topology or how it operates, and so why would a wireless operator be different? So, this implies that the MN must establish a link with the candidate network, be authenticated and authorized to receive capability information. A lot has to happen before IP packets can be exchanged (CAR is an L3 solution), and, in order for capability discovery to be useful, the MN must be in communication with at least two candidate networks. If the MN is assumed to have single channel, multi-mode NICs, this discovery process has to occur sequentially - the equivalent of channel scanning used in FDM wireless systems - which is very difficult to do and provide "seamless" handover, particularly when L2 authentication and L3 capability discovery have to be completed. This leads to the conclusion that the MN has to have multi-channel, multi-mode NICs, which might make the NIC vendors happy, and certainly would make the battery vendors very happy. None of these arguments apply if we are talking about best effort service over an "open" access network. To me, the idea of must be open and non-commercial access networks outside of select government/academic networks is unrealistic. It is arguable that that access to the Internet today is predominately commercial. The bottom line is that there are significantly greater resources within the network to perform these functions, and the communications between networks are relatively (note, I said "relatively") easier to make secure. Why does this matter? If Seamoby develops both solutions, then won't the marketplace determine what makes sense or not? Perhaps, but this approach makes sense only if there is no cost to defining a one-size-fits-all solution. I would prefer that the effort be focussed on inter-AR capability discovery, including internetwork capability discovery. Just more of my delusional thoughts, Gary > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: April 18, 2002 10:09 > To: seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > Since a couple of emails disagreed with me about this point, > I'm sending one email reply to clarify. As in the minutes, > the concept was that the only entity which can find out > all the possible CARs is the MN (that's what I mean by > mobile-centric). > The network could give hints, but it is the MN that has the complete > view and decides. That's what I understood from the meeting and there > seemed to be consensus on this. Hope we agree so far. The network > could assist in CAR discovery (e.g. it's L2 can help in anticipating > the movement). That's also somewhere in the minutes. In fact what I > said below was that I couldn't understand why there was focus on a > network-centric solution (i.e. where the MN is NOT involved). I wasn't > ruling out network involvement, but I couldn't understand why there > was work on ARs only doing CAR discovery. Hope my point is more clear > now. Maybe I misinterpreted some emails and people are in agreement > with this. I think Dirk's email at least was in line with what I > have above (i.e. we need to focus on the MN's role and allow the > network to assist where needed). > Rgds > /Karim > > > -----Original Message----- > > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > > Sent: den 17 april 2002 21:22 > > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > > hchaskar@hotmail.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > Hello Karim, > > First, I don't think that Steve Deering said anything > about excluding > > the network from CAR discovery. All he said (AFAIK) was > that the MN's > > preferences must be satisfied in the decision of selecting the TAR. > > Now that doesn't imply MN based CAR discovery: that the MN > > should receive > > all the capabilities and GAAR IDs and then make the decision. > > > > > > Regards, > > Govind. > > > > > > > >The reason I sent my previous email was that I got the feeling > > >from this thread that there is focus on providing a solution for > > >the network-centric case (i.e. the network handles CAR discovery > > >and the MN isn't involved). I wanted to point out that this > > >solution would not be applicable to the mobile-centric case and > > >clarify that this case is supported by MIP (v4 and v6) fast > > >handoffs. > > > > > >From the IETF meeting there was a majority who wanted to go for > > >the mobile-centric case (i.e. where the mobile is involved and > > >decides). Following Steve's presentation I think that became > > >quite clear. So, why are there discussions about doing a solution > > >which is meant for the network-centric case only? This solution > > >wouldn't apply to the mobile-centric case. That's what I was meant > > >to ask in my last email. > > > > > >/Karim > > > > > > > Karim, > > > > > > > > But it is applicable to network initiated handoff. And > > there are two > > > > algorithms, one in which the access router sends a PrxyRtAdv > > > > to the MN > > > > and one in which the MN is switched (for FMIPv4). > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Karim El-Malki (ERA)" > > > > To: "'James Kempf'" ; > "Hemant Chaskar" > > > > ; > > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have > > > > > > somehow come to a > > > > > > > >conclusion that there is no need for access routers to > > > > > > divulge that > > > > > > they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > > > > > > infrastructure. The > > > > > > > >minutes also seem to indicate that the mobile > > alone should be > > > > the > > > > > > only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > > information to > > > > > > their > > > > > > > >source AR if the mobile only has one NIC and > that NIC is > > > > > > only capable > > > > > > of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical > > problem. What I > > > > would > > > > > > really > > > > > > > like to understand is whether the above is a > > relevant case for > > > > CAR > > > > > > discovery > > > > > > > or we simply neglect it and focus only on two > > > > physical interfaces > > > > > > case. I > > > > > > > raised this question before, but we have not had much > > > > discussion > > > > on > > > > > > it. In > > > > > > > any case, address translation part of CARD will > > be required in > > > > this > > > > > > case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 > typically > > > > > > delivers the > > > > > > AP or AR L2 identifier to which the MN will be > > handed over. This > > > > > > information is required (by the MIP fast handover > > algorithms) at > > > > the > > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > > able to do > > > > > > reverse address translation in order that it can > > contact the > > > > > > other AR. > > > > > > > > > > This is not really applicable to Mobile-Initiated MIP > > Fast Handoff. > > > > > In Mobile-initiated we consider the useful case where > > the MN can > > > > recover > > > > > the CAR IP address/es from the L2 trigger. The MN then > > > > sends a Proxy > > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > > one or more > > > > CAR > > > > > IP addresses. This means that the source AR already > > gets the CAR > > > > addresses. > > > > > So we can do without the AR doing translation or discovering > > > > geographical > > > > > adjacency. The MN can pass these CAR address/es to the > > > > source AR for > > > > both > > > > > single and multiple-interface MNs. So I think that the > > > > conclusion from > > > > the > > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > > > /Karim > > > > > > > > > > > > > > >_______________________________________________ > > >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 ------_=_NextPart_001_01C1E6EC.53E49848 Content-Type: text/html; charset="ISO-8859-1" RE: [Seamoby] Minutes for Meeting at IETF 53

My observation on this MN centric approach is that, to me, there
are logical flaws. Let me present these flaws in two cases; I will
refer to the "old and candidate" networks, meaning the network that
was supporting the MN, and a network that is a possible candidate
network for handover of the MN's traffic. Each has an AR, AP, etc.

  1. The old and candidate networks have an interworking capability:
     in this case, the networks have a more complete, and current
     view of the services available before and after handover. The
     proposal is to use CAR to ship information describing this view
     to the MN. At best, this implies using wireless bandwidth, and MN
     CPU cycles and battery power to make a decision that can be made
     by two networks that have relatively unlimited link bandwidth,
     CPU cycles, and power.

     Note that if the two networks are under the same administration,
     it would seem reasonable to assume that the networks are deployed
     with some sort of interworking capability.

  2. The old and candidate networks have no interworking capability,
     e.g. they know nothing of each other. In this opposite extreme,
     the primary model is essentially one of an IP service running
     over two wireless access networks. Since, by definition, the MN
     is the main common element between the two networks, it would
     appear to make sense to have it make the handover decision.

     There are then three alternatives to how the MN can access the
     information from the candidate network: the candidate network
     broadcasts capability information "regularly" over the wireless
     channel; the candidate network responds to all requests for
     capability information; and, the candidate network responds
     to authorized requests from a specific MN (implying that the
     MN is authenticated).

     Now, at this point, I will assume that each network has an
     operator that wishes to recover his/her investment in spectrum,
     equipment, backhaul links, operating costs, etc. In a commercial
     operation, it is reasonable to assume competition: what operator
     would be willing to promiscuously broadcast capability information
     about their network that could be used by a competitor to lure
     away customers? Wireline network operators are leery of exposing
     any information that might identify their network topology or
     how it operates, and so why would a wireless operator be different?

     So, this implies that the MN must establish a link with the candidate
     network, be authenticated and authorized to receive capability
     information. A lot has to happen before IP packets can be exchanged
     (CAR is an L3 solution), and, in order for capability discovery
     to be useful, the MN must be in communication with at least two
     candidate networks. If the MN is assumed to have single channel,
     multi-mode NICs, this discovery process has to occur sequentially
     - the equivalent of channel scanning used in FDM wireless systems
     - which is very difficult to do and provide "seamless" handover,
     particularly when L2 authentication and L3 capability discovery
     have to be completed.

     This leads to the conclusion that the MN has to have multi-channel,
     multi-mode NICs, which might make the NIC vendors happy, and
     certainly would make the battery vendors very happy.

None of these arguments apply if we are talking about best effort service
over an "open" access network. To me, the idea of must be open and non-commercial
access networks outside of select government/academic networks is unrealistic.
It is arguable that that access to the Internet today is predominately
commercial.

The bottom line is that there are significantly greater resources within
the network to perform these functions, and the communications between
networks are relatively (note, I said "relatively") easier to make secure.

Why does this matter? If Seamoby develops both solutions, then won't the
marketplace determine what makes sense or not? Perhaps, but this approach
makes sense only if there is no cost to defining a one-size-fits-all solution.
I would prefer that the effort be focussed on inter-AR capability discovery,
including internetwork capability discovery.

Just more of my delusional thoughts,
Gary

> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se]
> Sent: April 18, 2002 10:09
> To: seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>
>
> Since a couple of emails disagreed with me about this point,
> I'm sending one email reply to clarify. As in the minutes,
> the concept was that the only entity which can find out
> all the possible CARs is the MN (that's what I mean by
> mobile-centric).
> The network could give hints, but it is the MN that has the complete
> view and decides. That's what I understood from the meeting and there
> seemed to be consensus on this. Hope we agree so far. The network
> could assist in CAR discovery (e.g. it's L2 can help in anticipating
> the movement). That's also somewhere in the minutes. In fact what I
> said below was that I couldn't understand why there was focus on a
> network-centric solution (i.e. where the MN is NOT involved). I wasn't
> ruling out network involvement, but I couldn't understand why there
> was work on ARs only doing CAR discovery. Hope my point is more clear
> now. Maybe I misinterpreted some emails and people are in agreement
> with this. I think Dirk's email at least was in line with what I
> have above (i.e. we need to focus on the MN's role and allow the
> network to assist where needed).
> Rgds
> /Karim
>
>  > -----Original Message-----
>  > From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
>  > Sent: den 17 april 2002 21:22
>  > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com;
>  > hchaskar@hotmail.com; seamoby@ietf.org
>  > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>  >
>  >
>  >
>  >
>  >
>  > Hello Karim,
>  > First, I don't think that Steve Deering said anything
> about excluding
>  > the network from CAR discovery. All he said (AFAIK) was
> that the MN's
>  > preferences must be satisfied in the decision of selecting the TAR.
>  > Now that doesn't imply MN based CAR discovery: that the MN
>  > should receive
>  > all the capabilities and GAAR IDs and then make the decision.
>  >
>  >
>  > Regards,
>  > Govind.
>  >
>  > >
>  > >The reason I sent my previous email was that I got the feeling
>  > >from this thread that there is focus on providing a solution for
>  > >the network-centric case (i.e. the network handles CAR discovery
>  > >and the MN isn't involved). I wanted to point out that this
>  > >solution would not be applicable to the mobile-centric case and
>  > >clarify that this case is supported by MIP (v4 and v6) fast
>  > >handoffs.
>  > >
>  > >From the IETF meeting there was a majority who wanted to go for
>  > >the mobile-centric case (i.e. where the mobile is involved and
>  > >decides). Following Steve's presentation I think that became
>  > >quite clear. So, why are there discussions about doing a solution
>  > >which is meant for the network-centric case only? This solution
>  > >wouldn't apply to the mobile-centric case. That's what I was meant
>  > >to ask in my last email.
>  > >
>  > >/Karim
>  > >
>  > >  > Karim,
>  > >  >
>  > >  > But it is applicable to network initiated handoff. And
>  > there are two
>  > >  > algorithms, one in which the access router sends a PrxyRtAdv
>  > >  > to the MN
>  > >  > and one in which the MN is switched (for FMIPv4).
>  > >  >
>  > >  >             jak
>  > >  >
>  > >  > ----- Original Message -----
>  > >  > From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
>  > >  > To: "'James Kempf'" <kempf@docomolabs-usa.com>;
> "Hemant Chaskar"
>  > >  > <hchaskar@hotmail.com>; <seamoby@ietf.org>
>  > >  > Sent: Tuesday, April 16, 2002 11:55 AM
>  > >  > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>  > >  >
>  > >  >
>  > >  > > > > >[The Issue]
>  > >  > >  > > >It seems that the minutes indicate that people have
>  > >  > >  > somehow come to a
>  > >  > >  > > >conclusion that there is no need for access routers to
>  > >  > >  > divulge that
>  > >  > >  > they
>  > >  > >  > > >are
>  > >  > >  > > >geographically adjancent to themselves via the IP
>  > >  > >  > infrastructure. The
>  > >  > >  > > >minutes also seem to indicate that the mobile
>  > alone should be
>  > >  > the
>  > >  > >  > only way
>  > >  > >  > > >to pass addresses of CARs to source ARs.
>  > >  > >  > > >
>  > >  > >  > > >[Technical Questions]
>  > >  > >  > > >O.K. If this is true then how will a mobile pass this
>  > >  > >  > information to
>  > >  > >  > their
>  > >  > >  > > >source AR if the mobile only has one NIC and
> that NIC is
>  > >  > >  > only capable
>  > >  > >  > of
>  > >  > >  > > >listening to one media at once?
>  > >  > >  > >
>  > >  > >  > > [HC] I agree that this is a genuine technical
>  > problem. What I
>  > >  > would
>  > >  > >  > really
>  > >  > >  > > like to understand is whether the above is a
>  > relevant case for
>  > >  > CAR
>  > >  > >  > discovery
>  > >  > >  > > or we simply neglect it and focus only on two
>  > >  > physical interfaces
>  > >  > >  > case. I
>  > >  > >  > > raised this question before, but we have not had much
>  > >  > discussion
>  > >  > on
>  > >  > >  > it. In
>  > >  > >  > > any case, address translation part of CARD will
>  > be required in
>  > >  > this
>  > >  > >  > case for
>  > >  > >  > > fast handoff support.
>  > >  > >  > >
>  > >  > >  >
>  > >  > >  > In a single interface handoff situation, Layer 2
> typically
>  > >  > >  > delivers the
>  > >  > >  > AP or AR L2 identifier to which the MN will be
>  > handed over. This
>  > >  > >  > information is required (by the MIP fast handover
>  > algorithms) at
>  > >  > the
>  > >  > >  > MN's AR. So the issue is fairly simple: the AR must be
>  > >  > able to do
>  > >  > >  > reverse address translation in order that it can
>  > contact the
>  > >  > >  > other AR.
>  > >  > >
>  > >  > > This is not really applicable to Mobile-Initiated MIP
>  > Fast Handoff.
>  > >  > > In Mobile-initiated we consider the useful case where
>  > the MN can
>  > >  > recover
>  > >  > > the CAR IP address/es from the L2 trigger. The MN then
>  > >  > sends a Proxy
>  > >  > > Router Solicitation (RtSolPr) to its curent AR containing
>  > >  > one or more
>  > >  > CAR
>  > >  > > IP addresses. This means that the source AR already
>  > gets the CAR
>  > >  > addresses.
>  > >  > > So we can do without the AR doing translation or discovering
>  > >  > geographical
>  > >  > > adjacency. The MN can pass these CAR address/es to the
>  > >  > source AR for
>  > >  > both
>  > >  > > single and multiple-interface MNs. So I think that the
>  > >  > conclusion from
>  > >  > the
>  > >  > > meeting is compatible with MIP Fast Handoffs.
>  > >  > >
>  > >  > > /Karim
>  > >  > >
>  > >  >
>  > >
>  > >_______________________________________________
>  > >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

------_=_NextPart_001_01C1E6EC.53E49848-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 18 11:25: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 LAA10467 for ; Thu, 18 Apr 2002 11:25:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04757 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 11:25:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04261; Thu, 18 Apr 2002 11:19:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04193 for ; Thu, 18 Apr 2002 11:19:18 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10096 for ; Thu, 18 Apr 2002 11:19:12 -0400 (EDT) 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 g3IFIiA20302 for ; Thu, 18 Apr 2002 11:18:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 11:18:44 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A48@zcard031.ca.nortel.com> From: "Gary Kenward" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 11:18:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E6EC.53E49848" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E6EC.53E49848 Content-Type: text/plain; charset="ISO-8859-1" My observation on this MN centric approach is that, to me, there are logical flaws. Let me present these flaws in two cases; I will refer to the "old and candidate" networks, meaning the network that was supporting the MN, and a network that is a possible candidate network for handover of the MN's traffic. Each has an AR, AP, etc. 1. The old and candidate networks have an interworking capability: in this case, the networks have a more complete, and current view of the services available before and after handover. The proposal is to use CAR to ship information describing this view to the MN. At best, this implies using wireless bandwidth, and MN CPU cycles and battery power to make a decision that can be made by two networks that have relatively unlimited link bandwidth, CPU cycles, and power. Note that if the two networks are under the same administration, it would seem reasonable to assume that the networks are deployed with some sort of interworking capability. 2. The old and candidate networks have no interworking capability, e.g. they know nothing of each other. In this opposite extreme, the primary model is essentially one of an IP service running over two wireless access networks. Since, by definition, the MN is the main common element between the two networks, it would appear to make sense to have it make the handover decision. There are then three alternatives to how the MN can access the information from the candidate network: the candidate network broadcasts capability information "regularly" over the wireless channel; the candidate network responds to all requests for capability information; and, the candidate network responds to authorized requests from a specific MN (implying that the MN is authenticated). Now, at this point, I will assume that each network has an operator that wishes to recover his/her investment in spectrum, equipment, backhaul links, operating costs, etc. In a commercial operation, it is reasonable to assume competition: what operator would be willing to promiscuously broadcast capability information about their network that could be used by a competitor to lure away customers? Wireline network operators are leery of exposing any information that might identify their network topology or how it operates, and so why would a wireless operator be different? So, this implies that the MN must establish a link with the candidate network, be authenticated and authorized to receive capability information. A lot has to happen before IP packets can be exchanged (CAR is an L3 solution), and, in order for capability discovery to be useful, the MN must be in communication with at least two candidate networks. If the MN is assumed to have single channel, multi-mode NICs, this discovery process has to occur sequentially - the equivalent of channel scanning used in FDM wireless systems - which is very difficult to do and provide "seamless" handover, particularly when L2 authentication and L3 capability discovery have to be completed. This leads to the conclusion that the MN has to have multi-channel, multi-mode NICs, which might make the NIC vendors happy, and certainly would make the battery vendors very happy. None of these arguments apply if we are talking about best effort service over an "open" access network. To me, the idea of must be open and non-commercial access networks outside of select government/academic networks is unrealistic. It is arguable that that access to the Internet today is predominately commercial. The bottom line is that there are significantly greater resources within the network to perform these functions, and the communications between networks are relatively (note, I said "relatively") easier to make secure. Why does this matter? If Seamoby develops both solutions, then won't the marketplace determine what makes sense or not? Perhaps, but this approach makes sense only if there is no cost to defining a one-size-fits-all solution. I would prefer that the effort be focussed on inter-AR capability discovery, including internetwork capability discovery. Just more of my delusional thoughts, Gary > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: April 18, 2002 10:09 > To: seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > Since a couple of emails disagreed with me about this point, > I'm sending one email reply to clarify. As in the minutes, > the concept was that the only entity which can find out > all the possible CARs is the MN (that's what I mean by > mobile-centric). > The network could give hints, but it is the MN that has the complete > view and decides. That's what I understood from the meeting and there > seemed to be consensus on this. Hope we agree so far. The network > could assist in CAR discovery (e.g. it's L2 can help in anticipating > the movement). That's also somewhere in the minutes. In fact what I > said below was that I couldn't understand why there was focus on a > network-centric solution (i.e. where the MN is NOT involved). I wasn't > ruling out network involvement, but I couldn't understand why there > was work on ARs only doing CAR discovery. Hope my point is more clear > now. Maybe I misinterpreted some emails and people are in agreement > with this. I think Dirk's email at least was in line with what I > have above (i.e. we need to focus on the MN's role and allow the > network to assist where needed). > Rgds > /Karim > > > -----Original Message----- > > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > > Sent: den 17 april 2002 21:22 > > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > > hchaskar@hotmail.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > Hello Karim, > > First, I don't think that Steve Deering said anything > about excluding > > the network from CAR discovery. All he said (AFAIK) was > that the MN's > > preferences must be satisfied in the decision of selecting the TAR. > > Now that doesn't imply MN based CAR discovery: that the MN > > should receive > > all the capabilities and GAAR IDs and then make the decision. > > > > > > Regards, > > Govind. > > > > > > > >The reason I sent my previous email was that I got the feeling > > >from this thread that there is focus on providing a solution for > > >the network-centric case (i.e. the network handles CAR discovery > > >and the MN isn't involved). I wanted to point out that this > > >solution would not be applicable to the mobile-centric case and > > >clarify that this case is supported by MIP (v4 and v6) fast > > >handoffs. > > > > > >From the IETF meeting there was a majority who wanted to go for > > >the mobile-centric case (i.e. where the mobile is involved and > > >decides). Following Steve's presentation I think that became > > >quite clear. So, why are there discussions about doing a solution > > >which is meant for the network-centric case only? This solution > > >wouldn't apply to the mobile-centric case. That's what I was meant > > >to ask in my last email. > > > > > >/Karim > > > > > > > Karim, > > > > > > > > But it is applicable to network initiated handoff. And > > there are two > > > > algorithms, one in which the access router sends a PrxyRtAdv > > > > to the MN > > > > and one in which the MN is switched (for FMIPv4). > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Karim El-Malki (ERA)" > > > > To: "'James Kempf'" ; > "Hemant Chaskar" > > > > ; > > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have > > > > > > somehow come to a > > > > > > > >conclusion that there is no need for access routers to > > > > > > divulge that > > > > > > they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > > > > > > infrastructure. The > > > > > > > >minutes also seem to indicate that the mobile > > alone should be > > > > the > > > > > > only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > > information to > > > > > > their > > > > > > > >source AR if the mobile only has one NIC and > that NIC is > > > > > > only capable > > > > > > of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical > > problem. What I > > > > would > > > > > > really > > > > > > > like to understand is whether the above is a > > relevant case for > > > > CAR > > > > > > discovery > > > > > > > or we simply neglect it and focus only on two > > > > physical interfaces > > > > > > case. I > > > > > > > raised this question before, but we have not had much > > > > discussion > > > > on > > > > > > it. In > > > > > > > any case, address translation part of CARD will > > be required in > > > > this > > > > > > case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 > typically > > > > > > delivers the > > > > > > AP or AR L2 identifier to which the MN will be > > handed over. This > > > > > > information is required (by the MIP fast handover > > algorithms) at > > > > the > > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > > able to do > > > > > > reverse address translation in order that it can > > contact the > > > > > > other AR. > > > > > > > > > > This is not really applicable to Mobile-Initiated MIP > > Fast Handoff. > > > > > In Mobile-initiated we consider the useful case where > > the MN can > > > > recover > > > > > the CAR IP address/es from the L2 trigger. The MN then > > > > sends a Proxy > > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > > one or more > > > > CAR > > > > > IP addresses. This means that the source AR already > > gets the CAR > > > > addresses. > > > > > So we can do without the AR doing translation or discovering > > > > geographical > > > > > adjacency. The MN can pass these CAR address/es to the > > > > source AR for > > > > both > > > > > single and multiple-interface MNs. So I think that the > > > > conclusion from > > > > the > > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > > > /Karim > > > > > > > > > > > > > > >_______________________________________________ > > >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 ------_=_NextPart_001_01C1E6EC.53E49848 Content-Type: text/html; charset="ISO-8859-1" RE: [Seamoby] Minutes for Meeting at IETF 53

My observation on this MN centric approach is that, to me, there
are logical flaws. Let me present these flaws in two cases; I will
refer to the "old and candidate" networks, meaning the network that
was supporting the MN, and a network that is a possible candidate
network for handover of the MN's traffic. Each has an AR, AP, etc.

  1. The old and candidate networks have an interworking capability:
     in this case, the networks have a more complete, and current
     view of the services available before and after handover. The
     proposal is to use CAR to ship information describing this view
     to the MN. At best, this implies using wireless bandwidth, and MN
     CPU cycles and battery power to make a decision that can be made
     by two networks that have relatively unlimited link bandwidth,
     CPU cycles, and power.

     Note that if the two networks are under the same administration,
     it would seem reasonable to assume that the networks are deployed
     with some sort of interworking capability.

  2. The old and candidate networks have no interworking capability,
     e.g. they know nothing of each other. In this opposite extreme,
     the primary model is essentially one of an IP service running
     over two wireless access networks. Since, by definition, the MN
     is the main common element between the two networks, it would
     appear to make sense to have it make the handover decision.

     There are then three alternatives to how the MN can access the
     information from the candidate network: the candidate network
     broadcasts capability information "regularly" over the wireless
     channel; the candidate network responds to all requests for
     capability information; and, the candidate network responds
     to authorized requests from a specific MN (implying that the
     MN is authenticated).

     Now, at this point, I will assume that each network has an
     operator that wishes to recover his/her investment in spectrum,
     equipment, backhaul links, operating costs, etc. In a commercial
     operation, it is reasonable to assume competition: what operator
     would be willing to promiscuously broadcast capability information
     about their network that could be used by a competitor to lure
     away customers? Wireline network operators are leery of exposing
     any information that might identify their network topology or
     how it operates, and so why would a wireless operator be different?

     So, this implies that the MN must establish a link with the candidate
     network, be authenticated and authorized to receive capability
     information. A lot has to happen before IP packets can be exchanged
     (CAR is an L3 solution), and, in order for capability discovery
     to be useful, the MN must be in communication with at least two
     candidate networks. If the MN is assumed to have single channel,
     multi-mode NICs, this discovery process has to occur sequentially
     - the equivalent of channel scanning used in FDM wireless systems
     - which is very difficult to do and provide "seamless" handover,
     particularly when L2 authentication and L3 capability discovery
     have to be completed.

     This leads to the conclusion that the MN has to have multi-channel,
     multi-mode NICs, which might make the NIC vendors happy, and
     certainly would make the battery vendors very happy.

None of these arguments apply if we are talking about best effort service
over an "open" access network. To me, the idea of must be open and non-commercial
access networks outside of select government/academic networks is unrealistic.
It is arguable that that access to the Internet today is predominately
commercial.

The bottom line is that there are significantly greater resources within
the network to perform these functions, and the communications between
networks are relatively (note, I said "relatively") easier to make secure.

Why does this matter? If Seamoby develops both solutions, then won't the
marketplace determine what makes sense or not? Perhaps, but this approach
makes sense only if there is no cost to defining a one-size-fits-all solution.
I would prefer that the effort be focussed on inter-AR capability discovery,
including internetwork capability discovery.

Just more of my delusional thoughts,
Gary

> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se]
> Sent: April 18, 2002 10:09
> To: seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>
>
> Since a couple of emails disagreed with me about this point,
> I'm sending one email reply to clarify. As in the minutes,
> the concept was that the only entity which can find out
> all the possible CARs is the MN (that's what I mean by
> mobile-centric).
> The network could give hints, but it is the MN that has the complete
> view and decides. That's what I understood from the meeting and there
> seemed to be consensus on this. Hope we agree so far. The network
> could assist in CAR discovery (e.g. it's L2 can help in anticipating
> the movement). That's also somewhere in the minutes. In fact what I
> said below was that I couldn't understand why there was focus on a
> network-centric solution (i.e. where the MN is NOT involved). I wasn't
> ruling out network involvement, but I couldn't understand why there
> was work on ARs only doing CAR discovery. Hope my point is more clear
> now. Maybe I misinterpreted some emails and people are in agreement
> with this. I think Dirk's email at least was in line with what I
> have above (i.e. we need to focus on the MN's role and allow the
> network to assist where needed).
> Rgds
> /Karim
>
>  > -----Original Message-----
>  > From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
>  > Sent: den 17 april 2002 21:22
>  > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com;
>  > hchaskar@hotmail.com; seamoby@ietf.org
>  > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>  >
>  >
>  >
>  >
>  >
>  > Hello Karim,
>  > First, I don't think that Steve Deering said anything
> about excluding
>  > the network from CAR discovery. All he said (AFAIK) was
> that the MN's
>  > preferences must be satisfied in the decision of selecting the TAR.
>  > Now that doesn't imply MN based CAR discovery: that the MN
>  > should receive
>  > all the capabilities and GAAR IDs and then make the decision.
>  >
>  >
>  > Regards,
>  > Govind.
>  >
>  > >
>  > >The reason I sent my previous email was that I got the feeling
>  > >from this thread that there is focus on providing a solution for
>  > >the network-centric case (i.e. the network handles CAR discovery
>  > >and the MN isn't involved). I wanted to point out that this
>  > >solution would not be applicable to the mobile-centric case and
>  > >clarify that this case is supported by MIP (v4 and v6) fast
>  > >handoffs.
>  > >
>  > >From the IETF meeting there was a majority who wanted to go for
>  > >the mobile-centric case (i.e. where the mobile is involved and
>  > >decides). Following Steve's presentation I think that became
>  > >quite clear. So, why are there discussions about doing a solution
>  > >which is meant for the network-centric case only? This solution
>  > >wouldn't apply to the mobile-centric case. That's what I was meant
>  > >to ask in my last email.
>  > >
>  > >/Karim
>  > >
>  > >  > Karim,
>  > >  >
>  > >  > But it is applicable to network initiated handoff. And
>  > there are two
>  > >  > algorithms, one in which the access router sends a PrxyRtAdv
>  > >  > to the MN
>  > >  > and one in which the MN is switched (for FMIPv4).
>  > >  >
>  > >  >             jak
>  > >  >
>  > >  > ----- Original Message -----
>  > >  > From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
>  > >  > To: "'James Kempf'" <kempf@docomolabs-usa.com>;
> "Hemant Chaskar"
>  > >  > <hchaskar@hotmail.com>; <seamoby@ietf.org>
>  > >  > Sent: Tuesday, April 16, 2002 11:55 AM
>  > >  > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>  > >  >
>  > >  >
>  > >  > > > > >[The Issue]
>  > >  > >  > > >It seems that the minutes indicate that people have
>  > >  > >  > somehow come to a
>  > >  > >  > > >conclusion that there is no need for access routers to
>  > >  > >  > divulge that
>  > >  > >  > they
>  > >  > >  > > >are
>  > >  > >  > > >geographically adjancent to themselves via the IP
>  > >  > >  > infrastructure. The
>  > >  > >  > > >minutes also seem to indicate that the mobile
>  > alone should be
>  > >  > the
>  > >  > >  > only way
>  > >  > >  > > >to pass addresses of CARs to source ARs.
>  > >  > >  > > >
>  > >  > >  > > >[Technical Questions]
>  > >  > >  > > >O.K. If this is true then how will a mobile pass this
>  > >  > >  > information to
>  > >  > >  > their
>  > >  > >  > > >source AR if the mobile only has one NIC and
> that NIC is
>  > >  > >  > only capable
>  > >  > >  > of
>  > >  > >  > > >listening to one media at once?
>  > >  > >  > >
>  > >  > >  > > [HC] I agree that this is a genuine technical
>  > problem. What I
>  > >  > would
>  > >  > >  > really
>  > >  > >  > > like to understand is whether the above is a
>  > relevant case for
>  > >  > CAR
>  > >  > >  > discovery
>  > >  > >  > > or we simply neglect it and focus only on two
>  > >  > physical interfaces
>  > >  > >  > case. I
>  > >  > >  > > raised this question before, but we have not had much
>  > >  > discussion
>  > >  > on
>  > >  > >  > it. In
>  > >  > >  > > any case, address translation part of CARD will
>  > be required in
>  > >  > this
>  > >  > >  > case for
>  > >  > >  > > fast handoff support.
>  > >  > >  > >
>  > >  > >  >
>  > >  > >  > In a single interface handoff situation, Layer 2
> typically
>  > >  > >  > delivers the
>  > >  > >  > AP or AR L2 identifier to which the MN will be
>  > handed over. This
>  > >  > >  > information is required (by the MIP fast handover
>  > algorithms) at
>  > >  > the
>  > >  > >  > MN's AR. So the issue is fairly simple: the AR must be
>  > >  > able to do
>  > >  > >  > reverse address translation in order that it can
>  > contact the
>  > >  > >  > other AR.
>  > >  > >
>  > >  > > This is not really applicable to Mobile-Initiated MIP
>  > Fast Handoff.
>  > >  > > In Mobile-initiated we consider the useful case where
>  > the MN can
>  > >  > recover
>  > >  > > the CAR IP address/es from the L2 trigger. The MN then
>  > >  > sends a Proxy
>  > >  > > Router Solicitation (RtSolPr) to its curent AR containing
>  > >  > one or more
>  > >  > CAR
>  > >  > > IP addresses. This means that the source AR already
>  > gets the CAR
>  > >  > addresses.
>  > >  > > So we can do without the AR doing translation or discovering
>  > >  > geographical
>  > >  > > adjacency. The MN can pass these CAR address/es to the
>  > >  > source AR for
>  > >  > both
>  > >  > > single and multiple-interface MNs. So I think that the
>  > >  > conclusion from
>  > >  > the
>  > >  > > meeting is compatible with MIP Fast Handoffs.
>  > >  > >
>  > >  > > /Karim
>  > >  > >
>  > >  >
>  > >
>  > >_______________________________________________
>  > >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

------_=_NextPart_001_01C1E6EC.53E49848-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 18 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 MAA12730 for ; Thu, 18 Apr 2002 12:08:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08542; Thu, 18 Apr 2002 11:56:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08512 for ; Thu, 18 Apr 2002 11:56:10 -0400 (EDT) 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 LAA11907 for ; Thu, 18 Apr 2002 11:56:04 -0400 (EDT) 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 IAA22114; Thu, 18 Apr 2002 08:55:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IFtbH18759; Thu, 18 Apr 2002 08:55:37 -0700 X-mProtect: <200204181555> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCtwfZd; Thu, 18 Apr 2002 08:55:35 PDT Message-ID: <3CBEEC77.3EDB171@iprg.nokia.com> Date: Thu, 18 Apr 2002 08:55:35 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.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 Hello Behcet, Behcet Sarikaya wrote: > > Karim et al., > It seems to me that what Karim is arguing is MIPv4/v6 fast handover > drafts do provide a solution to CARD. That's not what I read, but I'll wait to see what Karim has to say. > And he is saying that these are MN centric solutions and bode well > with Steve's arguments and the end-to-end arguments in system design > first presented by Saltzer, Reed and Clark in as early as 1984. I heard Steve's presentation. I asked a question at the microphone about whether he believed it precluded network-controlled operation. He said it did not, but he wanted to restore mobile nodes to be full citizens (paraphrasing, and it's been a few weeks now). Subsequent discussion seems to be going to extremes, to the point of ignoring obviously reasonable network-constrolled designs for which [seamoby] ought to be responsive. The paper you cite does not preclude such operation. We can view the mobile node as a client which is making use of available service. If the network provides the service, it is free to establish parameters by which it provides the service, and if it is beneficial to have a mobile node move to another point of attachment, I see nothing wrong with notifying the node about that, along with a good candidate for an access router. I don't see any reason why the network should be restricted from using a CAR discovery protoocol to identify such a candidate. > Maybe the question is what business Seamoby has here? My answer would be that [seamoby] ought to be making protocols by which we can expedite smooth handovers. That's a good piece of work, and one for which we can exhibit existence proofs to show that it is possible. I think that so far that there has been trouble to get agreement on "general" goals, but that there are particular instances where the intended results should be obvious. I believe these particular instances include network-controlled and mobile-controlled scenarios. =================================================================== Somewhere else, it was stated that only the mobile node can possibly know all of the CARs. I would amend this to instead say that the mobile node can always know about CARs that are not visible to the network. But, as it turns out, the network can always know CARs that are not visible to the mobile node also. So, we have to allow the mobile node to make the choice, but we should not prevent the mobile node from following network-directives. Thus, we should develop a model by which CAR discovery is allowed to provide input to a network-controlled handover scheme, which is nonetheless subject to possible rejection by the mobile node. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 18 12:08: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 MAA12739 for ; Thu, 18 Apr 2002 12:08:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11472 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 12:08:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08542; Thu, 18 Apr 2002 11:56:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08512 for ; Thu, 18 Apr 2002 11:56:10 -0400 (EDT) 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 LAA11907 for ; Thu, 18 Apr 2002 11:56:04 -0400 (EDT) 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 IAA22114; Thu, 18 Apr 2002 08:55:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IFtbH18759; Thu, 18 Apr 2002 08:55:37 -0700 X-mProtect: <200204181555> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCtwfZd; Thu, 18 Apr 2002 08:55:35 PDT Message-ID: <3CBEEC77.3EDB171@iprg.nokia.com> Date: Thu, 18 Apr 2002 08:55:35 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.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 Hello Behcet, Behcet Sarikaya wrote: > > Karim et al., > It seems to me that what Karim is arguing is MIPv4/v6 fast handover > drafts do provide a solution to CARD. That's not what I read, but I'll wait to see what Karim has to say. > And he is saying that these are MN centric solutions and bode well > with Steve's arguments and the end-to-end arguments in system design > first presented by Saltzer, Reed and Clark in as early as 1984. I heard Steve's presentation. I asked a question at the microphone about whether he believed it precluded network-controlled operation. He said it did not, but he wanted to restore mobile nodes to be full citizens (paraphrasing, and it's been a few weeks now). Subsequent discussion seems to be going to extremes, to the point of ignoring obviously reasonable network-constrolled designs for which [seamoby] ought to be responsive. The paper you cite does not preclude such operation. We can view the mobile node as a client which is making use of available service. If the network provides the service, it is free to establish parameters by which it provides the service, and if it is beneficial to have a mobile node move to another point of attachment, I see nothing wrong with notifying the node about that, along with a good candidate for an access router. I don't see any reason why the network should be restricted from using a CAR discovery protoocol to identify such a candidate. > Maybe the question is what business Seamoby has here? My answer would be that [seamoby] ought to be making protocols by which we can expedite smooth handovers. That's a good piece of work, and one for which we can exhibit existence proofs to show that it is possible. I think that so far that there has been trouble to get agreement on "general" goals, but that there are particular instances where the intended results should be obvious. I believe these particular instances include network-controlled and mobile-controlled scenarios. =================================================================== Somewhere else, it was stated that only the mobile node can possibly know all of the CARs. I would amend this to instead say that the mobile node can always know about CARs that are not visible to the network. But, as it turns out, the network can always know CARs that are not visible to the mobile node also. So, we have to allow the mobile node to make the choice, but we should not prevent the mobile node from following network-directives. Thus, we should develop a model by which CAR discovery is allowed to provide input to a network-controlled handover scheme, which is nonetheless subject to possible rejection by the mobile node. Regards, Charlie P. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 18 12:10: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 LAA09799 for ; Thu, 18 Apr 2002 11:13:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03837 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 11:13:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02557; Thu, 18 Apr 2002 10:58:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02530 for ; Thu, 18 Apr 2002 10:58:56 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09288 for ; Thu, 18 Apr 2002 10:58:52 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IEwPx22591 for ; Thu, 18 Apr 2002 09:58:25 -0500 (CDT) Message-ID: <3CBEDF29.2050707@alcatel.com> Date: Thu, 18 Apr 2002 09:58:49 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> 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 Karim et al., It seems to me that what Karim is arguing is MIPv4/v6 fast handover drafts do provide a solution to CARD. And he is saying that these are MN centric solutions and bode well with Steve's arguments and the end-to-end arguments in system design first presented by Saltzer, Reed and Clark in as early as 1984. Maybe the question is what business Seamoby has here? Regards, Karim El-Malki (ERA) wrote: >Since a couple of emails disagreed with me about this point, >I'm sending one email reply to clarify. As in the minutes, >the concept was that the only entity which can find out >all the possible CARs is the MN (that's what I mean by mobile-centric). >The network could give hints, but it is the MN that has the complete >view and decides. That's what I understood from the meeting and there >seemed to be consensus on this. Hope we agree so far. The network >could assist in CAR discovery (e.g. it's L2 can help in anticipating >the movement). That's also somewhere in the minutes. In fact what I >said below was that I couldn't understand why there was focus on a >network-centric solution (i.e. where the MN is NOT involved). I wasn't >ruling out network involvement, but I couldn't understand why there >was work on ARs only doing CAR discovery. Hope my point is more clear >now. Maybe I misinterpreted some emails and people are in agreement >with this. I think Dirk's email at least was in line with what I >have above (i.e. we need to focus on the MN's role and allow the >network to assist where needed). >Rgds >/Karim > > > -----Original Message----- > > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > > Sent: den 17 april 2002 21:22 > > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > > hchaskar@hotmail.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > Hello Karim, > > First, I don't think that Steve Deering said anything about excluding > > the network from CAR discovery. All he said (AFAIK) was that the MN's > > preferences must be satisfied in the decision of selecting the TAR. > > Now that doesn't imply MN based CAR discovery: that the MN > > should receive > > all the capabilities and GAAR IDs and then make the decision. > > > > > > Regards, > > Govind. > > > > > > > >The reason I sent my previous email was that I got the feeling > > >from this thread that there is focus on providing a solution for > > >the network-centric case (i.e. the network handles CAR discovery > > >and the MN isn't involved). I wanted to point out that this > > >solution would not be applicable to the mobile-centric case and > > >clarify that this case is supported by MIP (v4 and v6) fast > > >handoffs. > > > > > >From the IETF meeting there was a majority who wanted to go for > > >the mobile-centric case (i.e. where the mobile is involved and > > >decides). Following Steve's presentation I think that became > > >quite clear. So, why are there discussions about doing a solution > > >which is meant for the network-centric case only? This solution > > >wouldn't apply to the mobile-centric case. That's what I was meant > > >to ask in my last email. > > > > > >/Karim > > > > > > > Karim, > > > > > > > > But it is applicable to network initiated handoff. And > > there are two > > > > algorithms, one in which the access router sends a PrxyRtAdv > > > > to the MN > > > > and one in which the MN is switched (for FMIPv4). > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Karim El-Malki (ERA)" > > > > To: "'James Kempf'" ; "Hemant Chaskar" > > > > ; > > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have > > > > > > somehow come to a > > > > > > > >conclusion that there is no need for access routers to > > > > > > divulge that > > > > > > they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > > > > > > infrastructure. The > > > > > > > >minutes also seem to indicate that the mobile > > alone should be > > > > the > > > > > > only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > > information to > > > > > > their > > > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > > > only capable > > > > > > of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical > > problem. What I > > > > would > > > > > > really > > > > > > > like to understand is whether the above is a > > relevant case for > > > > CAR > > > > > > discovery > > > > > > > or we simply neglect it and focus only on two > > > > physical interfaces > > > > > > case. I > > > > > > > raised this question before, but we have not had much > > > > discussion > > > > on > > > > > > it. In > > > > > > > any case, address translation part of CARD will > > be required in > > > > this > > > > > > case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > > delivers the > > > > > > AP or AR L2 identifier to which the MN will be > > handed over. This > > > > > > information is required (by the MIP fast handover > > algorithms) at > > > > the > > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > > able to do > > > > > > reverse address translation in order that it can > > contact the > > > > > > other AR. > > > > > > > > > > This is not really applicable to Mobile-Initiated MIP > > Fast Handoff. > > > > > In Mobile-initiated we consider the useful case where > > the MN can > > > > recover > > > > > the CAR IP address/es from the L2 trigger. The MN then > > > > sends a Proxy > > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > > one or more > > > > CAR > > > > > IP addresses. This means that the source AR already > > gets the CAR > > > > addresses. > > > > > So we can do without the AR doing translation or discovering > > > > geographical > > > > > adjacency. The MN can pass these CAR address/es to the > > > > source AR for > > > > both > > > > > single and multiple-interface MNs. So I think that the > > > > conclusion from > > > > the > > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > > > /Karim > > > > > > > > > > > > > > >_______________________________________________ > > >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 > --behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 18 12:37: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 MAA13844 for ; Thu, 18 Apr 2002 12:37:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12927; Thu, 18 Apr 2002 12:26:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12900 for ; Thu, 18 Apr 2002 12:26:47 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13505 for ; Thu, 18 Apr 2002 12:26:41 -0400 (EDT) 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 g3IGQDA28399 for ; Thu, 18 Apr 2002 12:26:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 12:26:14 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A4A@zcard031.ca.nortel.com> From: "Gary Kenward" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 12:26:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E6F5.AAF3AFBC" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E6F5.AAF3AFBC Content-Type: text/plain; charset="ISO-8859-1" My observation on this MN centric approach is that, to me, there are logical flaws. Let me present these flaws in two cases; I will refer to the "old and candidate" networks, meaning the network that was supporting the MN, and a network that is a possible candidate network for handover of the MN's traffic. Each has an AR, AP, etc. 1. The old and candidate networks have an interworking capability: in this case, the networks have a more complete, and current view of the services available before and after handover. The proposal is to use CAR to ship information describing this view to the MN. At best, this implies using wireless bandwidth, and MN CPU cycles and battery power to make a decision that can be made by two networks that have relatively unlimited link bandwidth, CPU cycles, and power. Note that if the two networks are under the same administration, it would seem reasonable to assume that the networks are deployed with some sort of interworking capability. 2. The old and candidate networks have no interworking capability, e.g. they know nothing of each other. In this opposite extreme, the primary model is essentially one of an IP service running over two wireless access networks. Since, by definition, the MN is the main common element between the two networks, it would appear to make sense to have it make the handover decision. There are then three alternatives to how the MN can access the information from the candidate network: the candidate network broadcasts capability information "regularly" over the wireless channel; the candidate network responds to all requests for capability information; and, the candidate network responds to authorized requests from a specific MN (implying that the MN is authenticated). Now, at this point, I will assume that each network has an operator that wishes to recover his/her investment in spectrum, equipment, backhaul links, operating costs, etc. In a commercial operation, it is reasonable to assume competition: what operator would be willing to promiscuously broadcast capability information about their network that could be used by a competitor to lure away customers? Wireline network operators are leery of exposing any information that might identify their network topology or how it operates, and so why would a wireless operator be different? So, this implies that the MN must establish a link with the candidate network, be authenticated and authorized to receive capability information. A lot has to happen before IP packets can be exchanged (CAR is an L3 solution), and, in order for capability discovery to be useful, the MN must be in communication with at least two candidate networks. If the MN is assumed to have single channel, multi-mode NICs, this discovery process has to occur sequentially - the equivalent of channel scanning used in FDM wireless systems - which is very difficult to do and provide "seamless" handover, particularly when L2 authentication and L3 capability discovery have to be completed. This leads to the conclusion that the MN has to have multi-channel, multi-mode NICs, which might make the NIC vendors happy, and certainly would make the battery vendors very happy. None of these arguments apply if we are talking about best effort service over an "open" access network. To me, the idea of must be open and non-commercial access networks outside of select government/academic networks is unrealistic. It is arguable that that access to the Internet today is predominately commercial. The bottom line is that there are significantly greater resources within the network to perform these functions, and the communications between networks are relatively (note, I said "relatively") easier to make secure. Why does this matter? If Seamoby develops both solutions, then won't the marketplace determine what makes sense or not? Perhaps, but this approach makes sense only if there is no cost to defining a one-size-fits-all solution. I would prefer that the effort be focussed on inter-AR capability discovery, including internetwork capability discovery. Just more of my delusional thoughts, Gary > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: April 18, 2002 10:09 > To: seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > Since a couple of emails disagreed with me about this point, > I'm sending one email reply to clarify. As in the minutes, > the concept was that the only entity which can find out > all the possible CARs is the MN (that's what I mean by > mobile-centric). > The network could give hints, but it is the MN that has the complete > view and decides. That's what I understood from the meeting and there > seemed to be consensus on this. Hope we agree so far. The network > could assist in CAR discovery (e.g. it's L2 can help in anticipating > the movement). That's also somewhere in the minutes. In fact what I > said below was that I couldn't understand why there was focus on a > network-centric solution (i.e. where the MN is NOT involved). I wasn't > ruling out network involvement, but I couldn't understand why there > was work on ARs only doing CAR discovery. Hope my point is more clear > now. Maybe I misinterpreted some emails and people are in agreement > with this. I think Dirk's email at least was in line with what I > have above (i.e. we need to focus on the MN's role and allow the > network to assist where needed). > Rgds > /Karim > *snip* _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C1E6F5.AAF3AFBC Content-Type: text/html; charset="ISO-8859-1" RE: [Seamoby] Minutes for Meeting at IETF 53

My observation on this MN centric approach is that, to me, there
are logical flaws. Let me present these flaws in two cases; I will
refer to the "old and candidate" networks, meaning the network that
was supporting the MN, and a network that is a possible candidate
network for handover of the MN's traffic. Each has an AR, AP, etc.

  1. The old and candidate networks have an interworking capability:
     in this case, the networks have a more complete, and current
     view of the services available before and after handover. The
     proposal is to use CAR to ship information describing this view
     to the MN. At best, this implies using wireless bandwidth, and MN
     CPU cycles and battery power to make a decision that can be made
     by two networks that have relatively unlimited link bandwidth,
     CPU cycles, and power.

     Note that if the two networks are under the same administration,
     it would seem reasonable to assume that the networks are deployed
     with some sort of interworking capability.

  2. The old and candidate networks have no interworking capability,
     e.g. they know nothing of each other. In this opposite extreme,
     the primary model is essentially one of an IP service running
     over two wireless access networks. Since, by definition, the MN
     is the main common element between the two networks, it would
     appear to make sense to have it make the handover decision.

     There are then three alternatives to how the MN can access the
     information from the candidate network: the candidate network
     broadcasts capability information "regularly" over the wireless
     channel; the candidate network responds to all requests for
     capability information; and, the candidate network responds
     to authorized requests from a specific MN (implying that the
     MN is authenticated).

     Now, at this point, I will assume that each network has an
     operator that wishes to recover his/her investment in spectrum,
     equipment, backhaul links, operating costs, etc. In a commercial
     operation, it is reasonable to assume competition: what operator
     would be willing to promiscuously broadcast capability information
     about their network that could be used by a competitor to lure
     away customers? Wireline network operators are leery of exposing
     any information that might identify their network topology or
     how it operates, and so why would a wireless operator be different?

     So, this implies that the MN must establish a link with the candidate
     network, be authenticated and authorized to receive capability
     information. A lot has to happen before IP packets can be exchanged
     (CAR is an L3 solution), and, in order for capability discovery
     to be useful, the MN must be in communication with at least two
     candidate networks. If the MN is assumed to have single channel,
     multi-mode NICs, this discovery process has to occur sequentially
     - the equivalent of channel scanning used in FDM wireless systems
     - which is very difficult to do and provide "seamless" handover,
     particularly when L2 authentication and L3 capability discovery
     have to be completed.

     This leads to the conclusion that the MN has to have multi-channel,
     multi-mode NICs, which might make the NIC vendors happy, and
     certainly would make the battery vendors very happy.

None of these arguments apply if we are talking about best effort service
over an "open" access network. To me, the idea of must be open and non-commercial
access networks outside of select government/academic networks is unrealistic.
It is arguable that that access to the Internet today is predominately
commercial.

The bottom line is that there are significantly greater resources within
the network to perform these functions, and the communications between
networks are relatively (note, I said "relatively") easier to make secure.

Why does this matter? If Seamoby develops both solutions, then won't the
marketplace determine what makes sense or not? Perhaps, but this approach
makes sense only if there is no cost to defining a one-size-fits-all solution.
I would prefer that the effort be focussed on inter-AR capability discovery,
including internetwork capability discovery.

Just more of my delusional thoughts,
Gary

> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se]
> Sent: April 18, 2002 10:09
> To: seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>
>
> Since a couple of emails disagreed with me about this point,
> I'm sending one email reply to clarify. As in the minutes,
> the concept was that the only entity which can find out
> all the possible CARs is the MN (that's what I mean by
> mobile-centric).
> The network could give hints, but it is the MN that has the complete
> view and decides. That's what I understood from the meeting and there
> seemed to be consensus on this. Hope we agree so far. The network
> could assist in CAR discovery (e.g. it's L2 can help in anticipating
> the movement). That's also somewhere in the minutes. In fact what I
> said below was that I couldn't understand why there was focus on a
> network-centric solution (i.e. where the MN is NOT involved). I wasn't
> ruling out network involvement, but I couldn't understand why there
> was work on ARs only doing CAR discovery. Hope my point is more clear
> now. Maybe I misinterpreted some emails and people are in agreement
> with this. I think Dirk's email at least was in line with what I
> have above (i.e. we need to focus on the MN's role and allow the
> network to assist where needed).
> Rgds
> /Karim
>

*snip*

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

------_=_NextPart_001_01C1E6F5.AAF3AFBC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 18 12:37: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 MAA13857 for ; Thu, 18 Apr 2002 12:37:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13937 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 12:37:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12927; Thu, 18 Apr 2002 12:26:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12900 for ; Thu, 18 Apr 2002 12:26:47 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13505 for ; Thu, 18 Apr 2002 12:26:41 -0400 (EDT) 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 g3IGQDA28399 for ; Thu, 18 Apr 2002 12:26:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 12:26:14 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A4A@zcard031.ca.nortel.com> From: "Gary Kenward" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 12:26:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E6F5.AAF3AFBC" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1E6F5.AAF3AFBC Content-Type: text/plain; charset="ISO-8859-1" My observation on this MN centric approach is that, to me, there are logical flaws. Let me present these flaws in two cases; I will refer to the "old and candidate" networks, meaning the network that was supporting the MN, and a network that is a possible candidate network for handover of the MN's traffic. Each has an AR, AP, etc. 1. The old and candidate networks have an interworking capability: in this case, the networks have a more complete, and current view of the services available before and after handover. The proposal is to use CAR to ship information describing this view to the MN. At best, this implies using wireless bandwidth, and MN CPU cycles and battery power to make a decision that can be made by two networks that have relatively unlimited link bandwidth, CPU cycles, and power. Note that if the two networks are under the same administration, it would seem reasonable to assume that the networks are deployed with some sort of interworking capability. 2. The old and candidate networks have no interworking capability, e.g. they know nothing of each other. In this opposite extreme, the primary model is essentially one of an IP service running over two wireless access networks. Since, by definition, the MN is the main common element between the two networks, it would appear to make sense to have it make the handover decision. There are then three alternatives to how the MN can access the information from the candidate network: the candidate network broadcasts capability information "regularly" over the wireless channel; the candidate network responds to all requests for capability information; and, the candidate network responds to authorized requests from a specific MN (implying that the MN is authenticated). Now, at this point, I will assume that each network has an operator that wishes to recover his/her investment in spectrum, equipment, backhaul links, operating costs, etc. In a commercial operation, it is reasonable to assume competition: what operator would be willing to promiscuously broadcast capability information about their network that could be used by a competitor to lure away customers? Wireline network operators are leery of exposing any information that might identify their network topology or how it operates, and so why would a wireless operator be different? So, this implies that the MN must establish a link with the candidate network, be authenticated and authorized to receive capability information. A lot has to happen before IP packets can be exchanged (CAR is an L3 solution), and, in order for capability discovery to be useful, the MN must be in communication with at least two candidate networks. If the MN is assumed to have single channel, multi-mode NICs, this discovery process has to occur sequentially - the equivalent of channel scanning used in FDM wireless systems - which is very difficult to do and provide "seamless" handover, particularly when L2 authentication and L3 capability discovery have to be completed. This leads to the conclusion that the MN has to have multi-channel, multi-mode NICs, which might make the NIC vendors happy, and certainly would make the battery vendors very happy. None of these arguments apply if we are talking about best effort service over an "open" access network. To me, the idea of must be open and non-commercial access networks outside of select government/academic networks is unrealistic. It is arguable that that access to the Internet today is predominately commercial. The bottom line is that there are significantly greater resources within the network to perform these functions, and the communications between networks are relatively (note, I said "relatively") easier to make secure. Why does this matter? If Seamoby develops both solutions, then won't the marketplace determine what makes sense or not? Perhaps, but this approach makes sense only if there is no cost to defining a one-size-fits-all solution. I would prefer that the effort be focussed on inter-AR capability discovery, including internetwork capability discovery. Just more of my delusional thoughts, Gary > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: April 18, 2002 10:09 > To: seamoby@ietf.org > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > Since a couple of emails disagreed with me about this point, > I'm sending one email reply to clarify. As in the minutes, > the concept was that the only entity which can find out > all the possible CARs is the MN (that's what I mean by > mobile-centric). > The network could give hints, but it is the MN that has the complete > view and decides. That's what I understood from the meeting and there > seemed to be consensus on this. Hope we agree so far. The network > could assist in CAR discovery (e.g. it's L2 can help in anticipating > the movement). That's also somewhere in the minutes. In fact what I > said below was that I couldn't understand why there was focus on a > network-centric solution (i.e. where the MN is NOT involved). I wasn't > ruling out network involvement, but I couldn't understand why there > was work on ARs only doing CAR discovery. Hope my point is more clear > now. Maybe I misinterpreted some emails and people are in agreement > with this. I think Dirk's email at least was in line with what I > have above (i.e. we need to focus on the MN's role and allow the > network to assist where needed). > Rgds > /Karim > *snip* _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C1E6F5.AAF3AFBC Content-Type: text/html; charset="ISO-8859-1" RE: [Seamoby] Minutes for Meeting at IETF 53

My observation on this MN centric approach is that, to me, there
are logical flaws. Let me present these flaws in two cases; I will
refer to the "old and candidate" networks, meaning the network that
was supporting the MN, and a network that is a possible candidate
network for handover of the MN's traffic. Each has an AR, AP, etc.

  1. The old and candidate networks have an interworking capability:
     in this case, the networks have a more complete, and current
     view of the services available before and after handover. The
     proposal is to use CAR to ship information describing this view
     to the MN. At best, this implies using wireless bandwidth, and MN
     CPU cycles and battery power to make a decision that can be made
     by two networks that have relatively unlimited link bandwidth,
     CPU cycles, and power.

     Note that if the two networks are under the same administration,
     it would seem reasonable to assume that the networks are deployed
     with some sort of interworking capability.

  2. The old and candidate networks have no interworking capability,
     e.g. they know nothing of each other. In this opposite extreme,
     the primary model is essentially one of an IP service running
     over two wireless access networks. Since, by definition, the MN
     is the main common element between the two networks, it would
     appear to make sense to have it make the handover decision.

     There are then three alternatives to how the MN can access the
     information from the candidate network: the candidate network
     broadcasts capability information "regularly" over the wireless
     channel; the candidate network responds to all requests for
     capability information; and, the candidate network responds
     to authorized requests from a specific MN (implying that the
     MN is authenticated).

     Now, at this point, I will assume that each network has an
     operator that wishes to recover his/her investment in spectrum,
     equipment, backhaul links, operating costs, etc. In a commercial
     operation, it is reasonable to assume competition: what operator
     would be willing to promiscuously broadcast capability information
     about their network that could be used by a competitor to lure
     away customers? Wireline network operators are leery of exposing
     any information that might identify their network topology or
     how it operates, and so why would a wireless operator be different?

     So, this implies that the MN must establish a link with the candidate
     network, be authenticated and authorized to receive capability
     information. A lot has to happen before IP packets can be exchanged
     (CAR is an L3 solution), and, in order for capability discovery
     to be useful, the MN must be in communication with at least two
     candidate networks. If the MN is assumed to have single channel,
     multi-mode NICs, this discovery process has to occur sequentially
     - the equivalent of channel scanning used in FDM wireless systems
     - which is very difficult to do and provide "seamless" handover,
     particularly when L2 authentication and L3 capability discovery
     have to be completed.

     This leads to the conclusion that the MN has to have multi-channel,
     multi-mode NICs, which might make the NIC vendors happy, and
     certainly would make the battery vendors very happy.

None of these arguments apply if we are talking about best effort service
over an "open" access network. To me, the idea of must be open and non-commercial
access networks outside of select government/academic networks is unrealistic.
It is arguable that that access to the Internet today is predominately
commercial.

The bottom line is that there are significantly greater resources within
the network to perform these functions, and the communications between
networks are relatively (note, I said "relatively") easier to make secure.

Why does this matter? If Seamoby develops both solutions, then won't the
marketplace determine what makes sense or not? Perhaps, but this approach
makes sense only if there is no cost to defining a one-size-fits-all solution.
I would prefer that the effort be focussed on inter-AR capability discovery,
including internetwork capability discovery.

Just more of my delusional thoughts,
Gary

> -----Original Message-----
> From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se]
> Sent: April 18, 2002 10:09
> To: seamoby@ietf.org
> Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
>
>
> Since a couple of emails disagreed with me about this point,
> I'm sending one email reply to clarify. As in the minutes,
> the concept was that the only entity which can find out
> all the possible CARs is the MN (that's what I mean by
> mobile-centric).
> The network could give hints, but it is the MN that has the complete
> view and decides. That's what I understood from the meeting and there
> seemed to be consensus on this. Hope we agree so far. The network
> could assist in CAR discovery (e.g. it's L2 can help in anticipating
> the movement). That's also somewhere in the minutes. In fact what I
> said below was that I couldn't understand why there was focus on a
> network-centric solution (i.e. where the MN is NOT involved). I wasn't
> ruling out network involvement, but I couldn't understand why there
> was work on ARs only doing CAR discovery. Hope my point is more clear
> now. Maybe I misinterpreted some emails and people are in agreement
> with this. I think Dirk's email at least was in line with what I
> have above (i.e. we need to focus on the MN's role and allow the
> network to assist where needed).
> Rgds
> /Karim
>

*snip*

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

------_=_NextPart_001_01C1E6F5.AAF3AFBC-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 18 12:43: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 MAA14108 for ; Thu, 18 Apr 2002 12:43:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14095; Thu, 18 Apr 2002 12:41:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14067 for ; Thu, 18 Apr 2002 12:41:17 -0400 (EDT) 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 MAA14030 for ; Thu, 18 Apr 2002 12:41:14 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IGekV03434 for ; Thu, 18 Apr 2002 11:40:46 -0500 (CDT) Message-ID: <3CBEF725.4070906@alcatel.com> Date: Thu, 18 Apr 2002 11:41:09 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.com> <3CBEEC77.3EDB171@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------020200060101070200010202" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------020200060101070200010202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Charlie, Absolutely. What I was pointing out is looking at the history of Seamoby WG, it is keeping to jettison out (as James says) its work items. Maybe Seamoby WG is an incubator of new WGs. So CARD and CT are being incubated and sometime in the future new work items are going to come out with well defined scopes. The discussions here could serve this goal and as such they are probably very useful. This is how I see it. Regards, Charles E. Perkins wrote: >Hello Behcet, > >Behcet Sarikaya wrote: > >>Karim et al., >> It seems to me that what Karim is arguing is MIPv4/v6 fast handover >>drafts do provide a solution to CARD. >> > >That's not what I read, but I'll wait to see what Karim has to say. > >> And he is saying that these are MN centric solutions and bode well >>with Steve's arguments and the end-to-end arguments in system design >>first presented by Saltzer, Reed and Clark in as early as 1984. >> > >I heard Steve's presentation. I asked a question at the microphone >about whether he believed it precluded network-controlled operation. >He said it did not, but he wanted to restore mobile nodes to be >full citizens (paraphrasing, and it's been a few weeks now). >Subsequent discussion seems to be going to extremes, to the point >of ignoring obviously reasonable network-constrolled designs for >which [seamoby] ought to be responsive. > >The paper you cite does not preclude such operation. We can >view the mobile node as a client which is making use of available >service. If the network provides the service, it is free to >establish parameters by which it provides the service, and if >it is beneficial to have a mobile node move to another point of >attachment, I see nothing wrong with notifying the node about >that, along with a good candidate for an access router. I don't >see any reason why the network should be restricted from using >a CAR discovery protoocol to identify such a candidate. > >> Maybe the question is what business Seamoby has here? >> > >My answer would be that [seamoby] ought to be making protocols >by which we can expedite smooth handovers. That's a good piece >of work, and one for which we can exhibit existence proofs to >show that it is possible. I think that so far that there has >been trouble to get agreement on "general" goals, but that there >are particular instances where the intended results should be >obvious. I believe these particular instances include >network-controlled and mobile-controlled scenarios. > >=================================================================== > >Somewhere else, it was stated that only the mobile node can >possibly know all of the CARs. I would amend this to instead >say that the mobile node can always know about CARs that are >not visible to the network. But, as it turns out, the network >can always know CARs that are not visible to the mobile node >also. So, we have to allow the mobile node to make the choice, >but we should not prevent the mobile node from following >network-directives. Thus, we should develop a model by which >CAR discovery is allowed to provide input to a network-controlled >handover scheme, which is nonetheless subject to possible rejection >by the mobile node. > >Regards, >Charlie P. > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > --behcet --------------020200060101070200010202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Charlie,
  Absolutely.
What I was pointing out is looking at the history of Seamoby WG, it is keeping to jettison out (as James says) its work items. Maybe Seamoby WG is an incubator of new WGs.
So CARD and CT are being incubated and sometime in the future new work items are going to come out with  well defined scopes. The discussions here could serve this goal and as such they are probably very useful.
  This is how I see it.

Regards,
Charles E. Perkins wrote:
Hello Behcet,

Behcet Sarikaya wrote:
Karim et al.,
  It seems to me that what Karim is arguing is MIPv4/v6 fast handover
drafts do provide a solution to CARD.

That's not what I read, but I'll wait to see what Karim has to say.

  And he is saying that these are MN centric solutions and bode well
with Steve's arguments and the end-to-end arguments in system design
first presented by Saltzer, Reed and Clark in as early as 1984.

I heard Steve's presentation.  I asked a question at the microphone
about whether he believed it precluded network-controlled operation.
He said it did not, but he wanted to restore mobile nodes to be
full citizens (paraphrasing, and it's been a few weeks now).
Subsequent discussion seems to be going to extremes, to the point
of ignoring obviously reasonable network-constrolled designs for
which [seamoby] ought to be responsive.

The paper you cite does not preclude such operation.  We can
view the mobile node as a client which is making use of available
service.  If the network provides the service, it is free to
establish parameters by which it provides the service, and if
it is beneficial to have a mobile node move to another point of
attachment, I see nothing wrong with notifying the node about
that, along with a good candidate for an access router.  I don't
see any reason why the network should b
e restricted from using
a CAR discovery protoocol to identify such a candidate.

  Maybe the question is what business Seamoby has here?

My answer would be that [seamoby] ought to be making protocols
by which we can expedite smooth handovers.  That's a good piece
of work, and one for which we can exhibit existence proofs to
show that it is possible.  I think that so far that there has
been trouble to get agreement on "general" goals, but that there
are particular instances where the intended results should be
obvious.  I believe these particular instances include
network-controlled and mobile-controlled scenarios.

===================================================================

Somewhere else, it was stated that only the mobile node can
possibly know all of the CARs.  I would amend this to instead
say that the mobile node can always know about CARs that are
not visible to the network.  But, as it turns out, the network
can always know CARs that are not visible to the mobile node
also.  So, we have to allow the mobile node to 
make the choice,
but we should not prevent the mobile node from following
network-directives.  Thus, we should develop a model by which
CAR discovery is allowed to provide input to a network-controlled
handover scheme, which is nonetheless subject to possible rejection
by the mobile node.

Regards,
Charlie P.

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
--behcet
--------------020200060101070200010202-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 18 12:43: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 MAA14119 for ; Thu, 18 Apr 2002 12:43:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14280 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 12:43:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14095; Thu, 18 Apr 2002 12:41:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14067 for ; Thu, 18 Apr 2002 12:41:17 -0400 (EDT) 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 MAA14030 for ; Thu, 18 Apr 2002 12:41:14 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IGekV03434 for ; Thu, 18 Apr 2002 11:40:46 -0500 (CDT) Message-ID: <3CBEF725.4070906@alcatel.com> Date: Thu, 18 Apr 2002 11:41:09 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.com> <3CBEEC77.3EDB171@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------020200060101070200010202" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org --------------020200060101070200010202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Charlie, Absolutely. What I was pointing out is looking at the history of Seamoby WG, it is keeping to jettison out (as James says) its work items. Maybe Seamoby WG is an incubator of new WGs. So CARD and CT are being incubated and sometime in the future new work items are going to come out with well defined scopes. The discussions here could serve this goal and as such they are probably very useful. This is how I see it. Regards, Charles E. Perkins wrote: >Hello Behcet, > >Behcet Sarikaya wrote: > >>Karim et al., >> It seems to me that what Karim is arguing is MIPv4/v6 fast handover >>drafts do provide a solution to CARD. >> > >That's not what I read, but I'll wait to see what Karim has to say. > >> And he is saying that these are MN centric solutions and bode well >>with Steve's arguments and the end-to-end arguments in system design >>first presented by Saltzer, Reed and Clark in as early as 1984. >> > >I heard Steve's presentation. I asked a question at the microphone >about whether he believed it precluded network-controlled operation. >He said it did not, but he wanted to restore mobile nodes to be >full citizens (paraphrasing, and it's been a few weeks now). >Subsequent discussion seems to be going to extremes, to the point >of ignoring obviously reasonable network-constrolled designs for >which [seamoby] ought to be responsive. > >The paper you cite does not preclude such operation. We can >view the mobile node as a client which is making use of available >service. If the network provides the service, it is free to >establish parameters by which it provides the service, and if >it is beneficial to have a mobile node move to another point of >attachment, I see nothing wrong with notifying the node about >that, along with a good candidate for an access router. I don't >see any reason why the network should be restricted from using >a CAR discovery protoocol to identify such a candidate. > >> Maybe the question is what business Seamoby has here? >> > >My answer would be that [seamoby] ought to be making protocols >by which we can expedite smooth handovers. That's a good piece >of work, and one for which we can exhibit existence proofs to >show that it is possible. I think that so far that there has >been trouble to get agreement on "general" goals, but that there >are particular instances where the intended results should be >obvious. I believe these particular instances include >network-controlled and mobile-controlled scenarios. > >=================================================================== > >Somewhere else, it was stated that only the mobile node can >possibly know all of the CARs. I would amend this to instead >say that the mobile node can always know about CARs that are >not visible to the network. But, as it turns out, the network >can always know CARs that are not visible to the mobile node >also. So, we have to allow the mobile node to make the choice, >but we should not prevent the mobile node from following >network-directives. Thus, we should develop a model by which >CAR discovery is allowed to provide input to a network-controlled >handover scheme, which is nonetheless subject to possible rejection >by the mobile node. > >Regards, >Charlie P. > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > --behcet --------------020200060101070200010202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Charlie,
  Absolutely.
What I was pointing out is looking at the history of Seamoby WG, it is keeping to jettison out (as James says) its work items. Maybe Seamoby WG is an incubator of new WGs.
So CARD and CT are being incubated and sometime in the future new work items are going to come out with  well defined scopes. The discussions here could serve this goal and as such they are probably very useful.
  This is how I see it.

Regards,
Charles E. Perkins wrote:
Hello Behcet,

Behcet Sarikaya wrote:
Karim et al.,
  It seems to me that what Karim is arguing is MIPv4/v6 fast handover
drafts do provide a solution to CARD.

That's not what I read, but I'll wait to see what Karim has to say.

  And he is saying that these are MN centric solutions and bode well
with Steve's arguments and the end-to-end arguments in system design
first presented by Saltzer, Reed and Clark in as early as 1984.

I heard Steve's presentation.  I asked a question at the microphone
about whether he believed it precluded network-controlled operation.
He said it did not, but he wanted to restore mobile nodes to be
full citizens (paraphrasing, and it's been a few weeks now).
Subsequent discussion seems to be going to extremes, to the point
of ignoring obviously reasonable network-constrolled designs for
which [seamoby] ought to be responsive.

The paper you cite does not preclude such operation.  We can
view the mobile node as a client which is making use of available
service.  If the network provides the service, it is free to
establish parameters by which it provides the service, and if
it is beneficial to have a mobile node move to another point of
attachment, I see nothing wrong with notifying the node about
that, along with a good candidate for an access router.  I don't
see any reason why the network should b
e restricted from using
a CAR discovery protoocol to identify such a candidate.

  Maybe the question is what business Seamoby has here?

My answer would be that [seamoby] ought to be making protocols
by which we can expedite smooth handovers.  That's a good piece
of work, and one for which we can exhibit existence proofs to
show that it is possible.  I think that so far that there has
been trouble to get agreement on "general" goals, but that there
are particular instances where the intended results should be
obvious.  I believe these particular instances include
network-controlled and mobile-controlled scenarios.

===================================================================

Somewhere else, it was stated that only the mobile node can
possibly know all of the CARs.  I would amend this to instead
say that the mobile node can always know about CARs that are
not visible to the network.  But, as it turns out, the network
can always know CARs that are not visible to the mobile node
also.  So, we have to allow the mobile node to 
make the choice,
but we should not prevent the mobile node from following
network-directives.  Thus, we should develop a model by which
CAR discovery is allowed to provide input to a network-controlled
handover scheme, which is nonetheless subject to possible rejection
by the mobile node.

Regards,
Charlie P.

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby
--behcet
--------------020200060101070200010202-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 18 16:40: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 QAA22216 for ; Thu, 18 Apr 2002 16:40:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00012; Thu, 18 Apr 2002 16:20:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29941 for ; Thu, 18 Apr 2002 16:20:52 -0400 (EDT) Received: from hotmail.com (f214.law9.hotmail.com [64.4.9.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21709 for ; Thu, 18 Apr 2002 16:20:47 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Apr 2002 13:20:16 -0700 Received: from 194.251.240.108 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Apr 2002 20:20:15 GMT X-Originating-IP: [194.251.240.108] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 16:20:15 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Apr 2002 20:20:16.0927 (UTC) FILETIME=[744832F0:01C1E716] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim, >Since a couple of emails disagreed with me about this point, >I'm sending one email reply to clarify. As in the minutes, >the concept was that the only entity which can find out >all the possible CARs is the MN (that's what I mean by mobile-centric). [Govind] Sure, but there may be inherent constraints. Suppose there is just one interface, and the MN can hear multiple L2 beacons and if figuring out which ARs these L2 devices are connected to implies that the MN has to disconnect from the current AP then what good is the MN finding out the GAARs in this case. Also, to know CARs the MN has to get the capabilties (whatever they might be) from each and every GAAR. This may be an expensive proposition in terms of wireless bandwidth. >The network could give hints, but it is the MN that has the complete >view and decides. That's what I understood from the meeting and there >seemed to be consensus on this. Hope we agree so far. The network >could assist in CAR discovery (e.g. it's L2 can help in anticipating >the movement). That's also somewhere in the minutes. In fact what I >said below was that I couldn't understand why there was focus on a >network-centric solution (i.e. where the MN is NOT involved). [Govind] I don't know where you saw a network based solution which completely prohibits the MN from participation. CAR discovery by definition needs the capability match of the ARs with the MN's requirements. So there cannot be a case wherein the MN is not involved. I wasn't >ruling out network involvement, but I couldn't understand why there >was work on ARs only doing CAR discovery. Hope my point is more clear >now. Maybe I misinterpreted some emails and people are in agreement >with this. I think Dirk's email at least was in line with what I >have above (i.e. we need to focus on the MN's role and allow the >network to assist where needed). [Govind] The main point is that the MNs requirements should be taken into consideration when deciding on the TARs whether this happens in the network or in the MN is upto the individual solution (as long as it satisfies the requirements). Hope these clarifies your concerns. Regards, Govind. >Rgds >/Karim > > > -----Original Message----- > > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > > Sent: den 17 april 2002 21:22 > > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > > hchaskar@hotmail.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > Hello Karim, > > First, I don't think that Steve Deering said anything about excluding > > the network from CAR discovery. All he said (AFAIK) was that the MN's > > preferences must be satisfied in the decision of selecting the TAR. > > Now that doesn't imply MN based CAR discovery: that the MN > > should receive > > all the capabilities and GAAR IDs and then make the decision. > > > > > > Regards, > > Govind. > > > > > > > >The reason I sent my previous email was that I got the feeling > > >from this thread that there is focus on providing a solution for > > >the network-centric case (i.e. the network handles CAR discovery > > >and the MN isn't involved). I wanted to point out that this > > >solution would not be applicable to the mobile-centric case and > > >clarify that this case is supported by MIP (v4 and v6) fast > > >handoffs. > > > > > >From the IETF meeting there was a majority who wanted to go for > > >the mobile-centric case (i.e. where the mobile is involved and > > >decides). Following Steve's presentation I think that became > > >quite clear. So, why are there discussions about doing a solution > > >which is meant for the network-centric case only? This solution > > >wouldn't apply to the mobile-centric case. That's what I was meant > > >to ask in my last email. > > > > > >/Karim > > > > > > > Karim, > > > > > > > > But it is applicable to network initiated handoff. And > > there are two > > > > algorithms, one in which the access router sends a PrxyRtAdv > > > > to the MN > > > > and one in which the MN is switched (for FMIPv4). > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Karim El-Malki (ERA)" > > > > To: "'James Kempf'" ; "Hemant Chaskar" > > > > ; > > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have > > > > > > somehow come to a > > > > > > > >conclusion that there is no need for access routers to > > > > > > divulge that > > > > > > they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > > > > > > infrastructure. The > > > > > > > >minutes also seem to indicate that the mobile > > alone should be > > > > the > > > > > > only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > > information to > > > > > > their > > > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > > > only capable > > > > > > of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical > > problem. What I > > > > would > > > > > > really > > > > > > > like to understand is whether the above is a > > relevant case for > > > > CAR > > > > > > discovery > > > > > > > or we simply neglect it and focus only on two > > > > physical interfaces > > > > > > case. I > > > > > > > raised this question before, but we have not had much > > > > discussion > > > > on > > > > > > it. In > > > > > > > any case, address translation part of CARD will > > be required in > > > > this > > > > > > case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > > delivers the > > > > > > AP or AR L2 identifier to which the MN will be > > handed over. This > > > > > > information is required (by the MIP fast handover > > algorithms) at > > > > the > > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > > able to do > > > > > > reverse address translation in order that it can > > contact the > > > > > > other AR. > > > > > > > > > > This is not really applicable to Mobile-Initiated MIP > > Fast Handoff. > > > > > In Mobile-initiated we consider the useful case where > > the MN can > > > > recover > > > > > the CAR IP address/es from the L2 trigger. The MN then > > > > sends a Proxy > > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > > one or more > > > > CAR > > > > > IP addresses. This means that the source AR already > > gets the CAR > > > > addresses. > > > > > So we can do without the AR doing translation or discovering > > > > geographical > > > > > adjacency. The MN can pass these CAR address/es to the > > > > source AR for > > > > both > > > > > single and multiple-interface MNs. So I think that the > > > > conclusion from > > > > the > > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > > > /Karim > > > > > > > > > > > > > > >_______________________________________________ > > >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 _________________________________________________________________ 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 Thu Apr 18 16:40: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 QAA22228 for ; Thu, 18 Apr 2002 16:40:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01251 for seamoby-archive@odin.ietf.org; Thu, 18 Apr 2002 16:40:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00012; Thu, 18 Apr 2002 16:20:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29941 for ; Thu, 18 Apr 2002 16:20:52 -0400 (EDT) Received: from hotmail.com (f214.law9.hotmail.com [64.4.9.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21709 for ; Thu, 18 Apr 2002 16:20:47 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Apr 2002 13:20:16 -0700 Received: from 194.251.240.108 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 18 Apr 2002 20:20:15 GMT X-Originating-IP: [194.251.240.108] From: "Govind Krishnamurthi" To: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 16:20:15 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Apr 2002 20:20:16.0927 (UTC) FILETIME=[744832F0:01C1E716] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim, >Since a couple of emails disagreed with me about this point, >I'm sending one email reply to clarify. As in the minutes, >the concept was that the only entity which can find out >all the possible CARs is the MN (that's what I mean by mobile-centric). [Govind] Sure, but there may be inherent constraints. Suppose there is just one interface, and the MN can hear multiple L2 beacons and if figuring out which ARs these L2 devices are connected to implies that the MN has to disconnect from the current AP then what good is the MN finding out the GAARs in this case. Also, to know CARs the MN has to get the capabilties (whatever they might be) from each and every GAAR. This may be an expensive proposition in terms of wireless bandwidth. >The network could give hints, but it is the MN that has the complete >view and decides. That's what I understood from the meeting and there >seemed to be consensus on this. Hope we agree so far. The network >could assist in CAR discovery (e.g. it's L2 can help in anticipating >the movement). That's also somewhere in the minutes. In fact what I >said below was that I couldn't understand why there was focus on a >network-centric solution (i.e. where the MN is NOT involved). [Govind] I don't know where you saw a network based solution which completely prohibits the MN from participation. CAR discovery by definition needs the capability match of the ARs with the MN's requirements. So there cannot be a case wherein the MN is not involved. I wasn't >ruling out network involvement, but I couldn't understand why there >was work on ARs only doing CAR discovery. Hope my point is more clear >now. Maybe I misinterpreted some emails and people are in agreement >with this. I think Dirk's email at least was in line with what I >have above (i.e. we need to focus on the MN's role and allow the >network to assist where needed). [Govind] The main point is that the MNs requirements should be taken into consideration when deciding on the TARs whether this happens in the network or in the MN is upto the individual solution (as long as it satisfies the requirements). Hope these clarifies your concerns. Regards, Govind. >Rgds >/Karim > > > -----Original Message----- > > From: Govind Krishnamurthi [mailto:govs23@hotmail.com] > > Sent: den 17 april 2002 21:22 > > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com; > > hchaskar@hotmail.com; seamoby@ietf.org > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > Hello Karim, > > First, I don't think that Steve Deering said anything about excluding > > the network from CAR discovery. All he said (AFAIK) was that the MN's > > preferences must be satisfied in the decision of selecting the TAR. > > Now that doesn't imply MN based CAR discovery: that the MN > > should receive > > all the capabilities and GAAR IDs and then make the decision. > > > > > > Regards, > > Govind. > > > > > > > >The reason I sent my previous email was that I got the feeling > > >from this thread that there is focus on providing a solution for > > >the network-centric case (i.e. the network handles CAR discovery > > >and the MN isn't involved). I wanted to point out that this > > >solution would not be applicable to the mobile-centric case and > > >clarify that this case is supported by MIP (v4 and v6) fast > > >handoffs. > > > > > >From the IETF meeting there was a majority who wanted to go for > > >the mobile-centric case (i.e. where the mobile is involved and > > >decides). Following Steve's presentation I think that became > > >quite clear. So, why are there discussions about doing a solution > > >which is meant for the network-centric case only? This solution > > >wouldn't apply to the mobile-centric case. That's what I was meant > > >to ask in my last email. > > > > > >/Karim > > > > > > > Karim, > > > > > > > > But it is applicable to network initiated handoff. And > > there are two > > > > algorithms, one in which the access router sends a PrxyRtAdv > > > > to the MN > > > > and one in which the MN is switched (for FMIPv4). > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Karim El-Malki (ERA)" > > > > To: "'James Kempf'" ; "Hemant Chaskar" > > > > ; > > > > Sent: Tuesday, April 16, 2002 11:55 AM > > > > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have > > > > > > somehow come to a > > > > > > > >conclusion that there is no need for access routers to > > > > > > divulge that > > > > > > they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > > > > > > infrastructure. The > > > > > > > >minutes also seem to indicate that the mobile > > alone should be > > > > the > > > > > > only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > > > information to > > > > > > their > > > > > > > >source AR if the mobile only has one NIC and that NIC is > > > > > > only capable > > > > > > of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical > > problem. What I > > > > would > > > > > > really > > > > > > > like to understand is whether the above is a > > relevant case for > > > > CAR > > > > > > discovery > > > > > > > or we simply neglect it and focus only on two > > > > physical interfaces > > > > > > case. I > > > > > > > raised this question before, but we have not had much > > > > discussion > > > > on > > > > > > it. In > > > > > > > any case, address translation part of CARD will > > be required in > > > > this > > > > > > case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > > delivers the > > > > > > AP or AR L2 identifier to which the MN will be > > handed over. This > > > > > > information is required (by the MIP fast handover > > algorithms) at > > > > the > > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > > able to do > > > > > > reverse address translation in order that it can > > contact the > > > > > > other AR. > > > > > > > > > > This is not really applicable to Mobile-Initiated MIP > > Fast Handoff. > > > > > In Mobile-initiated we consider the useful case where > > the MN can > > > > recover > > > > > the CAR IP address/es from the L2 trigger. The MN then > > > > sends a Proxy > > > > > Router Solicitation (RtSolPr) to its curent AR containing > > > > one or more > > > > CAR > > > > > IP addresses. This means that the source AR already > > gets the CAR > > > > addresses. > > > > > So we can do without the AR doing translation or discovering > > > > geographical > > > > > adjacency. The MN can pass these CAR address/es to the > > > > source AR for > > > > both > > > > > single and multiple-interface MNs. So I think that the > > > > conclusion from > > > > the > > > > > meeting is compatible with MIP Fast Handoffs. > > > > > > > > > > /Karim > > > > > > > > > > > > > > >_______________________________________________ > > >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 _________________________________________________________________ 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 Fri Apr 19 01:47: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 BAA02879 for ; Fri, 19 Apr 2002 01:47:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12366; Fri, 19 Apr 2002 01:36:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12337 for ; Fri, 19 Apr 2002 01:36:30 -0400 (EDT) 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 BAA02676 for ; Fri, 19 Apr 2002 01:36:29 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5ZaI15859; Thu, 18 Apr 2002 22:35:37 -0700 (PDT) Message-ID: <000201c1e763$d05710f0$4c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Karim El-Malki \(ERA\)" , "'Hemant Chaskar'" , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 08:08:31 -0700 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 > What kind of L2 triggers provide the IP address(es) of the target > (candidate) access routers? > Would you mind providing some examples? > Thanks. > There are no specific examples today of commerial link layers that do this, but we have done some experiments involving modifying the IS-2000 RAN to support triggers. It works extremely well. Also, it's possible to generate a "trigger" of sorts by forcing handoff on certain 802.11 cards that provide to application software the BSSids for access points the mobile can hear. The mobile can utilize the BSSid to find the FA or AR address, or it can send it to the AR to find the address. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Apr 19 01:47: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 BAA02891 for ; Fri, 19 Apr 2002 01:47:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13111 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 01:47:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12366; Fri, 19 Apr 2002 01:36:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12337 for ; Fri, 19 Apr 2002 01:36:30 -0400 (EDT) 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 BAA02676 for ; Fri, 19 Apr 2002 01:36:29 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5ZaI15859; Thu, 18 Apr 2002 22:35:37 -0700 (PDT) Message-ID: <000201c1e763$d05710f0$4c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Karim El-Malki \(ERA\)" , "'Hemant Chaskar'" , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 08:08:31 -0700 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 > What kind of L2 triggers provide the IP address(es) of the target > (candidate) access routers? > Would you mind providing some examples? > Thanks. > There are no specific examples today of commerial link layers that do this, but we have done some experiments involving modifying the IS-2000 RAN to support triggers. It works extremely well. Also, it's possible to generate a "trigger" of sorts by forcing handoff on certain 802.11 cards that provide to application software the BSSids for access points the mobile can hear. The mobile can utilize the BSSid to find the FA or AR address, or it can send it to the AR to find the address. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Apr 19 01:47: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 BAA02905 for ; Fri, 19 Apr 2002 01:47:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13125 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 01:47:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12298; Fri, 19 Apr 2002 01:36:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12269 for ; Fri, 19 Apr 2002 01:36:08 -0400 (EDT) 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 BAA02671 for ; Fri, 19 Apr 2002 01:36:07 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5ZWI15855; Thu, 18 Apr 2002 22:35:33 -0700 (PDT) Message-ID: <000101c1e763$cd93ab30$4c6015ac@T23KEMPF> From: "James Kempf" To: "Karim El-Malki \(ERA\)" , "Hemant Chaskar" , References: <795A014AF92DD21182AF0008C7A404320DFBF084@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 08:01:17 -0700 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 reason I sent my previous email was that I got the feeling > from this thread that there is focus on providing a solution for > the network-centric case (i.e. the network handles CAR discovery > and the MN isn't involved). I wanted to point out that this > solution would not be applicable to the mobile-centric case and > clarify that this case is supported by MIP (v4 and v6) fast > handoffs. > > >From the IETF meeting there was a majority who wanted to go for > the mobile-centric case (i.e. where the mobile is involved and > decides). Following Steve's presentation I think that became > quite clear. So, why are there discussions about doing a solution > which is meant for the network-centric case only? This solution > wouldn't apply to the mobile-centric case. That's what I was meant > to ask in my last email. > I don't think anybody is proposoing a solution just for the network-centric case now (if you are, please raise your hand). The solutions for the mobile-centric case will work for the network-centric case too. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 19 01:49: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 BAA02945 for ; Fri, 19 Apr 2002 01:49:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12417; Fri, 19 Apr 2002 01:36:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12388 for ; Fri, 19 Apr 2002 01:36:50 -0400 (EDT) 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 BAA02682 for ; Fri, 19 Apr 2002 01:36:49 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5a6I15894; Thu, 18 Apr 2002 22:36:06 -0700 (PDT) Message-ID: <000801c1e763$e17bcc90$4c6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 08:33:10 -0700 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, Remember, TAR is not in scope. As a practical matter, I believe the 802.11 standard should provide some guidance, currently it doesn't. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Wednesday, April 17, 2002 2:45 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > If there are more than one L2 beacons available (of comparable signal > strength), probably governed by different ARs, how do we choose? I do not > have problem choosing randomly, but just want to confirm if this is the way > we want to proceed. > > There is no doubt that handoff is necessary as old link will fade, but you > still have choice as to which new beacon to hold on to. > > Hemant > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > >Right, that's what I'm saying. There is one case where the MN needs to > >choose, and the other where the MN and AR get an L2 address and don't > >have a choice. The handover happens because, if not, the power will fade > >and the MN loses link connectivity. > > > >The former case might require capabilities, the latter just requires > >cross link ARP. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Tuesday, April 16, 2002 2:17 PM > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > Hi James: > > > > > > What do you mean when you say that hearing multiple L2 is equivalent > >to > > > inter-technology case? I do not get the point. Why can't the MN listen > >to > > > different L2 beacons of the same technology? I guess it can, and > >hence, it > > > still needs to chose one among them for handoff. Then the issue is > >exactly > > > the same as Glenn raised for single NIC case: How to get capabilities > > > without letting go the old connection? Of course, I am assuming that > >these > > > L2's have comparable signal strengths. > > > > > > Hemant > > > > > > >From: "James Kempf" > > > >To: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > >[The Issue] > > > > > >It seems that the minutes indicate that people have somehow come > >to a > > > > > >conclusion that there is no need for access routers to divulge > >that > > > >they > > > > > >are > > > > > >geographically adjancent to themselves via the IP infrastructure. > >The > > > > > >minutes also seem to indicate that the mobile alone should be the > > > >only way > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > >[Technical Questions] > > > > > >O.K. If this is true then how will a mobile pass this information > >to > > > >their > > > > > >source AR if the mobile only has one NIC and that NIC is only > >capable > > > >of > > > > > >listening to one media at once? > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > >would > > > >really > > > > > like to understand is whether the above is a relevant case for CAR > > > >discovery > > > > > or we simply neglect it and focus only on two physical interfaces > > > >case. I > > > > > raised this question before, but we have not had much discussion > >on > > > >it. In > > > > > any case, address translation part of CARD will be required in > >this > > > >case for > > > > > fast handoff support. > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically delivers > >the > > > >AP or AR L2 identifier to which the MN will be handed over. This > > > >information is required (by the MIP fast handover algorithms) at the > > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > > >reverse address translation in order that it can contact the other > >AR. > > > >Capabilities aren't involved, except to the extent that the MN can > >hear > > > >multiple L2s and make the decision. But this is exactly the same as > >for > > > >the intertechnology case. > > > > > > > > jak > > > > > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > > > _________________________________________________________________ > 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 Fri Apr 19 01: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 BAA02980 for ; Fri, 19 Apr 2002 01:50:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12483; Fri, 19 Apr 2002 01:37:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12451 for ; Fri, 19 Apr 2002 01:37:10 -0400 (EDT) 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 BAA02686 for ; Fri, 19 Apr 2002 01:37:09 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5aTI15929; Thu, 18 Apr 2002 22:36:30 -0700 (PDT) Message-ID: <000d01c1e763$ef9fcb50$4c6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 11:23:59 -0700 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 think one can assume that IP addresses are available in L2 triggers in the general case. But it must still be possible to map an L2 identifier for an AP/AR to an IP address. I think there is one class of problem involving L2 handover where power is the only criterium in which capabilities are not of interest and handover is controlled at L2. That's how it is done today. There is another class where L3 had some input, especially for the intertechnology case but also potentially for intratechnology where time is not of the essence and potentially also for a future L2 where IP makes most of the decisions. In this case, capabilities are of interest. My 0.02 euro. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Wednesday, April 17, 2002 2:56 PM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > Hi Karim: > > >From: "Karim El-Malki (ERA)" > >To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com, > >seamoby@ietf.org > >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Wed, 17 Apr 2002 12:13:57 +0200 > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > delivers the > > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > > information is required (by the MIP fast handover > > > algorithms) at the > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > able to do > > > > > reverse address translation in order that it can contact the > > > > > other AR. > > > > > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > > >In Mobile-initiated we consider the useful case where the > > > MN can recover > > > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > > > >Router Solicitation (RtSolPr) to its curent AR containing > > > one or more CAR > > > >IP addresses. This means that the source AR already gets > > > the CAR addresses. > > > >So we can do without the AR doing translation or > > > discovering geographical > > > >adjacency. The MN can pass these CAR address/es to the > > > source AR for both > > > >single and multiple-interface MNs. So I think that the > > > conclusion from the > > > >meeting is compatible with MIP Fast Handoffs. > > > > > > > >/Karim > > > > > > [HC] I am wondering, if this useful case is genral enough. > > > In other words, > > > can MN always get IP addresses from AP beacons (or L2 > > > triggers) without > > > having to acquire connectivity with AP. More so, in single NIC case. > > > >[KEM] If you get a trigger at the MN you are somehow told > >that you have to move and this could contain the network's desired > >place where you should move (if it's multi-technology then one network > >may not know all that is possible). Here it is assumed that these are > >IP addresses or that the IP addresses can be easily recovered. The MN > >collects the full list of CAR addresses and decides. At least that's > >what I understood people wanted at the last meeting. Do you think it > >is not generic enough since it relies on IP addresses recovered from > >triggers? > > [HC]I think the issue was raised about single NIC case. So, if you are > saying that in general single NIC case, IP addresses will always be > available in beacons (L2 triggers), then our problem becomes simpler, that > is great. I am still looking for answer to question: Is capability discovery > required in this case and how to do this? When you receive multiple L2 > becons (and hence multiple IP addresses from those beacons from L2 triggers > that you have in mind), which one to choose still remains a question. Or, > will L2 triggers also include capability set of ARs? > > Also, another issue that was raised for both single and multiple NIC case > was about power and bandwidth considerations in receiving capabilities at > MN. Again, if that is not a concern then our problem becomes simpler. > > > > > > > > > Also, could you please say what conclusion you are referring to. > > > >[KEM] I'm referring to the discussion about mobile-centric vs > >network-centric > >approaches related to Steve's presentation. I believe there was a > >consensus on mobile-centric, which favours a CAR discovery solution where > >the > >MN is involved and takes the decisions. > > > >/Karim > > > _________________________________________________________________ > 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 Fri Apr 19 01: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 BAA02991 for ; Fri, 19 Apr 2002 01:50:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13348 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 01:50:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12483; Fri, 19 Apr 2002 01:37:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12451 for ; Fri, 19 Apr 2002 01:37:10 -0400 (EDT) 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 BAA02686 for ; Fri, 19 Apr 2002 01:37:09 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5aTI15929; Thu, 18 Apr 2002 22:36:30 -0700 (PDT) Message-ID: <000d01c1e763$ef9fcb50$4c6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 11:23:59 -0700 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 think one can assume that IP addresses are available in L2 triggers in the general case. But it must still be possible to map an L2 identifier for an AP/AR to an IP address. I think there is one class of problem involving L2 handover where power is the only criterium in which capabilities are not of interest and handover is controlled at L2. That's how it is done today. There is another class where L3 had some input, especially for the intertechnology case but also potentially for intratechnology where time is not of the essence and potentially also for a future L2 where IP makes most of the decisions. In this case, capabilities are of interest. My 0.02 euro. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Wednesday, April 17, 2002 2:56 PM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > Hi Karim: > > >From: "Karim El-Malki (ERA)" > >To: "'Hemant Chaskar'" , kempf@docomolabs-usa.com, > >seamoby@ietf.org > >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Wed, 17 Apr 2002 12:13:57 +0200 > > > > > > > In a single interface handoff situation, Layer 2 typically > > > > > delivers the > > > > > AP or AR L2 identifier to which the MN will be handed over. This > > > > > information is required (by the MIP fast handover > > > algorithms) at the > > > > > MN's AR. So the issue is fairly simple: the AR must be > > > able to do > > > > > reverse address translation in order that it can contact the > > > > > other AR. > > > > > > > >This is not really applicable to Mobile-Initiated MIP Fast Handoff. > > > >In Mobile-initiated we consider the useful case where the > > > MN can recover > > > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy > > > >Router Solicitation (RtSolPr) to its curent AR containing > > > one or more CAR > > > >IP addresses. This means that the source AR already gets > > > the CAR addresses. > > > >So we can do without the AR doing translation or > > > discovering geographical > > > >adjacency. The MN can pass these CAR address/es to the > > > source AR for both > > > >single and multiple-interface MNs. So I think that the > > > conclusion from the > > > >meeting is compatible with MIP Fast Handoffs. > > > > > > > >/Karim > > > > > > [HC] I am wondering, if this useful case is genral enough. > > > In other words, > > > can MN always get IP addresses from AP beacons (or L2 > > > triggers) without > > > having to acquire connectivity with AP. More so, in single NIC case. > > > >[KEM] If you get a trigger at the MN you are somehow told > >that you have to move and this could contain the network's desired > >place where you should move (if it's multi-technology then one network > >may not know all that is possible). Here it is assumed that these are > >IP addresses or that the IP addresses can be easily recovered. The MN > >collects the full list of CAR addresses and decides. At least that's > >what I understood people wanted at the last meeting. Do you think it > >is not generic enough since it relies on IP addresses recovered from > >triggers? > > [HC]I think the issue was raised about single NIC case. So, if you are > saying that in general single NIC case, IP addresses will always be > available in beacons (L2 triggers), then our problem becomes simpler, that > is great. I am still looking for answer to question: Is capability discovery > required in this case and how to do this? When you receive multiple L2 > becons (and hence multiple IP addresses from those beacons from L2 triggers > that you have in mind), which one to choose still remains a question. Or, > will L2 triggers also include capability set of ARs? > > Also, another issue that was raised for both single and multiple NIC case > was about power and bandwidth considerations in receiving capabilities at > MN. Again, if that is not a concern then our problem becomes simpler. > > > > > > > > > Also, could you please say what conclusion you are referring to. > > > >[KEM] I'm referring to the discussion about mobile-centric vs > >network-centric > >approaches related to Steve's presentation. I believe there was a > >consensus on mobile-centric, which favours a CAR discovery solution where > >the > >MN is involved and takes the decisions. > > > >/Karim > > > _________________________________________________________________ > 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 Fri Apr 19 02:40: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 BAA02883 for ; Fri, 19 Apr 2002 01:47:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12298; Fri, 19 Apr 2002 01:36:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12269 for ; Fri, 19 Apr 2002 01:36:08 -0400 (EDT) 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 BAA02671 for ; Fri, 19 Apr 2002 01:36:07 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5ZWI15855; Thu, 18 Apr 2002 22:35:33 -0700 (PDT) Message-ID: <000101c1e763$cd93ab30$4c6015ac@T23KEMPF> From: "James Kempf" To: "Karim El-Malki \(ERA\)" , "Hemant Chaskar" , References: <795A014AF92DD21182AF0008C7A404320DFBF084@esealnt117> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 08:01:17 -0700 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 reason I sent my previous email was that I got the feeling > from this thread that there is focus on providing a solution for > the network-centric case (i.e. the network handles CAR discovery > and the MN isn't involved). I wanted to point out that this > solution would not be applicable to the mobile-centric case and > clarify that this case is supported by MIP (v4 and v6) fast > handoffs. > > >From the IETF meeting there was a majority who wanted to go for > the mobile-centric case (i.e. where the mobile is involved and > decides). Following Steve's presentation I think that became > quite clear. So, why are there discussions about doing a solution > which is meant for the network-centric case only? This solution > wouldn't apply to the mobile-centric case. That's what I was meant > to ask in my last email. > I don't think anybody is proposoing a solution just for the network-centric case now (if you are, please raise your hand). The solutions for the mobile-centric case will work for the network-centric case too. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Apr 19 02:40: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 BAA02956 for ; Fri, 19 Apr 2002 01:49:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13232 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 01:49:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12417; Fri, 19 Apr 2002 01:36:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12388 for ; Fri, 19 Apr 2002 01:36:50 -0400 (EDT) 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 BAA02682 for ; Fri, 19 Apr 2002 01:36:49 -0400 (EDT) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5a6I15894; Thu, 18 Apr 2002 22:36:06 -0700 (PDT) Message-ID: <000801c1e763$e17bcc90$4c6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Thu, 18 Apr 2002 08:33:10 -0700 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, Remember, TAR is not in scope. As a practical matter, I believe the 802.11 standard should provide some guidance, currently it doesn't. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Wednesday, April 17, 2002 2:45 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > If there are more than one L2 beacons available (of comparable signal > strength), probably governed by different ARs, how do we choose? I do not > have problem choosing randomly, but just want to confirm if this is the way > we want to proceed. > > There is no doubt that handoff is necessary as old link will fade, but you > still have choice as to which new beacon to hold on to. > > Hemant > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > >Right, that's what I'm saying. There is one case where the MN needs to > >choose, and the other where the MN and AR get an L2 address and don't > >have a choice. The handover happens because, if not, the power will fade > >and the MN loses link connectivity. > > > >The former case might require capabilities, the latter just requires > >cross link ARP. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Tuesday, April 16, 2002 2:17 PM > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > Hi James: > > > > > > What do you mean when you say that hearing multiple L2 is equivalent > >to > > > inter-technology case? I do not get the point. Why can't the MN listen > >to > > > different L2 beacons of the same technology? I guess it can, and > >hence, it > > > still needs to chose one among them for handoff. Then the issue is > >exactly > > > the same as Glenn raised for single NIC case: How to get capabilities > > > without letting go the old connection? Of course, I am assuming that > >these > > > L2's have comparable signal strengths. > > > > > > Hemant > > > > > > >From: "James Kempf" > > > >To: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > >[The Issue] > > > > > >It seems that the minutes indicate that people have somehow come > >to a > > > > > >conclusion that there is no need for access routers to divulge > >that > > > >they > > > > > >are > > > > > >geographically adjancent to themselves via the IP infrastructure. > >The > > > > > >minutes also seem to indicate that the mobile alone should be the > > > >only way > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > >[Technical Questions] > > > > > >O.K. If this is true then how will a mobile pass this information > >to > > > >their > > > > > >source AR if the mobile only has one NIC and that NIC is only > >capable > > > >of > > > > > >listening to one media at once? > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > >would > > > >really > > > > > like to understand is whether the above is a relevant case for CAR > > > >discovery > > > > > or we simply neglect it and focus only on two physical interfaces > > > >case. I > > > > > raised this question before, but we have not had much discussion > >on > > > >it. In > > > > > any case, address translation part of CARD will be required in > >this > > > >case for > > > > > fast handoff support. > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically delivers > >the > > > >AP or AR L2 identifier to which the MN will be handed over. This > > > >information is required (by the MIP fast handover algorithms) at the > > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > > >reverse address translation in order that it can contact the other > >AR. > > > >Capabilities aren't involved, except to the extent that the MN can > >hear > > > >multiple L2s and make the decision. But this is exactly the same as > >for > > > >the intertechnology case. > > > > > > > > jak > > > > > > > > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > > > _________________________________________________________________ > 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 Fri Apr 19 04:58: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 EAA13870 for ; Fri, 19 Apr 2002 04:58:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23887; Fri, 19 Apr 2002 04:47:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23841 for ; Fri, 19 Apr 2002 04:47:20 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13698 for ; Fri, 19 Apr 2002 04:47:16 -0400 (EDT) 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 g3J8lIs7005711 for ; Fri, 19 Apr 2002 10:47:18 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 19 10:46:48 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 10:36:18 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF08B@esealnt117> From: "Karim El-Malki (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 10:44:39 +0200 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 wasn't > >ruling out network involvement, but I couldn't understand why there > >was work on ARs only doing CAR discovery. Hope my point is > more clear > >now. Maybe I misinterpreted some emails and people are in agreement > >with this. I think Dirk's email at least was in line with what I > >have above (i.e. we need to focus on the MN's role and allow the > >network to assist where needed). > > [Govind] The main point is that the MNs requirements should be > taken into consideration when deciding on the TARs whether this > happens in the network or in the MN is upto the individual solution > (as long as it satisfies the requirements). > Hope these clarifies your concerns. Sorry I'm falling behind on this discussion and haven't read all the emails, but the point was that the decision is to be taken by the MN, not by the network. So what you write above about the decision happening in the network does not follow from the discussion so far. The MN should take the decision with hints from the network, not the other way round. /K. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Apr 19 04:58: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 EAA13879 for ; Fri, 19 Apr 2002 04:58:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA24440 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 04:58:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23887; Fri, 19 Apr 2002 04:47:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23841 for ; Fri, 19 Apr 2002 04:47:20 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13698 for ; Fri, 19 Apr 2002 04:47:16 -0400 (EDT) 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 g3J8lIs7005711 for ; Fri, 19 Apr 2002 10:47:18 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 19 10:46:48 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 10:36:18 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF08B@esealnt117> From: "Karim El-Malki (ERA)" To: "'Govind Krishnamurthi'" , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 10:44:39 +0200 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 wasn't > >ruling out network involvement, but I couldn't understand why there > >was work on ARs only doing CAR discovery. Hope my point is > more clear > >now. Maybe I misinterpreted some emails and people are in agreement > >with this. I think Dirk's email at least was in line with what I > >have above (i.e. we need to focus on the MN's role and allow the > >network to assist where needed). > > [Govind] The main point is that the MNs requirements should be > taken into consideration when deciding on the TARs whether this > happens in the network or in the MN is upto the individual solution > (as long as it satisfies the requirements). > Hope these clarifies your concerns. Sorry I'm falling behind on this discussion and haven't read all the emails, but the point was that the decision is to be taken by the MN, not by the network. So what you write above about the decision happening in the network does not follow from the discussion so far. The MN should take the decision with hints from the network, not the other way round. /K. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 19 05:20: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 FAA14200 for ; Fri, 19 Apr 2002 05:20:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25085; Fri, 19 Apr 2002 05:03:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25059 for ; Fri, 19 Apr 2002 05:03:35 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13944 for ; Fri, 19 Apr 2002 05:03:30 -0400 (EDT) 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 g3J93W3G017509 for ; Fri, 19 Apr 2002 11:03:32 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 19 11:03:21 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTQG48>; Fri, 19 Apr 2002 11:03:21 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF08C@esealnt117> From: "Karim El-Malki (ERA)" To: "'James Kempf'" , Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 11:01:18 +0200 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 reason I sent my previous email was that I got the feeling > > from this thread that there is focus on providing a solution for > > the network-centric case (i.e. the network handles CAR discovery > > and the MN isn't involved). I wanted to point out that this > > solution would not be applicable to the mobile-centric case and > > clarify that this case is supported by MIP (v4 and v6) fast > > handoffs. > > > > >From the IETF meeting there was a majority who wanted to go for > > the mobile-centric case (i.e. where the mobile is involved and > > decides). Following Steve's presentation I think that became > > quite clear. So, why are there discussions about doing a solution > > which is meant for the network-centric case only? This solution > > wouldn't apply to the mobile-centric case. That's what I was meant > > to ask in my last email. > > > > I don't think anybody is proposoing a solution just for the > network-centric > case now (if you are, please raise your hand). > > The solutions for the mobile-centric case will work for the > network-centric > case too. Seems like it was my misunderstanding and the way I posed the question. I was trying to see whether there was agreement on the mailing list (after agreement during the meeting) about the MN being the entity which discovers all possible CARs, with hints from the network, and takes the decision. /Karim _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Apr 19 05: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 FAA14211 for ; Fri, 19 Apr 2002 05:20:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25636 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 05:20:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25085; Fri, 19 Apr 2002 05:03:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25059 for ; Fri, 19 Apr 2002 05:03:35 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13944 for ; Fri, 19 Apr 2002 05:03:30 -0400 (EDT) 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 g3J93W3G017509 for ; Fri, 19 Apr 2002 11:03:32 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 19 11:03:21 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTQG48>; Fri, 19 Apr 2002 11:03:21 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF08C@esealnt117> From: "Karim El-Malki (ERA)" To: "'James Kempf'" , Hemant Chaskar , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 11:01:18 +0200 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 reason I sent my previous email was that I got the feeling > > from this thread that there is focus on providing a solution for > > the network-centric case (i.e. the network handles CAR discovery > > and the MN isn't involved). I wanted to point out that this > > solution would not be applicable to the mobile-centric case and > > clarify that this case is supported by MIP (v4 and v6) fast > > handoffs. > > > > >From the IETF meeting there was a majority who wanted to go for > > the mobile-centric case (i.e. where the mobile is involved and > > decides). Following Steve's presentation I think that became > > quite clear. So, why are there discussions about doing a solution > > which is meant for the network-centric case only? This solution > > wouldn't apply to the mobile-centric case. That's what I was meant > > to ask in my last email. > > > > I don't think anybody is proposoing a solution just for the > network-centric > case now (if you are, please raise your hand). > > The solutions for the mobile-centric case will work for the > network-centric > case too. Seems like it was my misunderstanding and the way I posed the question. I was trying to see whether there was agreement on the mailing list (after agreement during the meeting) about the MN being the entity which discovers all possible CARs, with hints from the network, and takes the decision. /Karim _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 19 11:25: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 LAA23577 for ; Fri, 19 Apr 2002 11:25:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17570; Fri, 19 Apr 2002 11:12:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17526 for ; Fri, 19 Apr 2002 11:12:41 -0400 (EDT) Received: from hotmail.com (f52.law7.hotmail.com [216.33.237.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23077 for ; Fri, 19 Apr 2002 11:12:37 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 08:12:10 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 15:12:09 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 15:12:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 15:12:10.0008 (UTC) FILETIME=[93A1F980:01C1E7B4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, TAR is not in scope. I am talking about identifying capabilities of ARs (or identifying match between capabilities of these ARs and MN's requirements) that govern these L2 beacons. So, is it in scope of CAR discovery or we delegate the matter to IEEE? Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Thu, 18 Apr 2002 08:33:10 -0700 > >Hemant, > >Remember, TAR is not in scope. > >As a practical matter, I believe the 802.11 standard should provide some >guidance, currently it doesn't. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Wednesday, April 17, 2002 2:45 PM >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James: > > > > If there are more than one L2 beacons available (of comparable signal > > strength), probably governed by different ARs, how do we choose? I do >not > > have problem choosing randomly, but just want to confirm if this is >the way > > we want to proceed. > > > > There is no doubt that handoff is necessary as old link will fade, but >you > > still have choice as to which new beacon to hold on to. > > > > Hemant > > > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > >Right, that's what I'm saying. There is one case where the MN needs >to > > >choose, and the other where the MN and AR get an L2 address and don't > > >have a choice. The handover happens because, if not, the power will >fade > > >and the MN loses link connectivity. > > > > > >The former case might require capabilities, the latter just requires > > >cross link ARP. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Tuesday, April 16, 2002 2:17 PM > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > Hi James: > > > > > > > > What do you mean when you say that hearing multiple L2 is >equivalent > > >to > > > > inter-technology case? I do not get the point. Why can't the MN >listen > > >to > > > > different L2 beacons of the same technology? I guess it can, and > > >hence, it > > > > still needs to chose one among them for handoff. Then the issue is > > >exactly > > > > the same as Glenn raised for single NIC case: How to get >capabilities > > > > without letting go the old connection? Of course, I am assuming >that > > >these > > > > L2's have comparable signal strengths. > > > > > > > > Hemant > > > > > > > > >From: "James Kempf" > > > > >To: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > >[The Issue] > > > > > > >It seems that the minutes indicate that people have somehow >come > > >to a > > > > > > >conclusion that there is no need for access routers to >divulge > > >that > > > > >they > > > > > > >are > > > > > > >geographically adjancent to themselves via the IP >infrastructure. > > >The > > > > > > >minutes also seem to indicate that the mobile alone should be >the > > > > >only way > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > >[Technical Questions] > > > > > > >O.K. If this is true then how will a mobile pass this >information > > >to > > > > >their > > > > > > >source AR if the mobile only has one NIC and that NIC is only > > >capable > > > > >of > > > > > > >listening to one media at once? > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > > >would > > > > >really > > > > > > like to understand is whether the above is a relevant case for >CAR > > > > >discovery > > > > > > or we simply neglect it and focus only on two physical >interfaces > > > > >case. I > > > > > > raised this question before, but we have not had much >discussion > > >on > > > > >it. In > > > > > > any case, address translation part of CARD will be required in > > >this > > > > >case for > > > > > > fast handoff support. > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically >delivers > > >the > > > > >AP or AR L2 identifier to which the MN will be handed over. This > > > > >information is required (by the MIP fast handover algorithms) at >the > > > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > > > >reverse address translation in order that it can contact the >other > > >AR. > > > > >Capabilities aren't involved, except to the extent that the MN >can > > >hear > > > > >multiple L2s and make the decision. But this is exactly the same >as > > >for > > > > >the intertechnology case. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > > > > _________________________________________________________________ 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 Fri Apr 19 11:25: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 LAA23589 for ; Fri, 19 Apr 2002 11:25:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18714 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 11:25:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17570; Fri, 19 Apr 2002 11:12:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17526 for ; Fri, 19 Apr 2002 11:12:41 -0400 (EDT) Received: from hotmail.com (f52.law7.hotmail.com [216.33.237.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23077 for ; Fri, 19 Apr 2002 11:12:37 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 08:12:10 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 15:12:09 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 15:12:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 15:12:10.0008 (UTC) FILETIME=[93A1F980:01C1E7B4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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, TAR is not in scope. I am talking about identifying capabilities of ARs (or identifying match between capabilities of these ARs and MN's requirements) that govern these L2 beacons. So, is it in scope of CAR discovery or we delegate the matter to IEEE? Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Thu, 18 Apr 2002 08:33:10 -0700 > >Hemant, > >Remember, TAR is not in scope. > >As a practical matter, I believe the 802.11 standard should provide some >guidance, currently it doesn't. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Wednesday, April 17, 2002 2:45 PM >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James: > > > > If there are more than one L2 beacons available (of comparable signal > > strength), probably governed by different ARs, how do we choose? I do >not > > have problem choosing randomly, but just want to confirm if this is >the way > > we want to proceed. > > > > There is no doubt that handoff is necessary as old link will fade, but >you > > still have choice as to which new beacon to hold on to. > > > > Hemant > > > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > >Right, that's what I'm saying. There is one case where the MN needs >to > > >choose, and the other where the MN and AR get an L2 address and don't > > >have a choice. The handover happens because, if not, the power will >fade > > >and the MN loses link connectivity. > > > > > >The former case might require capabilities, the latter just requires > > >cross link ARP. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Tuesday, April 16, 2002 2:17 PM > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > Hi James: > > > > > > > > What do you mean when you say that hearing multiple L2 is >equivalent > > >to > > > > inter-technology case? I do not get the point. Why can't the MN >listen > > >to > > > > different L2 beacons of the same technology? I guess it can, and > > >hence, it > > > > still needs to chose one among them for handoff. Then the issue is > > >exactly > > > > the same as Glenn raised for single NIC case: How to get >capabilities > > > > without letting go the old connection? Of course, I am assuming >that > > >these > > > > L2's have comparable signal strengths. > > > > > > > > Hemant > > > > > > > > >From: "James Kempf" > > > > >To: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > >[The Issue] > > > > > > >It seems that the minutes indicate that people have somehow >come > > >to a > > > > > > >conclusion that there is no need for access routers to >divulge > > >that > > > > >they > > > > > > >are > > > > > > >geographically adjancent to themselves via the IP >infrastructure. > > >The > > > > > > >minutes also seem to indicate that the mobile alone should be >the > > > > >only way > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > >[Technical Questions] > > > > > > >O.K. If this is true then how will a mobile pass this >information > > >to > > > > >their > > > > > > >source AR if the mobile only has one NIC and that NIC is only > > >capable > > > > >of > > > > > > >listening to one media at once? > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > > >would > > > > >really > > > > > > like to understand is whether the above is a relevant case for >CAR > > > > >discovery > > > > > > or we simply neglect it and focus only on two physical >interfaces > > > > >case. I > > > > > > raised this question before, but we have not had much >discussion > > >on > > > > >it. In > > > > > > any case, address translation part of CARD will be required in > > >this > > > > >case for > > > > > > fast handoff support. > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically >delivers > > >the > > > > >AP or AR L2 identifier to which the MN will be handed over. This > > > > >information is required (by the MIP fast handover algorithms) at >the > > > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > > > >reverse address translation in order that it can contact the >other > > >AR. > > > > >Capabilities aren't involved, except to the extent that the MN >can > > >hear > > > > >multiple L2s and make the decision. But this is exactly the same >as > > >for > > > > >the intertechnology case. > > > > > > > > > > jak > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > > > > _________________________________________________________________ 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 Fri Apr 19 11:29: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 LAA23839 for ; Fri, 19 Apr 2002 11:29:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18130; Fri, 19 Apr 2002 11:19:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18104 for ; Fri, 19 Apr 2002 11:19:53 -0400 (EDT) Received: from hotmail.com (f12.law7.hotmail.com [216.33.237.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23348 for ; Fri, 19 Apr 2002 11:19:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 08:19:22 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 15:19:20 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: Karim.El-Malki@era.ericsson.se, govs23@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 15:19:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 15:19:22.0699 (UTC) FILETIME=[958961B0:01C1E7B5] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim: I am trying to understand the algorithmic perspective of the comment below saying that "The MN should take the decision with hints from the network, not the other way round." So, if there is an application on MN processor which takes one input as MN requirements and other input as AR capabilities and provides certain output (say boolean yes or no), is it acceptable approach? I guess yes. Now, suppose that there is this *same* application somewhere on processor of some network entity taking the *same* inputs as above and providing the same kind of output, is it acceptable approach? I guess it should be. So, is it the input and output information model of the application that decides whether the approach in MN-centric or is it the location of the processor executing the application as such that decides whether the approach is MN-centric? I guess it is the former. Hemant >From: "Karim El-Malki (ERA)" >To: "'Govind Krishnamurthi'" , seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Fri, 19 Apr 2002 10:44:39 +0200 > > > I wasn't > > >ruling out network involvement, but I couldn't understand why there > > >was work on ARs only doing CAR discovery. Hope my point is > > more clear > > >now. Maybe I misinterpreted some emails and people are in agreement > > >with this. I think Dirk's email at least was in line with what I > > >have above (i.e. we need to focus on the MN's role and allow the > > >network to assist where needed). > > > > [Govind] The main point is that the MNs requirements should be > > taken into consideration when deciding on the TARs whether this > > happens in the network or in the MN is upto the individual solution > > (as long as it satisfies the requirements). > > Hope these clarifies your concerns. > >Sorry I'm falling behind on this discussion and haven't read all the >emails, >but the point was that the decision is to be taken by the MN, not by the >network. So what you write above about the decision happening in the >network >does not follow from the discussion so far. The MN should take the decision >with hints from the network, not the other way round. > >/K. > >_______________________________________________ >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 Fri Apr 19 11:29: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 LAA23850 for ; Fri, 19 Apr 2002 11:29:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19012 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 11:29:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18130; Fri, 19 Apr 2002 11:19:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18104 for ; Fri, 19 Apr 2002 11:19:53 -0400 (EDT) Received: from hotmail.com (f12.law7.hotmail.com [216.33.237.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23348 for ; Fri, 19 Apr 2002 11:19:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 08:19:22 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 15:19:20 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: Karim.El-Malki@era.ericsson.se, govs23@hotmail.com, seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 15:19:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 15:19:22.0699 (UTC) FILETIME=[958961B0:01C1E7B5] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 Karim: I am trying to understand the algorithmic perspective of the comment below saying that "The MN should take the decision with hints from the network, not the other way round." So, if there is an application on MN processor which takes one input as MN requirements and other input as AR capabilities and provides certain output (say boolean yes or no), is it acceptable approach? I guess yes. Now, suppose that there is this *same* application somewhere on processor of some network entity taking the *same* inputs as above and providing the same kind of output, is it acceptable approach? I guess it should be. So, is it the input and output information model of the application that decides whether the approach in MN-centric or is it the location of the processor executing the application as such that decides whether the approach is MN-centric? I guess it is the former. Hemant >From: "Karim El-Malki (ERA)" >To: "'Govind Krishnamurthi'" , seamoby@ietf.org >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 >Date: Fri, 19 Apr 2002 10:44:39 +0200 > > > I wasn't > > >ruling out network involvement, but I couldn't understand why there > > >was work on ARs only doing CAR discovery. Hope my point is > > more clear > > >now. Maybe I misinterpreted some emails and people are in agreement > > >with this. I think Dirk's email at least was in line with what I > > >have above (i.e. we need to focus on the MN's role and allow the > > >network to assist where needed). > > > > [Govind] The main point is that the MNs requirements should be > > taken into consideration when deciding on the TARs whether this > > happens in the network or in the MN is upto the individual solution > > (as long as it satisfies the requirements). > > Hope these clarifies your concerns. > >Sorry I'm falling behind on this discussion and haven't read all the >emails, >but the point was that the decision is to be taken by the MN, not by the >network. So what you write above about the decision happening in the >network >does not follow from the discussion so far. The MN should take the decision >with hints from the network, not the other way round. > >/K. > >_______________________________________________ >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 Fri Apr 19 11:48: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 LAA24535 for ; Fri, 19 Apr 2002 11:48:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20018; Fri, 19 Apr 2002 11:44:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19990 for ; Fri, 19 Apr 2002 11:44:15 -0400 (EDT) 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 LAA24290 for ; Fri, 19 Apr 2002 11:44:11 -0400 (EDT) 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 g3JFhcI03945; Fri, 19 Apr 2002 08:43:38 -0700 (PDT) Message-ID: <007201c1e7b8$c08895e0$746015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.com> <3CBEEC77.3EDB171@iprg.nokia.com> <3CBEF725.4070906@alcatel.com> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 08:40:33 -0700 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 CARD and CT are in the charter and will stay there. There are just the right number of people and a good technical discussion going. These are precursors for a successful technical solution in IETF, though success is at this point by no means guaranteed. jak ----- Original Message ----- From: "Behcet Sarikaya" To: Sent: Thursday, April 18, 2002 9:41 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hello Charlie, > Absolutely. > What I was pointing out is looking at the history of Seamoby WG, it is > keeping to jettison out (as James says) its work items. Maybe Seamoby WG > is an incubator of new WGs. > So CARD and CT are being incubated and sometime in the future new work > items are going to come out with well defined scopes. The discussions > here could serve this goal and as such they are probably very useful. > This is how I see it. > > Regards, > Charles E. Perkins wrote: > > >Hello Behcet, > > > >Behcet Sarikaya wrote: > > > >>Karim et al., > >> It seems to me that what Karim is arguing is MIPv4/v6 fast handover > >>drafts do provide a solution to CARD. > >> > > > >That's not what I read, but I'll wait to see what Karim has to say. > > > >> And he is saying that these are MN centric solutions and bode well > >>with Steve's arguments and the end-to-end arguments in system design > >>first presented by Saltzer, Reed and Clark in as early as 1984. > >> > > > >I heard Steve's presentation. I asked a question at the microphone > >about whether he believed it precluded network-controlled operation. > >He said it did not, but he wanted to restore mobile nodes to be > >full citizens (paraphrasing, and it's been a few weeks now). > >Subsequent discussion seems to be going to extremes, to the point > >of ignoring obviously reasonable network-constrolled designs for > >which [seamoby] ought to be responsive. > > > >The paper you cite does not preclude such operation. We can > >view the mobile node as a client which is making use of available > >service. If the network provides the service, it is free to > >establish parameters by which it provides the service, and if > >it is beneficial to have a mobile node move to another point of > >attachment, I see nothing wrong with notifying the node about > >that, along with a good candidate for an access router. I don't > >see any reason why the network should be restricted from using > >a CAR discovery protoocol to identify such a candidate. > > > >> Maybe the question is what business Seamoby has here? > >> > > > >My answer would be that [seamoby] ought to be making protocols > >by which we can expedite smooth handovers. That's a good piece > >of work, and one for which we can exhibit existence proofs to > >show that it is possible. I think that so far that there has > >been trouble to get agreement on "general" goals, but that there > >are particular instances where the intended results should be > >obvious. I believe these particular instances include > >network-controlled and mobile-controlled scenarios. > > > >=================================================================== > > > >Somewhere else, it was stated that only the mobile node can > >possibly know all of the CARs. I would amend this to instead > >say that the mobile node can always know about CARs that are > >not visible to the network. But, as it turns out, the network > >can always know CARs that are not visible to the mobile node > >also. So, we have to allow the mobile node to make the choice, > >but we should not prevent the mobile node from following > >network-directives. Thus, we should develop a model by which > >CAR discovery is allowed to provide input to a network-controlled > >handover scheme, which is nonetheless subject to possible rejection > >by the mobile node. > > > >Regards, > >Charlie P. > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > --behcet > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Fri Apr 19 11:48: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 LAA24545 for ; Fri, 19 Apr 2002 11:48:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20589 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 11:48:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20018; Fri, 19 Apr 2002 11:44:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19990 for ; Fri, 19 Apr 2002 11:44:15 -0400 (EDT) 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 LAA24290 for ; Fri, 19 Apr 2002 11:44:11 -0400 (EDT) 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 g3JFhcI03945; Fri, 19 Apr 2002 08:43:38 -0700 (PDT) Message-ID: <007201c1e7b8$c08895e0$746015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" , References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117> <3CBEDF29.2050707@alcatel.com> <3CBEEC77.3EDB171@iprg.nokia.com> <3CBEF725.4070906@alcatel.com> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 08:40:33 -0700 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 CARD and CT are in the charter and will stay there. There are just the right number of people and a good technical discussion going. These are precursors for a successful technical solution in IETF, though success is at this point by no means guaranteed. jak ----- Original Message ----- From: "Behcet Sarikaya" To: Sent: Thursday, April 18, 2002 9:41 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hello Charlie, > Absolutely. > What I was pointing out is looking at the history of Seamoby WG, it is > keeping to jettison out (as James says) its work items. Maybe Seamoby WG > is an incubator of new WGs. > So CARD and CT are being incubated and sometime in the future new work > items are going to come out with well defined scopes. The discussions > here could serve this goal and as such they are probably very useful. > This is how I see it. > > Regards, > Charles E. Perkins wrote: > > >Hello Behcet, > > > >Behcet Sarikaya wrote: > > > >>Karim et al., > >> It seems to me that what Karim is arguing is MIPv4/v6 fast handover > >>drafts do provide a solution to CARD. > >> > > > >That's not what I read, but I'll wait to see what Karim has to say. > > > >> And he is saying that these are MN centric solutions and bode well > >>with Steve's arguments and the end-to-end arguments in system design > >>first presented by Saltzer, Reed and Clark in as early as 1984. > >> > > > >I heard Steve's presentation. I asked a question at the microphone > >about whether he believed it precluded network-controlled operation. > >He said it did not, but he wanted to restore mobile nodes to be > >full citizens (paraphrasing, and it's been a few weeks now). > >Subsequent discussion seems to be going to extremes, to the point > >of ignoring obviously reasonable network-constrolled designs for > >which [seamoby] ought to be responsive. > > > >The paper you cite does not preclude such operation. We can > >view the mobile node as a client which is making use of available > >service. If the network provides the service, it is free to > >establish parameters by which it provides the service, and if > >it is beneficial to have a mobile node move to another point of > >attachment, I see nothing wrong with notifying the node about > >that, along with a good candidate for an access router. I don't > >see any reason why the network should be restricted from using > >a CAR discovery protoocol to identify such a candidate. > > > >> Maybe the question is what business Seamoby has here? > >> > > > >My answer would be that [seamoby] ought to be making protocols > >by which we can expedite smooth handovers. That's a good piece > >of work, and one for which we can exhibit existence proofs to > >show that it is possible. I think that so far that there has > >been trouble to get agreement on "general" goals, but that there > >are particular instances where the intended results should be > >obvious. I believe these particular instances include > >network-controlled and mobile-controlled scenarios. > > > >=================================================================== > > > >Somewhere else, it was stated that only the mobile node can > >possibly know all of the CARs. I would amend this to instead > >say that the mobile node can always know about CARs that are > >not visible to the network. But, as it turns out, the network > >can always know CARs that are not visible to the mobile node > >also. So, we have to allow the mobile node to make the choice, > >but we should not prevent the mobile node from following > >network-directives. Thus, we should develop a model by which > >CAR discovery is allowed to provide input to a network-controlled > >handover scheme, which is nonetheless subject to possible rejection > >by the mobile node. > > > >Regards, > >Charlie P. > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > --behcet > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 19 12: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 MAA29333 for ; Fri, 19 Apr 2002 12:30:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23456; Fri, 19 Apr 2002 12:21:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23428 for ; Fri, 19 Apr 2002 12:21:06 -0400 (EDT) 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 MAA27810 for ; Fri, 19 Apr 2002 12:21:02 -0400 (EDT) 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 g3JGKVI05775; Fri, 19 Apr 2002 09:20:32 -0700 (PDT) Message-ID: <019d01c1e7bd$e7d00750$746015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 09:18:53 -0700 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 what L2 beacons has to do with CAR discovery. The issue is what ARs the MN has access to and what are their capabilities. How the MN chooses to use that in the context of a particular L2 is up to the MN. The ARs may be identified by their L2 identifier or by an IP address. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Friday, April 19, 2002 8:12 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James, > > TAR is not in scope. I am talking about identifying capabilities of ARs (or > identifying match between capabilities of these ARs and MN's requirements) > that govern these L2 beacons. > > So, is it in scope of CAR discovery or we delegate the matter to IEEE? > > Hemant > > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > >Hemant, > > > >Remember, TAR is not in scope. > > > >As a practical matter, I believe the 802.11 standard should provide some > >guidance, currently it doesn't. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Wednesday, April 17, 2002 2:45 PM > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > Hi James: > > > > > > If there are more than one L2 beacons available (of comparable signal > > > strength), probably governed by different ARs, how do we choose? I do > >not > > > have problem choosing randomly, but just want to confirm if this is > >the way > > > we want to proceed. > > > > > > There is no doubt that handoff is necessary as old link will fade, but > >you > > > still have choice as to which new beacon to hold on to. > > > > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > >Right, that's what I'm saying. There is one case where the MN needs > >to > > > >choose, and the other where the MN and AR get an L2 address and don't > > > >have a choice. The handover happens because, if not, the power will > >fade > > > >and the MN loses link connectivity. > > > > > > > >The former case might require capabilities, the latter just requires > > > >cross link ARP. > > > > > > > > jak > > > > > > > >----- Original Message ----- > > > >From: "Hemant Chaskar" > > > >To: ; > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > Hi James: > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > >equivalent > > > >to > > > > > inter-technology case? I do not get the point. Why can't the MN > >listen > > > >to > > > > > different L2 beacons of the same technology? I guess it can, and > > > >hence, it > > > > > still needs to chose one among them for handoff. Then the issue is > > > >exactly > > > > > the same as Glenn raised for single NIC case: How to get > >capabilities > > > > > without letting go the old connection? Of course, I am assuming > >that > > > >these > > > > > L2's have comparable signal strengths. > > > > > > > > > > Hemant > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Hemant Chaskar" , > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have somehow > >come > > > >to a > > > > > > > >conclusion that there is no need for access routers to > >divulge > > > >that > > > > > >they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > >infrastructure. > > > >The > > > > > > > >minutes also seem to indicate that the mobile alone should be > >the > > > > > >only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > >information > > > >to > > > > > >their > > > > > > > >source AR if the mobile only has one NIC and that NIC is only > > > >capable > > > > > >of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > > > >would > > > > > >really > > > > > > > like to understand is whether the above is a relevant case for > >CAR > > > > > >discovery > > > > > > > or we simply neglect it and focus only on two physical > >interfaces > > > > > >case. I > > > > > > > raised this question before, but we have not had much > >discussion > > > >on > > > > > >it. In > > > > > > > any case, address translation part of CARD will be required in > > > >this > > > > > >case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically > >delivers > > > >the > > > > > >AP or AR L2 identifier to which the MN will be handed over. This > > > > > >information is required (by the MIP fast handover algorithms) at > >the > > > > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > > > > >reverse address translation in order that it can contact the > >other > > > >AR. > > > > > >Capabilities aren't involved, except to the extent that the MN > >can > > > >hear > > > > > >multiple L2s and make the decision. But this is exactly the same > >as > > > >for > > > > > >the intertechnology case. > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > _________________________________________________________________ > 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 Fri Apr 19 12:34: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 MAA00009 for ; Fri, 19 Apr 2002 12:34:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24724 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 12:34:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23642; Fri, 19 Apr 2002 12:24:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23609 for ; Fri, 19 Apr 2002 12:24:56 -0400 (EDT) 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 MAA28404 for ; Fri, 19 Apr 2002 12:24:52 -0400 (EDT) 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 g3JGOAI05935; Fri, 19 Apr 2002 09:24:10 -0700 (PDT) Message-ID: <01ab01c1e7be$6a950c80$746015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 09:22:31 -0700 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 Nobody can prevent someone from deploying the CARD on an AR. The point is the requirements should be clear that the primary function is for the MN. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; ; Sent: Friday, April 19, 2002 8:19 AM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > Hi Karim: > > I am trying to understand the algorithmic perspective of the comment below > saying that "The MN should take the decision with hints from the network, > not the other way round." > > So, if there is an application on MN processor which takes one input as MN > requirements and other input as AR capabilities and provides certain output > (say boolean yes or no), is it acceptable approach? I guess yes. > > Now, suppose that there is this *same* application somewhere on processor of > some network entity taking the *same* inputs as above and providing the same > kind of output, is it acceptable approach? I guess it should be. > > So, is it the input and output information model of the application that > decides whether the approach in MN-centric or is it the location of the > processor executing the application as such that decides whether the > approach is MN-centric? I guess it is the former. > > Hemant > > > >From: "Karim El-Malki (ERA)" > >To: "'Govind Krishnamurthi'" , seamoby@ietf.org > >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Fri, 19 Apr 2002 10:44:39 +0200 > > > > > I wasn't > > > >ruling out network involvement, but I couldn't understand why there > > > >was work on ARs only doing CAR discovery. Hope my point is > > > more clear > > > >now. Maybe I misinterpreted some emails and people are in agreement > > > >with this. I think Dirk's email at least was in line with what I > > > >have above (i.e. we need to focus on the MN's role and allow the > > > >network to assist where needed). > > > > > > [Govind] The main point is that the MNs requirements should be > > > taken into consideration when deciding on the TARs whether this > > > happens in the network or in the MN is upto the individual solution > > > (as long as it satisfies the requirements). > > > Hope these clarifies your concerns. > > > >Sorry I'm falling behind on this discussion and haven't read all the > >emails, > >but the point was that the decision is to be taken by the MN, not by the > >network. So what you write above about the decision happening in the > >network > >does not follow from the discussion so far. The MN should take the decision > >with hints from the network, not the other way round. > > > >/K. > > > >_______________________________________________ > >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 Fri Apr 19 13:15: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 NAA05390 for ; Fri, 19 Apr 2002 13:15:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26324; Fri, 19 Apr 2002 13:04:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26294 for ; Fri, 19 Apr 2002 13:04:21 -0400 (EDT) Received: from hotmail.com (f51.law7.hotmail.com [216.33.237.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04383 for ; Fri, 19 Apr 2002 13:04:19 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 10:03:46 -0700 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 17:03:45 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 17:03:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 17:03:46.0033 (UTC) FILETIME=[2AC64E10:01C1E7C4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: L2 beacons have nothing to do with CAR discovery. I would like to understand however if the capability set of ARs behind those beacons is important or not. If it is, it has to be indentified by CAR discovery protocol. If that is the case, then there needs to be a creative implementation of CAR discovery protocol for the case that this thread is concerned with, namely, MN having single NIC and not being able to communicate with ARs behind those L2 beacons without letting go the old connection (the difficulty persists even if MN gets IP addresses in beacons). Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Fri, 19 Apr 2002 09:18:53 -0700 > >I don't see what L2 beacons has to do with CAR discovery. The issue is >what ARs the MN has access to and what are their capabilities. How the >MN chooses to use that in the context of a particular L2 is up to the >MN. >The ARs may be identified by their L2 identifier or by an IP address. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Friday, April 19, 2002 8:12 AM >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James, > > > > TAR is not in scope. I am talking about identifying capabilities of >ARs (or > > identifying match between capabilities of these ARs and MN's >requirements) > > that govern these L2 beacons. > > > > So, is it in scope of CAR discovery or we delegate the matter to IEEE? > > > > Hemant > > > > > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > > > >Hemant, > > > > > >Remember, TAR is not in scope. > > > > > >As a practical matter, I believe the 802.11 standard should provide >some > > >guidance, currently it doesn't. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Wednesday, April 17, 2002 2:45 PM > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > Hi James: > > > > > > > > If there are more than one L2 beacons available (of comparable >signal > > > > strength), probably governed by different ARs, how do we choose? I >do > > >not > > > > have problem choosing randomly, but just want to confirm if this >is > > >the way > > > > we want to proceed. > > > > > > > > There is no doubt that handoff is necessary as old link will fade, >but > > >you > > > > still have choice as to which new beacon to hold on to. > > > > > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > > > >Right, that's what I'm saying. There is one case where the MN >needs > > >to > > > > >choose, and the other where the MN and AR get an L2 address and >don't > > > > >have a choice. The handover happens because, if not, the power >will > > >fade > > > > >and the MN loses link connectivity. > > > > > > > > > >The former case might require capabilities, the latter just >requires > > > > >cross link ARP. > > > > > > > > > > jak > > > > > > > > > >----- Original Message ----- > > > > >From: "Hemant Chaskar" > > > > >To: ; > > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > > >equivalent > > > > >to > > > > > > inter-technology case? I do not get the point. Why can't the >MN > > >listen > > > > >to > > > > > > different L2 beacons of the same technology? I guess it can, >and > > > > >hence, it > > > > > > still needs to chose one among them for handoff. Then the >issue is > > > > >exactly > > > > > > the same as Glenn raised for single NIC case: How to get > > >capabilities > > > > > > without letting go the old connection? Of course, I am >assuming > > >that > > > > >these > > > > > > L2's have comparable signal strengths. > > > > > > > > > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Hemant Chaskar" , > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > > >It seems that the minutes indicate that people have >somehow > > >come > > > > >to a > > > > > > > > >conclusion that there is no need for access routers to > > >divulge > > > > >that > > > > > > >they > > > > > > > > >are > > > > > > > > >geographically adjancent to themselves via the IP > > >infrastructure. > > > > >The > > > > > > > > >minutes also seem to indicate that the mobile alone >should be > > >the > > > > > > >only way > > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > > >O.K. If this is true then how will a mobile pass this > > >information > > > > >to > > > > > > >their > > > > > > > > >source AR if the mobile only has one NIC and that NIC is >only > > > > >capable > > > > > > >of > > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. >What I > > > > >would > > > > > > >really > > > > > > > > like to understand is whether the above is a relevant case >for > > >CAR > > > > > > >discovery > > > > > > > > or we simply neglect it and focus only on two physical > > >interfaces > > > > > > >case. I > > > > > > > > raised this question before, but we have not had much > > >discussion > > > > >on > > > > > > >it. In > > > > > > > > any case, address translation part of CARD will be >required in > > > > >this > > > > > > >case for > > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically > > >delivers > > > > >the > > > > > > >AP or AR L2 identifier to which the MN will be handed over. >This > > > > > > >information is required (by the MIP fast handover algorithms) >at > > >the > > > > > > >MN's AR. So the issue is fairly simple: the AR must be able >to do > > > > > > >reverse address translation in order that it can contact the > > >other > > > > >AR. > > > > > > >Capabilities aren't involved, except to the extent that the >MN > > >can > > > > >hear > > > > > > >multiple L2s and make the decision. But this is exactly the >same > > >as > > > > >for > > > > > > >the intertechnology case. > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > _________________________________________________________________ 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 Fri Apr 19 13: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 NAA05404 for ; Fri, 19 Apr 2002 13:15:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27087 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 13:15:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26324; Fri, 19 Apr 2002 13:04:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26294 for ; Fri, 19 Apr 2002 13:04:21 -0400 (EDT) Received: from hotmail.com (f51.law7.hotmail.com [216.33.237.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04383 for ; Fri, 19 Apr 2002 13:04:19 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 10:03:46 -0700 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 17:03:45 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 17:03:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 17:03:46.0033 (UTC) FILETIME=[2AC64E10:01C1E7C4] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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: L2 beacons have nothing to do with CAR discovery. I would like to understand however if the capability set of ARs behind those beacons is important or not. If it is, it has to be indentified by CAR discovery protocol. If that is the case, then there needs to be a creative implementation of CAR discovery protocol for the case that this thread is concerned with, namely, MN having single NIC and not being able to communicate with ARs behind those L2 beacons without letting go the old connection (the difficulty persists even if MN gets IP addresses in beacons). Hemant >From: "James Kempf" >To: "Hemant Chaskar" , >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 >Date: Fri, 19 Apr 2002 09:18:53 -0700 > >I don't see what L2 beacons has to do with CAR discovery. The issue is >what ARs the MN has access to and what are their capabilities. How the >MN chooses to use that in the context of a particular L2 is up to the >MN. >The ARs may be identified by their L2 identifier or by an IP address. > > jak > >----- Original Message ----- >From: "Hemant Chaskar" >To: ; >Sent: Friday, April 19, 2002 8:12 AM >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James, > > > > TAR is not in scope. I am talking about identifying capabilities of >ARs (or > > identifying match between capabilities of these ARs and MN's >requirements) > > that govern these L2 beacons. > > > > So, is it in scope of CAR discovery or we delegate the matter to IEEE? > > > > Hemant > > > > > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > > > >Hemant, > > > > > >Remember, TAR is not in scope. > > > > > >As a practical matter, I believe the 802.11 standard should provide >some > > >guidance, currently it doesn't. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Wednesday, April 17, 2002 2:45 PM > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > Hi James: > > > > > > > > If there are more than one L2 beacons available (of comparable >signal > > > > strength), probably governed by different ARs, how do we choose? I >do > > >not > > > > have problem choosing randomly, but just want to confirm if this >is > > >the way > > > > we want to proceed. > > > > > > > > There is no doubt that handoff is necessary as old link will fade, >but > > >you > > > > still have choice as to which new beacon to hold on to. > > > > > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > > > >Right, that's what I'm saying. There is one case where the MN >needs > > >to > > > > >choose, and the other where the MN and AR get an L2 address and >don't > > > > >have a choice. The handover happens because, if not, the power >will > > >fade > > > > >and the MN loses link connectivity. > > > > > > > > > >The former case might require capabilities, the latter just >requires > > > > >cross link ARP. > > > > > > > > > > jak > > > > > > > > > >----- Original Message ----- > > > > >From: "Hemant Chaskar" > > > > >To: ; > > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > > >equivalent > > > > >to > > > > > > inter-technology case? I do not get the point. Why can't the >MN > > >listen > > > > >to > > > > > > different L2 beacons of the same technology? I guess it can, >and > > > > >hence, it > > > > > > still needs to chose one among them for handoff. Then the >issue is > > > > >exactly > > > > > > the same as Glenn raised for single NIC case: How to get > > >capabilities > > > > > > without letting go the old connection? Of course, I am >assuming > > >that > > > > >these > > > > > > L2's have comparable signal strengths. > > > > > > > > > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Hemant Chaskar" , > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > > >It seems that the minutes indicate that people have >somehow > > >come > > > > >to a > > > > > > > > >conclusion that there is no need for access routers to > > >divulge > > > > >that > > > > > > >they > > > > > > > > >are > > > > > > > > >geographically adjancent to themselves via the IP > > >infrastructure. > > > > >The > > > > > > > > >minutes also seem to indicate that the mobile alone >should be > > >the > > > > > > >only way > > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > > >O.K. If this is true then how will a mobile pass this > > >information > > > > >to > > > > > > >their > > > > > > > > >source AR if the mobile only has one NIC and that NIC is >only > > > > >capable > > > > > > >of > > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. >What I > > > > >would > > > > > > >really > > > > > > > > like to understand is whether the above is a relevant case >for > > >CAR > > > > > > >discovery > > > > > > > > or we simply neglect it and focus only on two physical > > >interfaces > > > > > > >case. I > > > > > > > > raised this question before, but we have not had much > > >discussion > > > > >on > > > > > > >it. In > > > > > > > > any case, address translation part of CARD will be >required in > > > > >this > > > > > > >case for > > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically > > >delivers > > > > >the > > > > > > >AP or AR L2 identifier to which the MN will be handed over. >This > > > > > > >information is required (by the MIP fast handover algorithms) >at > > >the > > > > > > >MN's AR. So the issue is fairly simple: the AR must be able >to do > > > > > > >reverse address translation in order that it can contact the > > >other > > > > >AR. > > > > > > >Capabilities aren't involved, except to the extent that the >MN > > >can > > > > >hear > > > > > > >multiple L2s and make the decision. But this is exactly the >same > > >as > > > > >for > > > > > > >the intertechnology case. > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > _________________________________________________________________ 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 Fri Apr 19 13:32: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 MAA29989 for ; Fri, 19 Apr 2002 12:34:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23642; Fri, 19 Apr 2002 12:24:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23609 for ; Fri, 19 Apr 2002 12:24:56 -0400 (EDT) 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 MAA28404 for ; Fri, 19 Apr 2002 12:24:52 -0400 (EDT) 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 g3JGOAI05935; Fri, 19 Apr 2002 09:24:10 -0700 (PDT) Message-ID: <01ab01c1e7be$6a950c80$746015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 09:22:31 -0700 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 Nobody can prevent someone from deploying the CARD on an AR. The point is the requirements should be clear that the primary function is for the MN. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; ; Sent: Friday, April 19, 2002 8:19 AM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > Hi Karim: > > I am trying to understand the algorithmic perspective of the comment below > saying that "The MN should take the decision with hints from the network, > not the other way round." > > So, if there is an application on MN processor which takes one input as MN > requirements and other input as AR capabilities and provides certain output > (say boolean yes or no), is it acceptable approach? I guess yes. > > Now, suppose that there is this *same* application somewhere on processor of > some network entity taking the *same* inputs as above and providing the same > kind of output, is it acceptable approach? I guess it should be. > > So, is it the input and output information model of the application that > decides whether the approach in MN-centric or is it the location of the > processor executing the application as such that decides whether the > approach is MN-centric? I guess it is the former. > > Hemant > > > >From: "Karim El-Malki (ERA)" > >To: "'Govind Krishnamurthi'" , seamoby@ietf.org > >Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Fri, 19 Apr 2002 10:44:39 +0200 > > > > > I wasn't > > > >ruling out network involvement, but I couldn't understand why there > > > >was work on ARs only doing CAR discovery. Hope my point is > > > more clear > > > >now. Maybe I misinterpreted some emails and people are in agreement > > > >with this. I think Dirk's email at least was in line with what I > > > >have above (i.e. we need to focus on the MN's role and allow the > > > >network to assist where needed). > > > > > > [Govind] The main point is that the MNs requirements should be > > > taken into consideration when deciding on the TARs whether this > > > happens in the network or in the MN is upto the individual solution > > > (as long as it satisfies the requirements). > > > Hope these clarifies your concerns. > > > >Sorry I'm falling behind on this discussion and haven't read all the > >emails, > >but the point was that the decision is to be taken by the MN, not by the > >network. So what you write above about the decision happening in the > >network > >does not follow from the discussion so far. The MN should take the decision > >with hints from the network, not the other way round. > > > >/K. > > > >_______________________________________________ > >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 Fri Apr 19 13:32: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 MAA29342 for ; Fri, 19 Apr 2002 12:30:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24254 for seamoby-archive@odin.ietf.org; Fri, 19 Apr 2002 12:30:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23456; Fri, 19 Apr 2002 12:21:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23428 for ; Fri, 19 Apr 2002 12:21:06 -0400 (EDT) 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 MAA27810 for ; Fri, 19 Apr 2002 12:21:02 -0400 (EDT) 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 g3JGKVI05775; Fri, 19 Apr 2002 09:20:32 -0700 (PDT) Message-ID: <019d01c1e7bd$e7d00750$746015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 19 Apr 2002 09:18:53 -0700 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 what L2 beacons has to do with CAR discovery. The issue is what ARs the MN has access to and what are their capabilities. How the MN chooses to use that in the context of a particular L2 is up to the MN. The ARs may be identified by their L2 identifier or by an IP address. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Friday, April 19, 2002 8:12 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James, > > TAR is not in scope. I am talking about identifying capabilities of ARs (or > identifying match between capabilities of these ARs and MN's requirements) > that govern these L2 beacons. > > So, is it in scope of CAR discovery or we delegate the matter to IEEE? > > Hemant > > > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > >Hemant, > > > >Remember, TAR is not in scope. > > > >As a practical matter, I believe the 802.11 standard should provide some > >guidance, currently it doesn't. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Wednesday, April 17, 2002 2:45 PM > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > Hi James: > > > > > > If there are more than one L2 beacons available (of comparable signal > > > strength), probably governed by different ARs, how do we choose? I do > >not > > > have problem choosing randomly, but just want to confirm if this is > >the way > > > we want to proceed. > > > > > > There is no doubt that handoff is necessary as old link will fade, but > >you > > > still have choice as to which new beacon to hold on to. > > > > > > Hemant > > > > > > > > > >From: "James Kempf" > > > >To: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > >Right, that's what I'm saying. There is one case where the MN needs > >to > > > >choose, and the other where the MN and AR get an L2 address and don't > > > >have a choice. The handover happens because, if not, the power will > >fade > > > >and the MN loses link connectivity. > > > > > > > >The former case might require capabilities, the latter just requires > > > >cross link ARP. > > > > > > > > jak > > > > > > > >----- Original Message ----- > > > >From: "Hemant Chaskar" > > > >To: ; > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > Hi James: > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > >equivalent > > > >to > > > > > inter-technology case? I do not get the point. Why can't the MN > >listen > > > >to > > > > > different L2 beacons of the same technology? I guess it can, and > > > >hence, it > > > > > still needs to chose one among them for handoff. Then the issue is > > > >exactly > > > > > the same as Glenn raised for single NIC case: How to get > >capabilities > > > > > without letting go the old connection? Of course, I am assuming > >that > > > >these > > > > > L2's have comparable signal strengths. > > > > > > > > > > Hemant > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Hemant Chaskar" , > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > >It seems that the minutes indicate that people have somehow > >come > > > >to a > > > > > > > >conclusion that there is no need for access routers to > >divulge > > > >that > > > > > >they > > > > > > > >are > > > > > > > >geographically adjancent to themselves via the IP > >infrastructure. > > > >The > > > > > > > >minutes also seem to indicate that the mobile alone should be > >the > > > > > >only way > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > >O.K. If this is true then how will a mobile pass this > >information > > > >to > > > > > >their > > > > > > > >source AR if the mobile only has one NIC and that NIC is only > > > >capable > > > > > >of > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. What I > > > >would > > > > > >really > > > > > > > like to understand is whether the above is a relevant case for > >CAR > > > > > >discovery > > > > > > > or we simply neglect it and focus only on two physical > >interfaces > > > > > >case. I > > > > > > > raised this question before, but we have not had much > >discussion > > > >on > > > > > >it. In > > > > > > > any case, address translation part of CARD will be required in > > > >this > > > > > >case for > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically > >delivers > > > >the > > > > > >AP or AR L2 identifier to which the MN will be handed over. This > > > > > >information is required (by the MIP fast handover algorithms) at > >the > > > > > >MN's AR. So the issue is fairly simple: the AR must be able to do > > > > > >reverse address translation in order that it can contact the > >other > > > >AR. > > > > > >Capabilities aren't involved, except to the extent that the MN > >can > > > >hear > > > > > >multiple L2s and make the decision. But this is exactly the same > >as > > > >for > > > > > >the intertechnology case. > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > _________________________________________________________________ > 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 Sat Apr 20 07:43: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 HAA00983 for ; Sat, 20 Apr 2002 07:43:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24990; Sat, 20 Apr 2002 07:35:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24960 for ; Sat, 20 Apr 2002 07:35:49 -0400 (EDT) Received: from c007.snv.cp.net (h000.c007.snv.cp.net [209.228.33.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00961 for ; Sat, 20 Apr 2002 07:35:46 -0400 (EDT) Received: (cpmta 26790 invoked from network); 20 Apr 2002 04:35:17 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.228) with SMTP; 20 Apr 2002 04:35:17 -0700 X-Sent: 20 Apr 2002 11:35:17 GMT Message-ID: <001101c1e85f$704f0ad0$35e1bb41@Study> From: "Phil Neumiller" To: "Hemant Chaskar" , , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sat, 20 Apr 2002 07:35:13 -0400 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 Some comments... ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Friday, April 19, 2002 1:03 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > L2 beacons have nothing to do with CAR discovery. This would be one thing that I "would" create an L2->L3 trigger for. This is really important. You want a real tight interface between CAR and the radio. If we throw this out, CAR becomes pretty useless IMO. In addition to the beacon itself, link quality assesment would be essential too. Thanks, Phil _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Apr 20 07:43: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 HAA00992 for ; Sat, 20 Apr 2002 07:43:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25092 for seamoby-archive@odin.ietf.org; Sat, 20 Apr 2002 07:43:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24990; Sat, 20 Apr 2002 07:35:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24960 for ; Sat, 20 Apr 2002 07:35:49 -0400 (EDT) Received: from c007.snv.cp.net (h000.c007.snv.cp.net [209.228.33.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00961 for ; Sat, 20 Apr 2002 07:35:46 -0400 (EDT) Received: (cpmta 26790 invoked from network); 20 Apr 2002 04:35:17 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.228) with SMTP; 20 Apr 2002 04:35:17 -0700 X-Sent: 20 Apr 2002 11:35:17 GMT Message-ID: <001101c1e85f$704f0ad0$35e1bb41@Study> From: "Phil Neumiller" To: "Hemant Chaskar" , , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sat, 20 Apr 2002 07:35:13 -0400 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 Some comments... ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Friday, April 19, 2002 1:03 PM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > L2 beacons have nothing to do with CAR discovery. This would be one thing that I "would" create an L2->L3 trigger for. This is really important. You want a real tight interface between CAR and the radio. If we throw this out, CAR becomes pretty useless IMO. In addition to the beacon itself, link quality assesment would be essential too. Thanks, Phil _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Apr 20 08:37: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 IAA01696 for ; Sat, 20 Apr 2002 08:37:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26371; Sat, 20 Apr 2002 08:28:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26339 for ; Sat, 20 Apr 2002 08:28:44 -0400 (EDT) From: owner-seamoby@optimus.ietf.org Received: from mail.friendlycity.net ([66.28.168.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01518 for ; Sat, 20 Apr 2002 08:28:41 -0400 (EDT) Received: from nbc2.nbctifton.org (NBC.cm.friendlycity.net [66.28.173.28]) by mail.friendlycity.net (8.11.2/8.11.2) with SMTP id g3KCdII28705 for ; Sat, 20 Apr 2002 08:39:18 -0400 Message-Id: <200204201239.g3KCdII28705@mail.friendlycity.net> Received: from smtp0572.mail.yahoo.com ([218.24.129.167]) by nbc2.nbctifton.org; Sat, 20 Apr 2002 08:25:54 -0400 Date: Sat, 20 Apr 2002 20:29:25 +0800 X-Priority: 3 To: seamobutts@hotmail.com CC: seamoby@ietf.org, seamoe@hotmail.com, seamohr107@aol.com, seamohr@hotmail.com Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Aging can be reversed with HGH Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, seamobutts@hotmail.com,

As seen on NBC, CBS, CNN, and even Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has even been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed!


Click here

Would you like to lose weight while you sleep!
No dieting!
No hunger pains!
No Cravings!
No strenuous exercise!
Change your life forever!

1.Body Fat Loss 82% improvement.
2.Wrinkle Reduction 61% improvement.
3.Energy Level 84% improvement.
4.Muscle Strength 88% improvement.
5.Sexual Potency 75% improvement.
6.Emotional Stability 67% improvement.
7.Memory 62% improvement.

100% GUARANTEED!

 

You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here

_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sat Apr 20 09:25: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 IAA01703 for ; Sat, 20 Apr 2002 08:37:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26928 for seamoby-archive@odin.ietf.org; Sat, 20 Apr 2002 08:37:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26371; Sat, 20 Apr 2002 08:28:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26339 for ; Sat, 20 Apr 2002 08:28:44 -0400 (EDT) From: owner-seamoby@optimus.ietf.org Received: from mail.friendlycity.net ([66.28.168.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01518 for ; Sat, 20 Apr 2002 08:28:41 -0400 (EDT) Received: from nbc2.nbctifton.org (NBC.cm.friendlycity.net [66.28.173.28]) by mail.friendlycity.net (8.11.2/8.11.2) with SMTP id g3KCdII28705 for ; Sat, 20 Apr 2002 08:39:18 -0400 Message-Id: <200204201239.g3KCdII28705@mail.friendlycity.net> Received: from smtp0572.mail.yahoo.com ([218.24.129.167]) by nbc2.nbctifton.org; Sat, 20 Apr 2002 08:25:54 -0400 Date: Sat, 20 Apr 2002 20:29:25 +0800 X-Priority: 3 To: seamobutts@hotmail.com CC: seamoby@ietf.org, seamoe@hotmail.com, seamohr107@aol.com, seamohr@hotmail.com Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Aging can be reversed with HGH Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, seamobutts@hotmail.com,

As seen on NBC, CBS, CNN, and even Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has even been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed!


Click here

Would you like to lose weight while you sleep!
No dieting!
No hunger pains!
No Cravings!
No strenuous exercise!
Change your life forever!

1.Body Fat Loss 82% improvement.
2.Wrinkle Reduction 61% improvement.
3.Energy Level 84% improvement.
4.Muscle Strength 88% improvement.
5.Sexual Potency 75% improvement.
6.Emotional Stability 67% improvement.
7.Memory 62% improvement.

100% GUARANTEED!

 

You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here

_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sat Apr 20 13:54: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 NAA05235 for ; Sat, 20 Apr 2002 13:54:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06800; Sat, 20 Apr 2002 13:05:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06772 for ; Sat, 20 Apr 2002 13:05:35 -0400 (EDT) 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 NAA04486 for ; Sat, 20 Apr 2002 13:05:32 -0400 (EDT) Received: from T23KEMPF (dhcp169.docomolabs-usa.com [172.21.96.169]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3KGV0I19640; Sat, 20 Apr 2002 09:31:00 -0700 (PDT) Message-ID: <002101c1e888$8908b4d0$a96015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sat, 20 Apr 2002 08:50:54 -0700 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 see two cases for CAR discovery. Simple case is L2 trigger on the AR or MN delivers an L2 identifier for the new AR or AP, AR or MN must map to IP address of new AR. This is essentially cross link reverse ARP and the MN doesn't have any choice about where it is going because it is moved by the Layer 2. Complex case is MN wants to find out what's available, uses CAR discovery to find an AR for the wireless medium/QoS/etc. that matches its preferences. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Friday, April 19, 2002 10:03 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > L2 beacons have nothing to do with CAR discovery. I would like to understand > however if the capability set of ARs behind those beacons is important or > not. If it is, it has to be indentified by CAR discovery protocol. If that > is the case, then there needs to be a creative implementation of CAR > discovery protocol for the case that this thread is concerned with, namely, > MN having single NIC and not being able to communicate with ARs behind those > L2 beacons without letting go the old connection (the difficulty persists > even if MN gets IP addresses in beacons). > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Fri, 19 Apr 2002 09:18:53 -0700 > > > >I don't see what L2 beacons has to do with CAR discovery. The issue is > >what ARs the MN has access to and what are their capabilities. How the > >MN chooses to use that in the context of a particular L2 is up to the > >MN. > >The ARs may be identified by their L2 identifier or by an IP address. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Friday, April 19, 2002 8:12 AM > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > Hi James, > > > > > > TAR is not in scope. I am talking about identifying capabilities of > >ARs (or > > > identifying match between capabilities of these ARs and MN's > >requirements) > > > that govern these L2 beacons. > > > > > > So, is it in scope of CAR discovery or we delegate the matter to IEEE? > > > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > >To: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > > > > > >Hemant, > > > > > > > >Remember, TAR is not in scope. > > > > > > > >As a practical matter, I believe the 802.11 standard should provide > >some > > > >guidance, currently it doesn't. > > > > > > > > jak > > > > > > > >----- Original Message ----- > > > >From: "Hemant Chaskar" > > > >To: ; > > > >Sent: Wednesday, April 17, 2002 2:45 PM > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > Hi James: > > > > > > > > > > If there are more than one L2 beacons available (of comparable > >signal > > > > > strength), probably governed by different ARs, how do we choose? I > >do > > > >not > > > > > have problem choosing randomly, but just want to confirm if this > >is > > > >the way > > > > > we want to proceed. > > > > > > > > > > There is no doubt that handoff is necessary as old link will fade, > >but > > > >you > > > > > still have choice as to which new beacon to hold on to. > > > > > > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Hemant Chaskar" , > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > > > > > >Right, that's what I'm saying. There is one case where the MN > >needs > > > >to > > > > > >choose, and the other where the MN and AR get an L2 address and > >don't > > > > > >have a choice. The handover happens because, if not, the power > >will > > > >fade > > > > > >and the MN loses link connectivity. > > > > > > > > > > > >The former case might require capabilities, the latter just > >requires > > > > > >cross link ARP. > > > > > > > > > > > > jak > > > > > > > > > > > >----- Original Message ----- > > > > > >From: "Hemant Chaskar" > > > > > >To: ; > > > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > > > >equivalent > > > > > >to > > > > > > > inter-technology case? I do not get the point. Why can't the > >MN > > > >listen > > > > > >to > > > > > > > different L2 beacons of the same technology? I guess it can, > >and > > > > > >hence, it > > > > > > > still needs to chose one among them for handoff. Then the > >issue is > > > > > >exactly > > > > > > > the same as Glenn raised for single NIC case: How to get > > > >capabilities > > > > > > > without letting go the old connection? Of course, I am > >assuming > > > >that > > > > > >these > > > > > > > L2's have comparable signal strengths. > > > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > > >To: "Hemant Chaskar" , > > > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > > > >It seems that the minutes indicate that people have > >somehow > > > >come > > > > > >to a > > > > > > > > > >conclusion that there is no need for access routers to > > > >divulge > > > > > >that > > > > > > > >they > > > > > > > > > >are > > > > > > > > > >geographically adjancent to themselves via the IP > > > >infrastructure. > > > > > >The > > > > > > > > > >minutes also seem to indicate that the mobile alone > >should be > > > >the > > > > > > > >only way > > > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > > > >O.K. If this is true then how will a mobile pass this > > > >information > > > > > >to > > > > > > > >their > > > > > > > > > >source AR if the mobile only has one NIC and that NIC is > >only > > > > > >capable > > > > > > > >of > > > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. > >What I > > > > > >would > > > > > > > >really > > > > > > > > > like to understand is whether the above is a relevant case > >for > > > >CAR > > > > > > > >discovery > > > > > > > > > or we simply neglect it and focus only on two physical > > > >interfaces > > > > > > > >case. I > > > > > > > > > raised this question before, but we have not had much > > > >discussion > > > > > >on > > > > > > > >it. In > > > > > > > > > any case, address translation part of CARD will be > >required in > > > > > >this > > > > > > > >case for > > > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically > > > >delivers > > > > > >the > > > > > > > >AP or AR L2 identifier to which the MN will be handed over. > >This > > > > > > > >information is required (by the MIP fast handover algorithms) > >at > > > >the > > > > > > > >MN's AR. So the issue is fairly simple: the AR must be able > >to do > > > > > > > >reverse address translation in order that it can contact the > > > >other > > > > > >AR. > > > > > > > >Capabilities aren't involved, except to the extent that the > >MN > > > >can > > > > > >hear > > > > > > > >multiple L2s and make the decision. But this is exactly the > >same > > > >as > > > > > >for > > > > > > > >the intertechnology case. > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > > > > _________________________________________________________________ > 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 Sat Apr 20 13:54: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 NAA05247 for ; Sat, 20 Apr 2002 13:54:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08477 for seamoby-archive@odin.ietf.org; Sat, 20 Apr 2002 13:54:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06800; Sat, 20 Apr 2002 13:05:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06772 for ; Sat, 20 Apr 2002 13:05:35 -0400 (EDT) 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 NAA04486 for ; Sat, 20 Apr 2002 13:05:32 -0400 (EDT) Received: from T23KEMPF (dhcp169.docomolabs-usa.com [172.21.96.169]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3KGV0I19640; Sat, 20 Apr 2002 09:31:00 -0700 (PDT) Message-ID: <002101c1e888$8908b4d0$a96015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sat, 20 Apr 2002 08:50:54 -0700 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 see two cases for CAR discovery. Simple case is L2 trigger on the AR or MN delivers an L2 identifier for the new AR or AP, AR or MN must map to IP address of new AR. This is essentially cross link reverse ARP and the MN doesn't have any choice about where it is going because it is moved by the Layer 2. Complex case is MN wants to find out what's available, uses CAR discovery to find an AR for the wireless medium/QoS/etc. that matches its preferences. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Sent: Friday, April 19, 2002 10:03 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > Hi James: > > L2 beacons have nothing to do with CAR discovery. I would like to understand > however if the capability set of ARs behind those beacons is important or > not. If it is, it has to be indentified by CAR discovery protocol. If that > is the case, then there needs to be a creative implementation of CAR > discovery protocol for the case that this thread is concerned with, namely, > MN having single NIC and not being able to communicate with ARs behind those > L2 beacons without letting go the old connection (the difficulty persists > even if MN gets IP addresses in beacons). > > Hemant > > >From: "James Kempf" > >To: "Hemant Chaskar" , > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > >Date: Fri, 19 Apr 2002 09:18:53 -0700 > > > >I don't see what L2 beacons has to do with CAR discovery. The issue is > >what ARs the MN has access to and what are their capabilities. How the > >MN chooses to use that in the context of a particular L2 is up to the > >MN. > >The ARs may be identified by their L2 identifier or by an IP address. > > > > jak > > > >----- Original Message ----- > >From: "Hemant Chaskar" > >To: ; > >Sent: Friday, April 19, 2002 8:12 AM > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > Hi James, > > > > > > TAR is not in scope. I am talking about identifying capabilities of > >ARs (or > > > identifying match between capabilities of these ARs and MN's > >requirements) > > > that govern these L2 beacons. > > > > > > So, is it in scope of CAR discovery or we delegate the matter to IEEE? > > > > > > Hemant > > > > > > > > > > > > >From: "James Kempf" > > > >To: "Hemant Chaskar" , > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > > > > > >Hemant, > > > > > > > >Remember, TAR is not in scope. > > > > > > > >As a practical matter, I believe the 802.11 standard should provide > >some > > > >guidance, currently it doesn't. > > > > > > > > jak > > > > > > > >----- Original Message ----- > > > >From: "Hemant Chaskar" > > > >To: ; > > > >Sent: Wednesday, April 17, 2002 2:45 PM > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > Hi James: > > > > > > > > > > If there are more than one L2 beacons available (of comparable > >signal > > > > > strength), probably governed by different ARs, how do we choose? I > >do > > > >not > > > > > have problem choosing randomly, but just want to confirm if this > >is > > > >the way > > > > > we want to proceed. > > > > > > > > > > There is no doubt that handoff is necessary as old link will fade, > >but > > > >you > > > > > still have choice as to which new beacon to hold on to. > > > > > > > > > > Hemant > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > >To: "Hemant Chaskar" , > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > > > > > >Right, that's what I'm saying. There is one case where the MN > >needs > > > >to > > > > > >choose, and the other where the MN and AR get an L2 address and > >don't > > > > > >have a choice. The handover happens because, if not, the power > >will > > > >fade > > > > > >and the MN loses link connectivity. > > > > > > > > > > > >The former case might require capabilities, the latter just > >requires > > > > > >cross link ARP. > > > > > > > > > > > > jak > > > > > > > > > > > >----- Original Message ----- > > > > > >From: "Hemant Chaskar" > > > > > >To: ; > > > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > > > >equivalent > > > > > >to > > > > > > > inter-technology case? I do not get the point. Why can't the > >MN > > > >listen > > > > > >to > > > > > > > different L2 beacons of the same technology? I guess it can, > >and > > > > > >hence, it > > > > > > > still needs to chose one among them for handoff. Then the > >issue is > > > > > >exactly > > > > > > > the same as Glenn raised for single NIC case: How to get > > > >capabilities > > > > > > > without letting go the old connection? Of course, I am > >assuming > > > >that > > > > > >these > > > > > > > L2's have comparable signal strengths. > > > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > > >To: "Hemant Chaskar" , > > > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > > > >It seems that the minutes indicate that people have > >somehow > > > >come > > > > > >to a > > > > > > > > > >conclusion that there is no need for access routers to > > > >divulge > > > > > >that > > > > > > > >they > > > > > > > > > >are > > > > > > > > > >geographically adjancent to themselves via the IP > > > >infrastructure. > > > > > >The > > > > > > > > > >minutes also seem to indicate that the mobile alone > >should be > > > >the > > > > > > > >only way > > > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > > > >O.K. If this is true then how will a mobile pass this > > > >information > > > > > >to > > > > > > > >their > > > > > > > > > >source AR if the mobile only has one NIC and that NIC is > >only > > > > > >capable > > > > > > > >of > > > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. > >What I > > > > > >would > > > > > > > >really > > > > > > > > > like to understand is whether the above is a relevant case > >for > > > >CAR > > > > > > > >discovery > > > > > > > > > or we simply neglect it and focus only on two physical > > > >interfaces > > > > > > > >case. I > > > > > > > > > raised this question before, but we have not had much > > > >discussion > > > > > >on > > > > > > > >it. In > > > > > > > > > any case, address translation part of CARD will be > >required in > > > > > >this > > > > > > > >case for > > > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 typically > > > >delivers > > > > > >the > > > > > > > >AP or AR L2 identifier to which the MN will be handed over. > >This > > > > > > > >information is required (by the MIP fast handover algorithms) > >at > > > >the > > > > > > > >MN's AR. So the issue is fairly simple: the AR must be able > >to do > > > > > > > >reverse address translation in order that it can contact the > > > >other > > > > > >AR. > > > > > > > >Capabilities aren't involved, except to the extent that the > >MN > > > >can > > > > > >hear > > > > > > > >multiple L2s and make the decision. But this is exactly the > >same > > > >as > > > > > >for > > > > > > > >the intertechnology case. > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > > > > _________________________________________________________________ > 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 Sun Apr 21 00:21: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 AAA12523 for ; Sun, 21 Apr 2002 00:21:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28612; Sun, 21 Apr 2002 00:02:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28579 for ; Sun, 21 Apr 2002 00:02:14 -0400 (EDT) Received: from hotmail.com (oe18.law4.hotmail.com [216.33.148.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12411 for ; Sun, 21 Apr 2002 00:02:13 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Apr 2002 21:01:42 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "James Kempf" , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <000201c1e763$d05710f0$4c6015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 13:06:46 -0700 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: 21 Apr 2002 04:01:42.0773 (UTC) FILETIME=[3F288A50:01C1E8E9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Thanks for the information. Could you tell us, if possible, how the IP address of the target address is discovered in your experiment with the IS-2000 RAN? Also how can the mobile utilize the BSSid to find the FA or AR address without asking the current AR in 802.11? Don't we need something like the CAR discovery protocol eventually? I assume the mobile does not receive the Agent Advertisement messages of the target AR in the above question. Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; "Karim El-Malki (ERA)" ; "'Hemant Chaskar'" ; Sent: Thursday, April 18, 2002 8:08 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > What kind of L2 triggers provide the IP address(es) of the target > > (candidate) access routers? > > Would you mind providing some examples? > > Thanks. > > > > There are no specific examples today of commerial link layers that do > this, but we have done some experiments involving modifying the IS-2000 > RAN to support triggers. It works extremely well. > > Also, it's possible to generate a "trigger" of sorts by forcing handoff > on certain 802.11 cards that provide to application software the BSSids > for access points the mobile can hear. The mobile can utilize the BSSid > to find the FA or AR address, or it can send it to the AR to find the > address. > > 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 Sun Apr 21 00:21: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 AAA12536 for ; Sun, 21 Apr 2002 00:21:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA29078 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 00:21:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28612; Sun, 21 Apr 2002 00:02:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28579 for ; Sun, 21 Apr 2002 00:02:14 -0400 (EDT) Received: from hotmail.com (oe18.law4.hotmail.com [216.33.148.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12411 for ; Sun, 21 Apr 2002 00:02:13 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Apr 2002 21:01:42 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "James Kempf" , References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <000201c1e763$d05710f0$4c6015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 13:06:46 -0700 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: 21 Apr 2002 04:01:42.0773 (UTC) FILETIME=[3F288A50:01C1E8E9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Thanks for the information. Could you tell us, if possible, how the IP address of the target address is discovered in your experiment with the IS-2000 RAN? Also how can the mobile utilize the BSSid to find the FA or AR address without asking the current AR in 802.11? Don't we need something like the CAR discovery protocol eventually? I assume the mobile does not receive the Agent Advertisement messages of the target AR in the above question. Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; "Karim El-Malki (ERA)" ; "'Hemant Chaskar'" ; Sent: Thursday, April 18, 2002 8:08 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > What kind of L2 triggers provide the IP address(es) of the target > > (candidate) access routers? > > Would you mind providing some examples? > > Thanks. > > > > There are no specific examples today of commerial link layers that do > this, but we have done some experiments involving modifying the IS-2000 > RAN to support triggers. It works extremely well. > > Also, it's possible to generate a "trigger" of sorts by forcing handoff > on certain 802.11 cards that provide to application software the BSSids > for access points the mobile can hear. The mobile can utilize the BSSid > to find the FA or AR address, or it can send it to the AR to find the > address. > > 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 Sun Apr 21 00:22: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 AAA12557 for ; Sun, 21 Apr 2002 00:22:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29029; Sun, 21 Apr 2002 00:17:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28984 for ; Sun, 21 Apr 2002 00:17:00 -0400 (EDT) Received: from hotmail.com (oe26.law4.hotmail.com [216.33.148.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12488 for ; Sun, 21 Apr 2002 00:16:59 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Apr 2002 21:16:29 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "James Kempf" , References: <002101c1e888$8908b4d0$a96015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 13:21:35 -0700 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: 21 Apr 2002 04:16:29.0057 (UTC) FILETIME=[4F6CBF10:01C1E8EB] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, To put a somewhat diverging comment, the low-latency handoff proposal of the MobileIP WG requires the L2 triggers (L2-MT, L2-ST) contain the IP address of the nFA. So in the scenario of the proposal, the mapping should happen before the L2 trigger message is composed. Actually I prefer having L2 triggers with just L2 identifiers and then doing the mapping as you described in the below. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Hemant Chaskar" ; Sent: Saturday, April 20, 2002 8:50 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > I see two cases for CAR discovery. Simple case is L2 trigger on the AR > or MN delivers an L2 identifier for the new AR or AP, AR or MN must map > to IP address of new AR. This is essentially cross link reverse ARP and > the MN doesn't have any choice about where it is going because it is > moved by the Layer 2. Complex case is MN wants to find out what's > available, uses CAR discovery to find an AR for the wireless > medium/QoS/etc. that matches its preferences. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Sent: Friday, April 19, 2002 10:03 AM > Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James: > > > > L2 beacons have nothing to do with CAR discovery. I would like to > understand > > however if the capability set of ARs behind those beacons is > important or > > not. If it is, it has to be indentified by CAR discovery protocol. If > that > > is the case, then there needs to be a creative implementation of CAR > > discovery protocol for the case that this thread is concerned with, > namely, > > MN having single NIC and not being able to communicate with ARs behind > those > > L2 beacons without letting go the old connection (the difficulty > persists > > even if MN gets IP addresses in beacons). > > > > Hemant > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Fri, 19 Apr 2002 09:18:53 -0700 > > > > > >I don't see what L2 beacons has to do with CAR discovery. The issue > is > > >what ARs the MN has access to and what are their capabilities. How > the > > >MN chooses to use that in the context of a particular L2 is up to the > > >MN. > > >The ARs may be identified by their L2 identifier or by an IP address. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Friday, April 19, 2002 8:12 AM > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > Hi James, > > > > > > > > TAR is not in scope. I am talking about identifying capabilities > of > > >ARs (or > > > > identifying match between capabilities of these ARs and MN's > > >requirements) > > > > that govern these L2 beacons. > > > > > > > > So, is it in scope of CAR discovery or we delegate the matter to > IEEE? > > > > > > > > Hemant > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > > > > > > > >Hemant, > > > > > > > > > >Remember, TAR is not in scope. > > > > > > > > > >As a practical matter, I believe the 802.11 standard should > provide > > >some > > > > >guidance, currently it doesn't. > > > > > > > > > > jak > > > > > > > > > >----- Original Message ----- > > > > >From: "Hemant Chaskar" > > > > >To: ; > > > > >Sent: Wednesday, April 17, 2002 2:45 PM > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > If there are more than one L2 beacons available (of comparable > > >signal > > > > > > strength), probably governed by different ARs, how do we > choose? I > > >do > > > > >not > > > > > > have problem choosing randomly, but just want to confirm if > this > > >is > > > > >the way > > > > > > we want to proceed. > > > > > > > > > > > > There is no doubt that handoff is necessary as old link will > fade, > > >but > > > > >you > > > > > > still have choice as to which new beacon to hold on to. > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Hemant Chaskar" , > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > > > > > > > >Right, that's what I'm saying. There is one case where the MN > > >needs > > > > >to > > > > > > >choose, and the other where the MN and AR get an L2 address > and > > >don't > > > > > > >have a choice. The handover happens because, if not, the > power > > >will > > > > >fade > > > > > > >and the MN loses link connectivity. > > > > > > > > > > > > > >The former case might require capabilities, the latter just > > >requires > > > > > > >cross link ARP. > > > > > > > > > > > > > > jak > > > > > > > > > > > > > >----- Original Message ----- > > > > > > >From: "Hemant Chaskar" > > > > > > >To: ; > > > > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > > > > >equivalent > > > > > > >to > > > > > > > > inter-technology case? I do not get the point. Why can't > the > > >MN > > > > >listen > > > > > > >to > > > > > > > > different L2 beacons of the same technology? I guess it > can, > > >and > > > > > > >hence, it > > > > > > > > still needs to chose one among them for handoff. Then the > > >issue is > > > > > > >exactly > > > > > > > > the same as Glenn raised for single NIC case: How to get > > > > >capabilities > > > > > > > > without letting go the old connection? Of course, I am > > >assuming > > > > >that > > > > > > >these > > > > > > > > L2's have comparable signal strengths. > > > > > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > > > >To: "Hemant Chaskar" , > > > > > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > > > > >It seems that the minutes indicate that people have > > >somehow > > > > >come > > > > > > >to a > > > > > > > > > > >conclusion that there is no need for access routers > to > > > > >divulge > > > > > > >that > > > > > > > > >they > > > > > > > > > > >are > > > > > > > > > > >geographically adjancent to themselves via the IP > > > > >infrastructure. > > > > > > >The > > > > > > > > > > >minutes also seem to indicate that the mobile alone > > >should be > > > > >the > > > > > > > > >only way > > > > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > >information > > > > > > >to > > > > > > > > >their > > > > > > > > > > >source AR if the mobile only has one NIC and that NIC > is > > >only > > > > > > >capable > > > > > > > > >of > > > > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. > > >What I > > > > > > >would > > > > > > > > >really > > > > > > > > > > like to understand is whether the above is a relevant > case > > >for > > > > >CAR > > > > > > > > >discovery > > > > > > > > > > or we simply neglect it and focus only on two physical > > > > >interfaces > > > > > > > > >case. I > > > > > > > > > > raised this question before, but we have not had much > > > > >discussion > > > > > > >on > > > > > > > > >it. In > > > > > > > > > > any case, address translation part of CARD will be > > >required in > > > > > > >this > > > > > > > > >case for > > > > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 > typically > > > > >delivers > > > > > > >the > > > > > > > > >AP or AR L2 identifier to which the MN will be handed > over. > > >This > > > > > > > > >information is required (by the MIP fast handover > algorithms) > > >at > > > > >the > > > > > > > > >MN's AR. So the issue is fairly simple: the AR must be > able > > >to do > > > > > > > > >reverse address translation in order that it can contact > the > > > > >other > > > > > > >AR. > > > > > > > > >Capabilities aren't involved, except to the extent that > the > > >MN > > > > >can > > > > > > >hear > > > > > > > > >multiple L2s and make the decision. But this is exactly > the > > >same > > > > >as > > > > > > >for > > > > > > > > >the intertechnology case. > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > Get your FREE download of MSN Explorer at > > > > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Send and receive Hotmail on your mobile device: > http://mobile.msn.com > > > > > > > > > > > > > > > > > _________________________________________________________________ > > 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 Sun Apr 21 00:22: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 AAA12570 for ; Sun, 21 Apr 2002 00:22:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA29095 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 00:22:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29029; Sun, 21 Apr 2002 00:17:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28984 for ; Sun, 21 Apr 2002 00:17:00 -0400 (EDT) Received: from hotmail.com (oe26.law4.hotmail.com [216.33.148.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12488 for ; Sun, 21 Apr 2002 00:16:59 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Apr 2002 21:16:29 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "James Kempf" , References: <002101c1e888$8908b4d0$a96015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 13:21:35 -0700 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: 21 Apr 2002 04:16:29.0057 (UTC) FILETIME=[4F6CBF10:01C1E8EB] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, To put a somewhat diverging comment, the low-latency handoff proposal of the MobileIP WG requires the L2 triggers (L2-MT, L2-ST) contain the IP address of the nFA. So in the scenario of the proposal, the mapping should happen before the L2 trigger message is composed. Actually I prefer having L2 triggers with just L2 identifiers and then doing the mapping as you described in the below. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Hemant Chaskar" ; Sent: Saturday, April 20, 2002 8:50 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > I see two cases for CAR discovery. Simple case is L2 trigger on the AR > or MN delivers an L2 identifier for the new AR or AP, AR or MN must map > to IP address of new AR. This is essentially cross link reverse ARP and > the MN doesn't have any choice about where it is going because it is > moved by the Layer 2. Complex case is MN wants to find out what's > available, uses CAR discovery to find an AR for the wireless > medium/QoS/etc. that matches its preferences. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Sent: Friday, April 19, 2002 10:03 AM > Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > Hi James: > > > > L2 beacons have nothing to do with CAR discovery. I would like to > understand > > however if the capability set of ARs behind those beacons is > important or > > not. If it is, it has to be indentified by CAR discovery protocol. If > that > > is the case, then there needs to be a creative implementation of CAR > > discovery protocol for the case that this thread is concerned with, > namely, > > MN having single NIC and not being able to communicate with ARs behind > those > > L2 beacons without letting go the old connection (the difficulty > persists > > even if MN gets IP addresses in beacons). > > > > Hemant > > > > >From: "James Kempf" > > >To: "Hemant Chaskar" , > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > >Date: Fri, 19 Apr 2002 09:18:53 -0700 > > > > > >I don't see what L2 beacons has to do with CAR discovery. The issue > is > > >what ARs the MN has access to and what are their capabilities. How > the > > >MN chooses to use that in the context of a particular L2 is up to the > > >MN. > > >The ARs may be identified by their L2 identifier or by an IP address. > > > > > > jak > > > > > >----- Original Message ----- > > >From: "Hemant Chaskar" > > >To: ; > > >Sent: Friday, April 19, 2002 8:12 AM > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > Hi James, > > > > > > > > TAR is not in scope. I am talking about identifying capabilities > of > > >ARs (or > > > > identifying match between capabilities of these ARs and MN's > > >requirements) > > > > that govern these L2 beacons. > > > > > > > > So, is it in scope of CAR discovery or we delegate the matter to > IEEE? > > > > > > > > Hemant > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > >To: "Hemant Chaskar" , > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > >Date: Thu, 18 Apr 2002 08:33:10 -0700 > > > > > > > > > >Hemant, > > > > > > > > > >Remember, TAR is not in scope. > > > > > > > > > >As a practical matter, I believe the 802.11 standard should > provide > > >some > > > > >guidance, currently it doesn't. > > > > > > > > > > jak > > > > > > > > > >----- Original Message ----- > > > > >From: "Hemant Chaskar" > > > > >To: ; > > > > >Sent: Wednesday, April 17, 2002 2:45 PM > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > If there are more than one L2 beacons available (of comparable > > >signal > > > > > > strength), probably governed by different ARs, how do we > choose? I > > >do > > > > >not > > > > > > have problem choosing randomly, but just want to confirm if > this > > >is > > > > >the way > > > > > > we want to proceed. > > > > > > > > > > > > There is no doubt that handoff is necessary as old link will > fade, > > >but > > > > >you > > > > > > still have choice as to which new beacon to hold on to. > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > >To: "Hemant Chaskar" , > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > >Date: Tue, 16 Apr 2002 15:44:48 -0700 > > > > > > > > > > > > > >Right, that's what I'm saying. There is one case where the MN > > >needs > > > > >to > > > > > > >choose, and the other where the MN and AR get an L2 address > and > > >don't > > > > > > >have a choice. The handover happens because, if not, the > power > > >will > > > > >fade > > > > > > >and the MN loses link connectivity. > > > > > > > > > > > > > >The former case might require capabilities, the latter just > > >requires > > > > > > >cross link ARP. > > > > > > > > > > > > > > jak > > > > > > > > > > > > > >----- Original Message ----- > > > > > > >From: "Hemant Chaskar" > > > > > > >To: ; > > > > > > >Sent: Tuesday, April 16, 2002 2:17 PM > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > > > > > > > > > > > > > > > Hi James: > > > > > > > > > > > > > > > > What do you mean when you say that hearing multiple L2 is > > > > >equivalent > > > > > > >to > > > > > > > > inter-technology case? I do not get the point. Why can't > the > > >MN > > > > >listen > > > > > > >to > > > > > > > > different L2 beacons of the same technology? I guess it > can, > > >and > > > > > > >hence, it > > > > > > > > still needs to chose one among them for handoff. Then the > > >issue is > > > > > > >exactly > > > > > > > > the same as Glenn raised for single NIC case: How to get > > > > >capabilities > > > > > > > > without letting go the old connection? Of course, I am > > >assuming > > > > >that > > > > > > >these > > > > > > > > L2's have comparable signal strengths. > > > > > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > >From: "James Kempf" > > > > > > > > >To: "Hemant Chaskar" , > > > > > > > > > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > > > > >Date: Tue, 16 Apr 2002 10:26:45 -0700 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[The Issue] > > > > > > > > > > >It seems that the minutes indicate that people have > > >somehow > > > > >come > > > > > > >to a > > > > > > > > > > >conclusion that there is no need for access routers > to > > > > >divulge > > > > > > >that > > > > > > > > >they > > > > > > > > > > >are > > > > > > > > > > >geographically adjancent to themselves via the IP > > > > >infrastructure. > > > > > > >The > > > > > > > > > > >minutes also seem to indicate that the mobile alone > > >should be > > > > >the > > > > > > > > >only way > > > > > > > > > > >to pass addresses of CARs to source ARs. > > > > > > > > > > > > > > > > > > > > > >[Technical Questions] > > > > > > > > > > >O.K. If this is true then how will a mobile pass this > > > > >information > > > > > > >to > > > > > > > > >their > > > > > > > > > > >source AR if the mobile only has one NIC and that NIC > is > > >only > > > > > > >capable > > > > > > > > >of > > > > > > > > > > >listening to one media at once? > > > > > > > > > > > > > > > > > > > > [HC] I agree that this is a genuine technical problem. > > >What I > > > > > > >would > > > > > > > > >really > > > > > > > > > > like to understand is whether the above is a relevant > case > > >for > > > > >CAR > > > > > > > > >discovery > > > > > > > > > > or we simply neglect it and focus only on two physical > > > > >interfaces > > > > > > > > >case. I > > > > > > > > > > raised this question before, but we have not had much > > > > >discussion > > > > > > >on > > > > > > > > >it. In > > > > > > > > > > any case, address translation part of CARD will be > > >required in > > > > > > >this > > > > > > > > >case for > > > > > > > > > > fast handoff support. > > > > > > > > > > > > > > > > > > > > > > > > > > > >In a single interface handoff situation, Layer 2 > typically > > > > >delivers > > > > > > >the > > > > > > > > >AP or AR L2 identifier to which the MN will be handed > over. > > >This > > > > > > > > >information is required (by the MIP fast handover > algorithms) > > >at > > > > >the > > > > > > > > >MN's AR. So the issue is fairly simple: the AR must be > able > > >to do > > > > > > > > >reverse address translation in order that it can contact > the > > > > >other > > > > > > >AR. > > > > > > > > >Capabilities aren't involved, except to the extent that > the > > >MN > > > > >can > > > > > > >hear > > > > > > > > >multiple L2s and make the decision. But this is exactly > the > > >same > > > > >as > > > > > > >for > > > > > > > > >the intertechnology case. > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > > > Join the world's largest e-mail service with MSN Hotmail. > > > > > > > > http://www.hotmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > Get your FREE download of MSN Explorer at > > > > >http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Send and receive Hotmail on your mobile device: > http://mobile.msn.com > > > > > > > > > > > > > > > > > _________________________________________________________________ > > 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 Sun Apr 21 05:55: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 FAA23017 for ; Sun, 21 Apr 2002 05:55:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20190; Sun, 21 Apr 2002 05:49:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20161 for ; Sun, 21 Apr 2002 05:49:47 -0400 (EDT) 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 FAA22960 for ; Sun, 21 Apr 2002 05:49:45 -0400 (EDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3L9n8I10945; Sun, 21 Apr 2002 02:49:09 -0700 (PDT) Message-ID: <004801c1e919$8f877d00$446015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <002101c1e888$8908b4d0$a96015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 02:47:29 -0700 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 > To put a somewhat diverging comment, the low-latency handoff proposal of the > MobileIP WG requires the L2 triggers (L2-MT, L2-ST) contain the IP address > of the nFA. So in the scenario of the proposal, the mapping should happen > before the L2 trigger message is composed. Actually I prefer having L2 > triggers with just L2 identifiers and then doing the mapping as you > described in the below. > Thanks. > The L2 triggers require some identifier. In general, I would think that this would be an L2 identifier, but for particular L2s where it is possible to provide the IP address and the network topology is fixed, it could also be the IP address. The prototype IS-2000 RAN work falls into the latter case. It is just a further optimization. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Apr 21 05:55: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 FAA23031 for ; Sun, 21 Apr 2002 05:55:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20521 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 05:55:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20190; Sun, 21 Apr 2002 05:49:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20161 for ; Sun, 21 Apr 2002 05:49:47 -0400 (EDT) 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 FAA22960 for ; Sun, 21 Apr 2002 05:49:45 -0400 (EDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3L9n8I10945; Sun, 21 Apr 2002 02:49:09 -0700 (PDT) Message-ID: <004801c1e919$8f877d00$446015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <002101c1e888$8908b4d0$a96015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 02:47:29 -0700 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 > To put a somewhat diverging comment, the low-latency handoff proposal of the > MobileIP WG requires the L2 triggers (L2-MT, L2-ST) contain the IP address > of the nFA. So in the scenario of the proposal, the mapping should happen > before the L2 trigger message is composed. Actually I prefer having L2 > triggers with just L2 identifiers and then doing the mapping as you > described in the below. > Thanks. > The L2 triggers require some identifier. In general, I would think that this would be an L2 identifier, but for particular L2s where it is possible to provide the IP address and the network topology is fixed, it could also be the IP address. The prototype IS-2000 RAN work falls into the latter case. It is just a further optimization. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Apr 21 05:55: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 FAA23047 for ; Sun, 21 Apr 2002 05:55:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20087; Sun, 21 Apr 2002 05:46:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20057 for ; Sun, 21 Apr 2002 05:46:15 -0400 (EDT) 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 FAA22939 for ; Sun, 21 Apr 2002 05:46:13 -0400 (EDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3L9jaI10838; Sun, 21 Apr 2002 02:45:36 -0700 (PDT) Message-ID: <004001c1e919$111f6950$446015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , "Singh Ajoy-ASINGH1" References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <000201c1e763$d05710f0$4c6015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 02:43:56 -0700 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 > Could you tell us, if possible, how the IP address of the target address is > discovered in your experiment with the IS-2000 RAN? The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the technical lead. I've cc'ed him on this response, perhaps he can describe how the L2 triggers were implemented. > Also how can the mobile utilize the BSSid to find the FA or AR address > without asking the current AR in 802.11? Don't we need something like the > CAR discovery protocol eventually? I assume the mobile does not receive the > Agent Advertisement messages of the target AR in the above question. Sure. But for experimental purposes, one can simply statically configure the access routers or FAs with the mapping. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Apr 21 05: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 FAA23063 for ; Sun, 21 Apr 2002 05:55:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20535 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 05:55:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20087; Sun, 21 Apr 2002 05:46:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20057 for ; Sun, 21 Apr 2002 05:46:15 -0400 (EDT) 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 FAA22939 for ; Sun, 21 Apr 2002 05:46:13 -0400 (EDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3L9jaI10838; Sun, 21 Apr 2002 02:45:36 -0700 (PDT) Message-ID: <004001c1e919$111f6950$446015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , "Singh Ajoy-ASINGH1" References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <000201c1e763$d05710f0$4c6015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 02:43:56 -0700 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 > Could you tell us, if possible, how the IP address of the target address is > discovered in your experiment with the IS-2000 RAN? The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the technical lead. I've cc'ed him on this response, perhaps he can describe how the L2 triggers were implemented. > Also how can the mobile utilize the BSSid to find the FA or AR address > without asking the current AR in 802.11? Don't we need something like the > CAR discovery protocol eventually? I assume the mobile does not receive the > Agent Advertisement messages of the target AR in the above question. Sure. But for experimental purposes, one can simply statically configure the access routers or FAs with the mapping. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Apr 21 06:42: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 GAA23364 for ; Sun, 21 Apr 2002 06:42:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21852; Sun, 21 Apr 2002 06:24:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21821 for ; Sun, 21 Apr 2002 06:24:14 -0400 (EDT) Received: from hotmail.com (oe54.law4.hotmail.com [216.33.148.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23267 for ; Sun, 21 Apr 2002 06:24:13 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Apr 2002 03:23:43 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "James Kempf" , , "Singh Ajoy-ASINGH1" References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <000201c1e763$d05710f0$4c6015ac@T23KEMPF> <004001c1e919$111f6950$446015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 19:28:50 -0700 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: 21 Apr 2002 10:23:43.0385 (UTC) FILETIME=[9CE86090:01C1E91E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, I see. Thanks a lot. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; ; "Singh Ajoy-ASINGH1" Sent: Sunday, April 21, 2002 2:43 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > Could you tell us, if possible, how the IP address of the target > address is > > discovered in your experiment with the IS-2000 RAN? > > The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the > technical lead. I've cc'ed him on this response, perhaps he can describe > how the L2 triggers were implemented. > > > Also how can the mobile utilize the BSSid to find the FA or AR address > > without asking the current AR in 802.11? Don't we need something like > the > > CAR discovery protocol eventually? I assume the mobile does not > receive the > > Agent Advertisement messages of the target AR in the above question. > > Sure. But for experimental purposes, one can simply statically configure > the access routers or FAs with the mapping. > > 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 Sun Apr 21 06:42: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 GAA23375 for ; Sun, 21 Apr 2002 06:42:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22650 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 06:42:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21852; Sun, 21 Apr 2002 06:24:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21821 for ; Sun, 21 Apr 2002 06:24:14 -0400 (EDT) Received: from hotmail.com (oe54.law4.hotmail.com [216.33.148.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23267 for ; Sun, 21 Apr 2002 06:24:13 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Apr 2002 03:23:43 -0700 X-Originating-IP: [211.192.81.212] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "James Kempf" , , "Singh Ajoy-ASINGH1" References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117> <000201c1e763$d05710f0$4c6015ac@T23KEMPF> <004001c1e919$111f6950$446015ac@T23KEMPF> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 19:28:50 -0700 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: 21 Apr 2002 10:23:43.0385 (UTC) FILETIME=[9CE86090:01C1E91E] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, I see. Thanks a lot. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; ; "Singh Ajoy-ASINGH1" Sent: Sunday, April 21, 2002 2:43 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > Could you tell us, if possible, how the IP address of the target > address is > > discovered in your experiment with the IS-2000 RAN? > > The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the > technical lead. I've cc'ed him on this response, perhaps he can describe > how the L2 triggers were implemented. > > > Also how can the mobile utilize the BSSid to find the FA or AR address > > without asking the current AR in 802.11? Don't we need something like > the > > CAR discovery protocol eventually? I assume the mobile does not > receive the > > Agent Advertisement messages of the target AR in the above question. > > Sure. But for experimental purposes, one can simply statically configure > the access routers or FAs with the mapping. > > 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 Sun Apr 21 06:42: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 GAA23390 for ; Sun, 21 Apr 2002 06:42:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22502; Sun, 21 Apr 2002 06:33:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22433 for ; Sun, 21 Apr 2002 06:33:21 -0400 (EDT) Received: from hunter.ee.tu-berlin.de (pD9587B42.dip.t-dialin.net [217.88.123.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23321 for ; Sun, 21 Apr 2002 06:33:20 -0400 (EDT) Received: from hunter ([127.0.0.1]) by hunter.ee.tu-berlin.de with Microsoft SMTPSVC(5.0.2172.1); Sun, 21 Apr 2002 12:32:03 +0200 Message-ID: <028b01c1e91f$c6c34af0$6b1dfea9@ee.tuberlin.de> Reply-To: "Xiaoming Fu" From: "Xiaoming Fu" To: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 12:32:02 +0200 Organization: Telecommunication Networks Group, TU-Berlin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0288_01C1E930.8A39CB70" 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 X-OriginalArrivalTime: 21 Apr 2002 10:32:03.0103 (UTC) FILETIME=[C6C34AF0:01C1E91F] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_0288_01C1E930.8A39CB70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have not been following this discussion closely, so sorry if this has been clear to all: (In IETF53minutes / Requirement 5 - FORMAT OF CAPABILITIES): The capabilities MUST be described in a standard format which is TBD. =3D> Is "TBD" task within the Seamoby/CARD? Or it is going to like=20 "The exact format differs (and/or derives) from the capacity=20 parameters specified by specific L2 technologies"? (Rajeev's mail:=20 CARD: a process that facilitates resolving the prospective = link(identifier) with its prefix and assocaited capabilities. This comes out as off-link = ARP with extensions. TARS: a process that assists in selecting _a_ router from among multiple candidates.) =3D>Where does CARD end? If I understand correctly, it's (current) ARs. "Associated capabilities" = also=20 include some higher-layer information e.g., QoS and security. So when=20 CARD is used, perhaps one possibility is that the same information in CT = could be avoided to save wireless bandwidth.=20 =3D>How does TARS possibly work: MN may (e.g., periodically) ask its (current) AR for a satisfied TARS by = checking into "associated capabilities". My understanding is, when=20 succeeds a L2 identifier may only be returned to MN. However when=20 it it may be impossible to identify the IP address of TARS (because the=20 AR only knows about the L2 identifiers & associated capacity of CARs).=20 One possibility is to let the (current)AR to "solicitate" an L3 = advertisement=20 from the TARS to the MN.=20 Thanks, Xiaoming ------=_NextPart_000_0288_01C1E930.8A39CB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have not been following this discussion closely, = so sorry if=20 this
has been clear to all:
 
(In IETF53minutes / Requirement 5 - FORMAT OF=20 CAPABILITIES):
The capabilities MUST be described in a standard = format which=20 is TBD.
 
=3D> Is "TBD" task within the Seamoby/CARD? = Or it is=20 going to like 
"The exact format differs (and/or derives) from=20 the capacity 
parameters specified by specific=20 L2 technologies"?
(Rajeev's mail:
CARD: a process that facilitates resolving the = prospective=20 link(identifier)
with its prefix and assocaited capabilities. This = comes out=20 as off-link ARP
with extensions.
TARS: a process that assists in = selecting=20 _a_ router from among multiple
candidates.)
=3D>Where does CARD = end?
If I understand correctly, it's (current) ARs. = "Associated capabilities" also =
include some higher-layer = information=20 e.g., QoS and security. So when
CARD is used, perhaps one = possibility=20 is that the same information in = CT 
could be avoided to save=20 wireless bandwidth.
 
=3D>How does TARS possibly work:
MN may (e.g., periodically) ask its (current) AR=20 for a satisfied TARS by
checking into "associated capabilities". My = understanding is,=20 when 
succeeds a L2 identifier  may only be returned to MN. However when=20
it it may be impossible to identify the = IP address of TARS (because = the 
AR only knows about=20 the L2 identifiers & associated capacity of CARs). 
One possibility is to let the=20 (current)AR to "solicitate" = an=20 L3 advertisement
from the TARS to the MN.=20
 
Thanks,
Xiaoming
------=_NextPart_000_0288_01C1E930.8A39CB70-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Apr 21 06:42: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 GAA23401 for ; Sun, 21 Apr 2002 06:42:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22664 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 06:42:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22502; Sun, 21 Apr 2002 06:33:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22433 for ; Sun, 21 Apr 2002 06:33:21 -0400 (EDT) Received: from hunter.ee.tu-berlin.de (pD9587B42.dip.t-dialin.net [217.88.123.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23321 for ; Sun, 21 Apr 2002 06:33:20 -0400 (EDT) Received: from hunter ([127.0.0.1]) by hunter.ee.tu-berlin.de with Microsoft SMTPSVC(5.0.2172.1); Sun, 21 Apr 2002 12:32:03 +0200 Message-ID: <028b01c1e91f$c6c34af0$6b1dfea9@ee.tuberlin.de> Reply-To: "Xiaoming Fu" From: "Xiaoming Fu" To: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 12:32:02 +0200 Organization: Telecommunication Networks Group, TU-Berlin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0288_01C1E930.8A39CB70" 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 X-OriginalArrivalTime: 21 Apr 2002 10:32:03.0103 (UTC) FILETIME=[C6C34AF0:01C1E91F] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_0288_01C1E930.8A39CB70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have not been following this discussion closely, so sorry if this has been clear to all: (In IETF53minutes / Requirement 5 - FORMAT OF CAPABILITIES): The capabilities MUST be described in a standard format which is TBD. =3D> Is "TBD" task within the Seamoby/CARD? Or it is going to like=20 "The exact format differs (and/or derives) from the capacity=20 parameters specified by specific L2 technologies"? (Rajeev's mail:=20 CARD: a process that facilitates resolving the prospective = link(identifier) with its prefix and assocaited capabilities. This comes out as off-link = ARP with extensions. TARS: a process that assists in selecting _a_ router from among multiple candidates.) =3D>Where does CARD end? If I understand correctly, it's (current) ARs. "Associated capabilities" = also=20 include some higher-layer information e.g., QoS and security. So when=20 CARD is used, perhaps one possibility is that the same information in CT = could be avoided to save wireless bandwidth.=20 =3D>How does TARS possibly work: MN may (e.g., periodically) ask its (current) AR for a satisfied TARS by = checking into "associated capabilities". My understanding is, when=20 succeeds a L2 identifier may only be returned to MN. However when=20 it it may be impossible to identify the IP address of TARS (because the=20 AR only knows about the L2 identifiers & associated capacity of CARs).=20 One possibility is to let the (current)AR to "solicitate" an L3 = advertisement=20 from the TARS to the MN.=20 Thanks, Xiaoming ------=_NextPart_000_0288_01C1E930.8A39CB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have not been following this discussion closely, = so sorry if=20 this
has been clear to all:
 
(In IETF53minutes / Requirement 5 - FORMAT OF=20 CAPABILITIES):
The capabilities MUST be described in a standard = format which=20 is TBD.
 
=3D> Is "TBD" task within the Seamoby/CARD? = Or it is=20 going to like 
"The exact format differs (and/or derives) from=20 the capacity 
parameters specified by specific=20 L2 technologies"?
(Rajeev's mail:
CARD: a process that facilitates resolving the = prospective=20 link(identifier)
with its prefix and assocaited capabilities. This = comes out=20 as off-link ARP
with extensions.
TARS: a process that assists in = selecting=20 _a_ router from among multiple
candidates.)
=3D>Where does CARD = end?
If I understand correctly, it's (current) ARs. = "Associated capabilities" also =
include some higher-layer = information=20 e.g., QoS and security. So when
CARD is used, perhaps one = possibility=20 is that the same information in = CT 
could be avoided to save=20 wireless bandwidth.
 
=3D>How does TARS possibly work:
MN may (e.g., periodically) ask its (current) AR=20 for a satisfied TARS by
checking into "associated capabilities". My = understanding is,=20 when 
succeeds a L2 identifier  may only be returned to MN. However when=20
it it may be impossible to identify the = IP address of TARS (because = the 
AR only knows about=20 the L2 identifiers & associated capacity of CARs). 
One possibility is to let the=20 (current)AR to "solicitate" = an=20 L3 advertisement
from the TARS to the MN.=20
 
Thanks,
Xiaoming
------=_NextPart_000_0288_01C1E930.8A39CB70-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Apr 21 12:19: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 MAA27932 for ; Sun, 21 Apr 2002 12:19:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05433; Sun, 21 Apr 2002 12:07:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05406 for ; Sun, 21 Apr 2002 12:07:38 -0400 (EDT) Received: from hunter.ee.tu-berlin.de (pD9587249.dip.t-dialin.net [217.88.114.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27797 for ; Sun, 21 Apr 2002 12:07:35 -0400 (EDT) Received: from hunter ([127.0.0.1]) by hunter.ee.tu-berlin.de with Microsoft SMTPSVC(5.0.2172.1); Sun, 21 Apr 2002 18:06:17 +0200 Message-ID: <01c101c1e94e$781e0a00$6b1dfea9@ee.tuberlin.de> Reply-To: "Xiaoming Fu" From: "Xiaoming Fu" To: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 18:06:17 +0200 Organization: Telecommunication Networks Group, TU-Berlin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BE_01C1E95F.3B9303E0" 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 X-OriginalArrivalTime: 21 Apr 2002 16:06:17.0504 (UTC) FILETIME=[781E0A00:01C1E94E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_01BE_01C1E95F.3B9303E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have not been following this discussion closely, so sorry if this has been clear to all: (In IETF53minutes / Requirement 5 - FORMAT OF CAPABILITIES): The capabilities MUST be described in a standard format which is TBD. =3D> Is "TBD" task within the Seamoby/CARD? Or it is going to like=20 "The exact format differs (and/or derives) from the capacity=20 parameters specified by specific L2 technologies"? (Rajeev's mail:=20 CARD: a process that facilitates resolving the prospective = link(identifier) with its prefix and assocaited capabilities. This comes out as off-link = ARP with extensions. TARS: a process that assists in selecting _a_ router from among multiple candidates.) =3D>Where does CARD end? If I understand correctly, it's (current) ARs. "Associated capabilities" = also=20 include some higher-layer information e.g., QoS and security. So when=20 CARD is used, perhaps one possibility is that the same information in CT = could be avoided to save wireless bandwidth.=20 =3D>How does TARS possibly : MN may (e.g., periodically) ask its (current) AR for a TARS by checking=20 into "associated capabilities". My understanding is, when this succeeds a L2 identifier of a TAR may only be returned to MN. It may=20 be still impossible for the AR (and henceforce the MN) to identify the = IP=20 address of TAR (because the AR only knows about the L2 identifiers &=20 associated capacity of CARs). Is it then necessary to let the = (current)AR=20 "solicitate" L3 advertisement from TAR? Thanks, Xiaoming ------=_NextPart_000_01BE_01C1E95F.3B9303E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi all,
 
I have not been following this discussion closely, = so sorry if=20 this
has been clear to all:
 
(In IETF53minutes / Requirement 5 - FORMAT OF=20 CAPABILITIES):
The capabilities MUST be described in a standard = format which=20 is TBD.
 
=3D> Is "TBD" task within the Seamoby/CARD? = Or it is=20 going to like 
"The exact format differs (and/or derives) from=20 the capacity 
parameters specified by specific=20 L2 technologies"?
 
(Rajeev's mail:
CARD: a process that facilitates resolving the = prospective=20 link(identifier)
with its prefix and assocaited capabilities. This = comes out=20 as off-link ARP
with extensions.
TARS: a process that assists in = selecting=20 _a_ router from among multiple
candidates.)
 
=3D>Where does CARD = end?
If I understand correctly, it's (current) ARs. = "Associated capabilities" also =
include some higher-layer = information=20 e.g., QoS and security. So when
CARD is used, perhaps one = possibility=20 is that the same information in = CT 
could be avoided to save=20 wireless bandwidth.
 
=3D>How does TARS possibly :
MN may (e.g., periodically) ask its (current) AR=20 for a TARS by checking =
into "associated = capabilities". My understanding is, when this
succeeds a L2 identifier of a=20 TAR may only be returned to MN. = It may
be still impossible for = the AR (and=20 henceforce the MN) to identify the IP=20
address of TAR (because=20 the AR only = knows about the L2 identifiers &
associated capacity of = CARs). Is=20 it then necessary to let the=20 (current)AR 
"solicitate" L3 advertisement from TAR?
 
Thanks,
Xiaoming
------=_NextPart_000_01BE_01C1E95F.3B9303E0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Sun Apr 21 12:19: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 MAA27942 for ; Sun, 21 Apr 2002 12:19:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05613 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 12:19:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05433; Sun, 21 Apr 2002 12:07:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05406 for ; Sun, 21 Apr 2002 12:07:38 -0400 (EDT) Received: from hunter.ee.tu-berlin.de (pD9587249.dip.t-dialin.net [217.88.114.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27797 for ; Sun, 21 Apr 2002 12:07:35 -0400 (EDT) Received: from hunter ([127.0.0.1]) by hunter.ee.tu-berlin.de with Microsoft SMTPSVC(5.0.2172.1); Sun, 21 Apr 2002 18:06:17 +0200 Message-ID: <01c101c1e94e$781e0a00$6b1dfea9@ee.tuberlin.de> Reply-To: "Xiaoming Fu" From: "Xiaoming Fu" To: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 18:06:17 +0200 Organization: Telecommunication Networks Group, TU-Berlin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BE_01C1E95F.3B9303E0" 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 X-OriginalArrivalTime: 21 Apr 2002 16:06:17.0504 (UTC) FILETIME=[781E0A00:01C1E94E] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 is a multi-part message in MIME format. ------=_NextPart_000_01BE_01C1E95F.3B9303E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have not been following this discussion closely, so sorry if this has been clear to all: (In IETF53minutes / Requirement 5 - FORMAT OF CAPABILITIES): The capabilities MUST be described in a standard format which is TBD. =3D> Is "TBD" task within the Seamoby/CARD? Or it is going to like=20 "The exact format differs (and/or derives) from the capacity=20 parameters specified by specific L2 technologies"? (Rajeev's mail:=20 CARD: a process that facilitates resolving the prospective = link(identifier) with its prefix and assocaited capabilities. This comes out as off-link = ARP with extensions. TARS: a process that assists in selecting _a_ router from among multiple candidates.) =3D>Where does CARD end? If I understand correctly, it's (current) ARs. "Associated capabilities" = also=20 include some higher-layer information e.g., QoS and security. So when=20 CARD is used, perhaps one possibility is that the same information in CT = could be avoided to save wireless bandwidth.=20 =3D>How does TARS possibly : MN may (e.g., periodically) ask its (current) AR for a TARS by checking=20 into "associated capabilities". My understanding is, when this succeeds a L2 identifier of a TAR may only be returned to MN. It may=20 be still impossible for the AR (and henceforce the MN) to identify the = IP=20 address of TAR (because the AR only knows about the L2 identifiers &=20 associated capacity of CARs). Is it then necessary to let the = (current)AR=20 "solicitate" L3 advertisement from TAR? Thanks, Xiaoming ------=_NextPart_000_01BE_01C1E95F.3B9303E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi all,
 
I have not been following this discussion closely, = so sorry if=20 this
has been clear to all:
 
(In IETF53minutes / Requirement 5 - FORMAT OF=20 CAPABILITIES):
The capabilities MUST be described in a standard = format which=20 is TBD.
 
=3D> Is "TBD" task within the Seamoby/CARD? = Or it is=20 going to like 
"The exact format differs (and/or derives) from=20 the capacity 
parameters specified by specific=20 L2 technologies"?
 
(Rajeev's mail:
CARD: a process that facilitates resolving the = prospective=20 link(identifier)
with its prefix and assocaited capabilities. This = comes out=20 as off-link ARP
with extensions.
TARS: a process that assists in = selecting=20 _a_ router from among multiple
candidates.)
 
=3D>Where does CARD = end?
If I understand correctly, it's (current) ARs. = "Associated capabilities" also =
include some higher-layer = information=20 e.g., QoS and security. So when
CARD is used, perhaps one = possibility=20 is that the same information in = CT 
could be avoided to save=20 wireless bandwidth.
 
=3D>How does TARS possibly :
MN may (e.g., periodically) ask its (current) AR=20 for a TARS by checking =
into "associated = capabilities". My understanding is, when this
succeeds a L2 identifier of a=20 TAR may only be returned to MN. = It may
be still impossible for = the AR (and=20 henceforce the MN) to identify the IP=20
address of TAR (because=20 the AR only = knows about the L2 identifiers &
associated capacity of = CARs). Is=20 it then necessary to let the=20 (current)AR 
"solicitate" L3 advertisement from TAR?
 
Thanks,
Xiaoming
------=_NextPart_000_01BE_01C1E95F.3B9303E0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Apr 21 16:19: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 QAA01226 for ; Sun, 21 Apr 2002 16:19:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16719; Sun, 21 Apr 2002 16:10:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16688 for ; Sun, 21 Apr 2002 16:10:54 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01130 for ; Sun, 21 Apr 2002 16:10:52 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA00881 for ; Sun, 21 Apr 2002 12:59:01 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA10054 for ; Sun, 21 Apr 2002 13:10:41 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Sun, 21 Apr 2002 15:10:41 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 15:10:39 -0500 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/James, We implemented both source as well as target trigger scenarios of Low latency handoff draft. In case of source trigger, the Pre-trigger indication at source FA provides the BTS id of the target BTS to which MN is moving to. The L2 trigger handler at the oFA resolves BTS-ID to obtain the IP address of the nFA. We used static table to resolve IP address from the given BTS-ID. Similarly, in case of target trigger, the Pre-trigger indication at nFA provides the BTS-ID of the source BTS from which the MN is moving from. The L2 trigger handler at nFA resolves source BTS-ID to obtain the IP address of the source FA. Pre-trigger indication is sent from radio network controller to foreign agent as soon as link layer handoff is detected based upon power measurement. Hope this helps. regards, ajoy -----Original Message----- From: Eunsoo Shim [mailto:eunsooshim@hotmail.com] Sent: Sunday, April 21, 2002 9:29 PM To: James Kempf; seamoby@ietf.org; Singh Ajoy-ASINGH1 Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 James, I see. Thanks a lot. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; ; "Singh Ajoy-ASINGH1" Sent: Sunday, April 21, 2002 2:43 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > Could you tell us, if possible, how the IP address of the target > address is > > discovered in your experiment with the IS-2000 RAN? > > The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the > technical lead. I've cc'ed him on this response, perhaps he can describe > how the L2 triggers were implemented. > > > Also how can the mobile utilize the BSSid to find the FA or AR address > > without asking the current AR in 802.11? Don't we need something like > the > > CAR discovery protocol eventually? I assume the mobile does not > receive the > > Agent Advertisement messages of the target AR in the above question. > > Sure. But for experimental purposes, one can simply statically configure > the access routers or FAs with the mapping. > > 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 Sun Apr 21 16:19: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 QAA01237 for ; Sun, 21 Apr 2002 16:19:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16979 for seamoby-archive@odin.ietf.org; Sun, 21 Apr 2002 16:19:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16719; Sun, 21 Apr 2002 16:10:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16688 for ; Sun, 21 Apr 2002 16:10:54 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01130 for ; Sun, 21 Apr 2002 16:10:52 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA00881 for ; Sun, 21 Apr 2002 12:59:01 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA10054 for ; Sun, 21 Apr 2002 13:10:41 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Sun, 21 Apr 2002 15:10:41 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Eunsoo Shim'" , James Kempf , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Sun, 21 Apr 2002 15:10:39 -0500 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/James, We implemented both source as well as target trigger scenarios of Low latency handoff draft. In case of source trigger, the Pre-trigger indication at source FA provides the BTS id of the target BTS to which MN is moving to. The L2 trigger handler at the oFA resolves BTS-ID to obtain the IP address of the nFA. We used static table to resolve IP address from the given BTS-ID. Similarly, in case of target trigger, the Pre-trigger indication at nFA provides the BTS-ID of the source BTS from which the MN is moving from. The L2 trigger handler at nFA resolves source BTS-ID to obtain the IP address of the source FA. Pre-trigger indication is sent from radio network controller to foreign agent as soon as link layer handoff is detected based upon power measurement. Hope this helps. regards, ajoy -----Original Message----- From: Eunsoo Shim [mailto:eunsooshim@hotmail.com] Sent: Sunday, April 21, 2002 9:29 PM To: James Kempf; seamoby@ietf.org; Singh Ajoy-ASINGH1 Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 James, I see. Thanks a lot. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; ; "Singh Ajoy-ASINGH1" Sent: Sunday, April 21, 2002 2:43 AM Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > Could you tell us, if possible, how the IP address of the target > address is > > discovered in your experiment with the IS-2000 RAN? > > The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the > technical lead. I've cc'ed him on this response, perhaps he can describe > how the L2 triggers were implemented. > > > Also how can the mobile utilize the BSSid to find the FA or AR address > > without asking the current AR in 802.11? Don't we need something like > the > > CAR discovery protocol eventually? I assume the mobile does not > receive the > > Agent Advertisement messages of the target AR in the above question. > > Sure. But for experimental purposes, one can simply statically configure > the access routers or FAs with the mapping. > > 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 Apr 23 14:45: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 OAA01644 for ; Tue, 23 Apr 2002 14:45:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20646; Tue, 23 Apr 2002 14:24:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20618 for ; Tue, 23 Apr 2002 14:24:34 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00455 for ; Tue, 23 Apr 2002 14:24:30 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NINiB27543; Tue, 23 Apr 2002 13:23:44 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYXSP>; Tue, 23 Apr 2002 13:23:38 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E034DB901@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Charles E. Perkins" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 23 Apr 2002 13:23:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EAF3.FC6A4520" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1EAF3.FC6A4520 Content-Type: text/plain; charset="iso-8859-1" Very very well said - let's move on to the analysis and agreement of a standard from a set of candidate solutions to this problem space, please. > I heard Steve's presentation. I asked a question at the microphone > about whether he believed it precluded network-controlled operation. > He said it did not, but he wanted to restore mobile nodes to be > full citizens (paraphrasing, and it's been a few weeks now). > Subsequent discussion seems to be going to extremes, to the point > of ignoring obviously reasonable network-constrolled designs for > which [seamoby] ought to be responsive. > > The paper you cite does not preclude such operation. We can > view the mobile node as a client which is making use of available > service. If the network provides the service, it is free to > establish parameters by which it provides the service, and if > it is beneficial to have a mobile node move to another point of > attachment, I see nothing wrong with notifying the node about > that, along with a good candidate for an access router. I don't > see any reason why the network should be restricted from using > a CAR discovery protoocol to identify such a candidate. > > > Maybe the question is what business Seamoby has here? > > My answer would be that [seamoby] ought to be making protocols > by which we can expedite smooth handovers. That's a good piece > of work, and one for which we can exhibit existence proofs to > show that it is possible. I think that so far that there has > been trouble to get agreement on "general" goals, but that there > are particular instances where the intended results should be > obvious. I believe these particular instances include > network-controlled and mobile-controlled scenarios. > > =================================================================== > > Somewhere else, it was stated that only the mobile node can > possibly know all of the CARs. I would amend this to instead > say that the mobile node can always know about CARs that are > not visible to the network. But, as it turns out, the network > can always know CARs that are not visible to the mobile node > also. So, we have to allow the mobile node to make the choice, > but we should not prevent the mobile node from following > network-directives. Thus, we should develop a model by which > CAR discovery is allowed to provide input to a network-controlled > handover scheme, which is nonetheless subject to possible rejection > by the mobile node. > > Regards, > Charlie P. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1EAF3.FC6A4520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Minutes for Meeting at IETF 53

Very very well said - let's move on to the analysis = and agreement of a standard from a set of candidate solutions to this = problem space, please.

> I heard Steve's presentation.  I asked a = question at the microphone
> about whether he believed it precluded = network-controlled operation.
> He said it did not, but he wanted to restore = mobile nodes to be
> full citizens (paraphrasing, and it's been a = few weeks now).
> Subsequent discussion seems to be going to = extremes, to the point
> of ignoring obviously reasonable = network-constrolled designs for
> which [seamoby] ought to be responsive.
>
> The paper you cite does not preclude such = operation.  We can
> view the mobile node as a client which is = making use of available
> service.  If the network provides the = service, it is free to
> establish parameters by which it provides the = service, and if
> it is beneficial to have a mobile node move to = another point of
> attachment, I see nothing wrong with notifying = the node about
> that, along with a good candidate for an access = router.  I don't
> see any reason why the network should be = restricted from using
> a CAR discovery protoocol to identify such a = candidate.
>
> >   Maybe the question is what = business Seamoby has here?
>
> My answer would be that [seamoby] ought to be = making protocols
> by which we can expedite smooth = handovers.  That's a good piece
> of work, and one for which we can exhibit = existence proofs to
> show that it is possible.  I think that so = far that there has
> been trouble to get agreement on = "general" goals, but that there
> are particular instances where the intended = results should be
> obvious.  I believe these particular = instances include
> network-controlled and mobile-controlled = scenarios.
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Somewhere else, it was stated that only the = mobile node can
> possibly know all of the CARs.  I would = amend this to instead
> say that the mobile node can always know about = CARs that are
> not visible to the network.  But, as it = turns out, the network
> can always know CARs that are not visible to = the mobile node
> also.  So, we have to allow the mobile = node to make the choice,
> but we should not prevent the mobile node from = following
> network-directives.  Thus, we should = develop a model by which
> CAR discovery is allowed to provide input to a = network-controlled
> handover scheme, which is nonetheless subject = to possible rejection
> by the mobile node.
>
> Regards,
> Charlie P.
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1EAF3.FC6A4520-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Tue Apr 23 14:45: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 OAA01656 for ; Tue, 23 Apr 2002 14:45:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22140 for seamoby-archive@odin.ietf.org; Tue, 23 Apr 2002 14:45:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20646; Tue, 23 Apr 2002 14:24:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20618 for ; Tue, 23 Apr 2002 14:24:34 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00455 for ; Tue, 23 Apr 2002 14:24:30 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NINiB27543; Tue, 23 Apr 2002 13:23:44 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TYXSP>; Tue, 23 Apr 2002 13:23:38 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E034DB901@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Charles E. Perkins" Cc: seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Tue, 23 Apr 2002 13:23:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EAF3.FC6A4520" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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_01C1EAF3.FC6A4520 Content-Type: text/plain; charset="iso-8859-1" Very very well said - let's move on to the analysis and agreement of a standard from a set of candidate solutions to this problem space, please. > I heard Steve's presentation. I asked a question at the microphone > about whether he believed it precluded network-controlled operation. > He said it did not, but he wanted to restore mobile nodes to be > full citizens (paraphrasing, and it's been a few weeks now). > Subsequent discussion seems to be going to extremes, to the point > of ignoring obviously reasonable network-constrolled designs for > which [seamoby] ought to be responsive. > > The paper you cite does not preclude such operation. We can > view the mobile node as a client which is making use of available > service. If the network provides the service, it is free to > establish parameters by which it provides the service, and if > it is beneficial to have a mobile node move to another point of > attachment, I see nothing wrong with notifying the node about > that, along with a good candidate for an access router. I don't > see any reason why the network should be restricted from using > a CAR discovery protoocol to identify such a candidate. > > > Maybe the question is what business Seamoby has here? > > My answer would be that [seamoby] ought to be making protocols > by which we can expedite smooth handovers. That's a good piece > of work, and one for which we can exhibit existence proofs to > show that it is possible. I think that so far that there has > been trouble to get agreement on "general" goals, but that there > are particular instances where the intended results should be > obvious. I believe these particular instances include > network-controlled and mobile-controlled scenarios. > > =================================================================== > > Somewhere else, it was stated that only the mobile node can > possibly know all of the CARs. I would amend this to instead > say that the mobile node can always know about CARs that are > not visible to the network. But, as it turns out, the network > can always know CARs that are not visible to the mobile node > also. So, we have to allow the mobile node to make the choice, > but we should not prevent the mobile node from following > network-directives. Thus, we should develop a model by which > CAR discovery is allowed to provide input to a network-controlled > handover scheme, which is nonetheless subject to possible rejection > by the mobile node. > > Regards, > Charlie P. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1EAF3.FC6A4520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] Minutes for Meeting at IETF 53

Very very well said - let's move on to the analysis = and agreement of a standard from a set of candidate solutions to this = problem space, please.

> I heard Steve's presentation.  I asked a = question at the microphone
> about whether he believed it precluded = network-controlled operation.
> He said it did not, but he wanted to restore = mobile nodes to be
> full citizens (paraphrasing, and it's been a = few weeks now).
> Subsequent discussion seems to be going to = extremes, to the point
> of ignoring obviously reasonable = network-constrolled designs for
> which [seamoby] ought to be responsive.
>
> The paper you cite does not preclude such = operation.  We can
> view the mobile node as a client which is = making use of available
> service.  If the network provides the = service, it is free to
> establish parameters by which it provides the = service, and if
> it is beneficial to have a mobile node move to = another point of
> attachment, I see nothing wrong with notifying = the node about
> that, along with a good candidate for an access = router.  I don't
> see any reason why the network should be = restricted from using
> a CAR discovery protoocol to identify such a = candidate.
>
> >   Maybe the question is what = business Seamoby has here?
>
> My answer would be that [seamoby] ought to be = making protocols
> by which we can expedite smooth = handovers.  That's a good piece
> of work, and one for which we can exhibit = existence proofs to
> show that it is possible.  I think that so = far that there has
> been trouble to get agreement on = "general" goals, but that there
> are particular instances where the intended = results should be
> obvious.  I believe these particular = instances include
> network-controlled and mobile-controlled = scenarios.
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Somewhere else, it was stated that only the = mobile node can
> possibly know all of the CARs.  I would = amend this to instead
> say that the mobile node can always know about = CARs that are
> not visible to the network.  But, as it = turns out, the network
> can always know CARs that are not visible to = the mobile node
> also.  So, we have to allow the mobile = node to make the choice,
> but we should not prevent the mobile node from = following
> network-directives.  Thus, we should = develop a model by which
> CAR discovery is allowed to provide input to a = network-controlled
> handover scheme, which is nonetheless subject = to possible rejection
> by the mobile node.
>
> Regards,
> Charlie P.
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1EAF3.FC6A4520-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Apr 24 22: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 WAA14534 for ; Wed, 24 Apr 2002 22:21:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16801; Wed, 24 Apr 2002 22:03:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16771 for ; Wed, 24 Apr 2002 22:03:00 -0400 (EDT) Received: from freightmart.com (116-154-239-64.pajo.com [64.239.154.116] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14359 for ; Wed, 24 Apr 2002 22:02:56 -0400 (EDT) From: lisa@freightmart.com Message-Id: <200204250202.WAA14359@ietf.org> Content-Type: text/html; charset=US-ASCII Date: Wed, 24 Apr 2002 19:07:20 -0700 To: seamoby@ietf.org X-Mailer: Version 5.0 Subject: [Seamoby] An Invitation from Lisa@freightmart.com Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org FREIGHTMART Mail Campaign


To be REMOVED from any future offers, simply CLICK HERE!
For more info, CLICK HERE!
Team FREIGHTMART
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@ns.ietf.org Wed Apr 24 22:21: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 WAA14549 for ; Wed, 24 Apr 2002 22:21:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17429 for seamoby-archive@odin.ietf.org; Wed, 24 Apr 2002 22:21:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16801; Wed, 24 Apr 2002 22:03:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16771 for ; Wed, 24 Apr 2002 22:03:00 -0400 (EDT) Received: from freightmart.com (116-154-239-64.pajo.com [64.239.154.116] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14359 for ; Wed, 24 Apr 2002 22:02:56 -0400 (EDT) From: lisa@freightmart.com Message-Id: <200204250202.WAA14359@ietf.org> Content-Type: text/html; charset=US-ASCII Date: Wed, 24 Apr 2002 19:07:20 -0700 To: seamoby@ietf.org X-Mailer: Version 5.0 Subject: [Seamoby] An Invitation from Lisa@freightmart.com Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org FREIGHTMART Mail Campaign


To be REMOVED from any future offers, simply CLICK HERE!
For more info, CLICK HERE!
Team FREIGHTMART
_______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Apr 25 00:36: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 AAA17861 for ; Thu, 25 Apr 2002 00:36:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22874; Thu, 25 Apr 2002 00:17:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22847 for ; Thu, 25 Apr 2002 00:17:50 -0400 (EDT) Received: from hotmail.com (oe73.law4.hotmail.com [216.33.148.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17622 for ; Thu, 25 Apr 2002 00:17:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Apr 2002 21:17:16 -0700 X-Originating-IP: [66.122.105.22] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "James Kempf" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 24 Apr 2002 21:22:17 -0700 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 Apr 2002 04:17:16.0983 (UTC) FILETIME=[15A4AC70:01C1EC10] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Ajoy. That's helpful. Eunsoo ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'Eunsoo Shim'" ; "James Kempf" ; Sent: Sunday, April 21, 2002 1:10 PM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > Eunsoo/James, > > We implemented both source as well as target trigger scenarios > of Low latency handoff draft. In case of source trigger, the > Pre-trigger indication at source FA provides the BTS id of the > target BTS to which MN is moving to. The L2 trigger > handler at the oFA resolves BTS-ID to obtain the IP address > of the nFA. We used static table to resolve IP address from the > given BTS-ID. Similarly, in case of target trigger, the > Pre-trigger indication at nFA provides the BTS-ID of > the source BTS from which the MN is moving from. The L2 trigger > handler at nFA resolves source BTS-ID to obtain the IP address > of the source FA. Pre-trigger indication is sent from > radio network controller to foreign agent as soon > as link layer handoff is detected based upon power > measurement. Hope this helps. > > regards, > ajoy > > > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@hotmail.com] > Sent: Sunday, April 21, 2002 9:29 PM > To: James Kempf; seamoby@ietf.org; Singh Ajoy-ASINGH1 > Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > James, > > I see. Thanks a lot. > > Eunsoo > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; ; "Singh > Ajoy-ASINGH1" > Sent: Sunday, April 21, 2002 2:43 AM > Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > Could you tell us, if possible, how the IP address of the target > > address is > > > discovered in your experiment with the IS-2000 RAN? > > > > The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the > > technical lead. I've cc'ed him on this response, perhaps he can describe > > how the L2 triggers were implemented. > > > > > Also how can the mobile utilize the BSSid to find the FA or AR address > > > without asking the current AR in 802.11? Don't we need something like > > the > > > CAR discovery protocol eventually? I assume the mobile does not > > receive the > > > Agent Advertisement messages of the target AR in the above question. > > > > Sure. But for experimental purposes, one can simply statically configure > > the access routers or FAs with the mapping. > > > > 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 Apr 25 00:36: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 AAA17872 for ; Thu, 25 Apr 2002 00:36:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA24021 for seamoby-archive@odin.ietf.org; Thu, 25 Apr 2002 00:36:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22874; Thu, 25 Apr 2002 00:17:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22847 for ; Thu, 25 Apr 2002 00:17:50 -0400 (EDT) Received: from hotmail.com (oe73.law4.hotmail.com [216.33.148.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17622 for ; Thu, 25 Apr 2002 00:17:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Apr 2002 21:17:16 -0700 X-Originating-IP: [66.122.105.22] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "Singh Ajoy-ASINGH1" , "James Kempf" , References: Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Date: Wed, 24 Apr 2002 21:22:17 -0700 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 Apr 2002 04:17:16.0983 (UTC) FILETIME=[15A4AC70:01C1EC10] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.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, Ajoy. That's helpful. Eunsoo ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'Eunsoo Shim'" ; "James Kempf" ; Sent: Sunday, April 21, 2002 1:10 PM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > Eunsoo/James, > > We implemented both source as well as target trigger scenarios > of Low latency handoff draft. In case of source trigger, the > Pre-trigger indication at source FA provides the BTS id of the > target BTS to which MN is moving to. The L2 trigger > handler at the oFA resolves BTS-ID to obtain the IP address > of the nFA. We used static table to resolve IP address from the > given BTS-ID. Similarly, in case of target trigger, the > Pre-trigger indication at nFA provides the BTS-ID of > the source BTS from which the MN is moving from. The L2 trigger > handler at nFA resolves source BTS-ID to obtain the IP address > of the source FA. Pre-trigger indication is sent from > radio network controller to foreign agent as soon > as link layer handoff is detected based upon power > measurement. Hope this helps. > > regards, > ajoy > > > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@hotmail.com] > Sent: Sunday, April 21, 2002 9:29 PM > To: James Kempf; seamoby@ietf.org; Singh Ajoy-ASINGH1 > Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > James, > > I see. Thanks a lot. > > Eunsoo > ----- Original Message ----- > From: "James Kempf" > To: "Eunsoo Shim" ; ; "Singh > Ajoy-ASINGH1" > Sent: Sunday, April 21, 2002 2:43 AM > Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 > > > > > Could you tell us, if possible, how the IP address of the target > > address is > > > discovered in your experiment with the IS-2000 RAN? > > > > The work on the IS-2000 RAN was done by Motorola, Ajoy Singh was the > > technical lead. I've cc'ed him on this response, perhaps he can describe > > how the L2 triggers were implemented. > > > > > Also how can the mobile utilize the BSSid to find the FA or AR address > > > without asking the current AR in 802.11? Don't we need something like > > the > > > CAR discovery protocol eventually? I assume the mobile does not > > receive the > > > Agent Advertisement messages of the target AR in the above question. > > > > Sure. But for experimental purposes, one can simply statically configure > > the access routers or FAs with the mapping. > > > > 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 Apr 25 12:33: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 MAA26565 for ; Thu, 25 Apr 2002 12:33:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20181; Thu, 25 Apr 2002 12:29:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20151 for ; Thu, 25 Apr 2002 12:29:44 -0400 (EDT) Received: from proxy.jamsil.hs.kr ([211.248.110.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26438 for ; Thu, 25 Apr 2002 12:29:38 -0400 (EDT) Received: from test ([202.103.67.44]) by proxy.jamsil.hs.kr (8.11.6/8.11.6) with SMTP id g3PGgBn22928 for ; Fri, 26 Apr 2002 01:42:14 +0900 Message-Id: <200204251642.g3PGgBn22928@proxy.jamsil.hs.kr> Reply-To: office_management@desertmail.com From: andrew261386@messpro.com To: seamoby@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 25 Apr 2002 09:32:29 -0700 Subject: [Seamoby] ===Medical Breakthrough...Aging can be reversed=== 2613865433222 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 HGH (Human Growth Hormone) products are not the same. There are three different types of products. Yet, all three are advertised as if they where the same. The three types are: 1) Homeopathic HGH 2) Pre-cursor HGH 3) Real or synthetic HGH (delivered by injection or, by an oral spray method). Do you know differences? Call us and we'll explain them to you. Our toll free number is 888-621-7300. For more information on HGH read on............ ***************************************************************************** HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us now. TOLL FREE 1-888-621-7300 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-621-7300 If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: "The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging." Dr. Daniel Rudman, MD, New England Journal of Medicine. "Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly." D.W., New Jersey "We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying!" C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Offer expires 19 April 2002 Call us now 1-888-621-7300 *********************************************************** ======= End of message ======== To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *********************************************************** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and type remvoe in the subject box. Then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *********************************************************** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA & WA. Screening of addresses has been done to the best of our technical ability. *********************************************************** Call us now 1-888-621-7300 for your free HGH consultation. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Thu Apr 25 12:33: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 MAA26576 for ; Thu, 25 Apr 2002 12:33:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20818 for seamoby-archive@odin.ietf.org; Thu, 25 Apr 2002 12:33:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20181; Thu, 25 Apr 2002 12:29:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20151 for ; Thu, 25 Apr 2002 12:29:44 -0400 (EDT) Received: from proxy.jamsil.hs.kr ([211.248.110.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26438 for ; Thu, 25 Apr 2002 12:29:38 -0400 (EDT) Received: from test ([202.103.67.44]) by proxy.jamsil.hs.kr (8.11.6/8.11.6) with SMTP id g3PGgBn22928 for ; Fri, 26 Apr 2002 01:42:14 +0900 Message-Id: <200204251642.g3PGgBn22928@proxy.jamsil.hs.kr> Reply-To: office_management@desertmail.com From: andrew261386@messpro.com To: seamoby@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 25 Apr 2002 09:32:29 -0700 Subject: [Seamoby] ===Medical Breakthrough...Aging can be reversed=== 2613865433222 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org 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 HGH (Human Growth Hormone) products are not the same. There are three different types of products. Yet, all three are advertised as if they where the same. The three types are: 1) Homeopathic HGH 2) Pre-cursor HGH 3) Real or synthetic HGH (delivered by injection or, by an oral spray method). Do you know differences? Call us and we'll explain them to you. Our toll free number is 888-621-7300. For more information on HGH read on............ ***************************************************************************** HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us now. TOLL FREE 1-888-621-7300 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-621-7300 If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: "The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging." Dr. Daniel Rudman, MD, New England Journal of Medicine. "Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly." D.W., New Jersey "We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying!" C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Offer expires 19 April 2002 Call us now 1-888-621-7300 *********************************************************** ======= End of message ======== To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *********************************************************** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and type remvoe in the subject box. Then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *********************************************************** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA & WA. Screening of addresses has been done to the best of our technical ability. *********************************************************** Call us now 1-888-621-7300 for your free HGH consultation. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 26 10:53: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 KAA06530 for ; Fri, 26 Apr 2002 10:53:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15961; Fri, 26 Apr 2002 10:31:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15916 for ; Fri, 26 Apr 2002 10:31:37 -0400 (EDT) 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 KAA05853 for ; Fri, 26 Apr 2002 10:31:33 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3QEV5P01490 for ; Fri, 26 Apr 2002 09:31:05 -0500 (CDT) Message-ID: <3CC964C0.5000704@alcatel.com> Date: Fri, 26 Apr 2002 09:31:28 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: 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 Hello Ajoy, Do you mean to say that BTS is where Mobile IP handover occurs, i.e. BTS of 1xRTT was where FA was placed in your experiment? If yes then how do you reconcile this with the standard architecture? Can you please provide more details so that we can better understand what you did? Regards, Singh Ajoy-ASINGH1 wrote: >Eunsoo/James, > >We implemented both source as well as target trigger scenarios >of Low latency handoff draft. In case of source trigger, the >Pre-trigger indication at source FA provides the BTS id of the >target BTS to which MN is moving to. The L2 trigger >handler at the oFA resolves BTS-ID to obtain the IP address >of the nFA. We used static table to resolve IP address from the >given BTS-ID. Similarly, in case of target trigger, the >Pre-trigger indication at nFA provides the BTS-ID of >the source BTS from which the MN is moving from. The L2 trigger >handler at nFA resolves source BTS-ID to obtain the IP address >of the source FA. Pre-trigger indication is sent from >radio network controller to foreign agent as soon >as link layer handoff is detected based upon power >measurement. Hope this helps. > >regards, >ajoy > --behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Apr 26 11:38: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 LAA08099 for ; Fri, 26 Apr 2002 11:38:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19139; Fri, 26 Apr 2002 11:13:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19110 for ; Fri, 26 Apr 2002 11:13:03 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07260 for ; Fri, 26 Apr 2002 11:12:59 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA10256 for ; Fri, 26 Apr 2002 08:13:02 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA12788 for ; Fri, 26 Apr 2002 08:13:02 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 26 Apr 2002 10:13:01 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Behcet Sarikaya'" , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 26 Apr 2002 10:12:57 -0500 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 Bachet, I did not mean that Mobile/IP handover occurs at BTS. But some inter-BTS handover causes Mobile/IP handover. Suppose you have BTS 1 to 5 mapped to FA1 and BTS 5 to 10 mapped to FA2. When L2 trigger indicates that MN is moving from BTS 1 to BTS 5, the trigger handler knows that it has to initiate Mobile/IP handover. Similarly, when trigger indicates that MN is moving from BTS 1 to BTS 2, the trigger handler knows that there is no need to initiate Mobile/IP handover. Hope this helps. regards, ajoy -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, April 26, 2002 9:31 AM To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Hello Ajoy, Do you mean to say that BTS is where Mobile IP handover occurs, i.e. BTS of 1xRTT was where FA was placed in your experiment? If yes then how do you reconcile this with the standard architecture? Can you please provide more details so that we can better understand what you did? Regards, Singh Ajoy-ASINGH1 wrote: >Eunsoo/James, > >We implemented both source as well as target trigger scenarios >of Low latency handoff draft. In case of source trigger, the >Pre-trigger indication at source FA provides the BTS id of the >target BTS to which MN is moving to. The L2 trigger >handler at the oFA resolves BTS-ID to obtain the IP address >of the nFA. We used static table to resolve IP address from the >given BTS-ID. Similarly, in case of target trigger, the >Pre-trigger indication at nFA provides the BTS-ID of >the source BTS from which the MN is moving from. The L2 trigger >handler at nFA resolves source BTS-ID to obtain the IP address >of the source FA. Pre-trigger indication is sent from >radio network controller to foreign agent as soon >as link layer handoff is detected based upon power >measurement. Hope this helps. > >regards, >ajoy > --behcet _______________________________________________ Seamoby mailing 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 Apr 26 11: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 LAA08109 for ; Fri, 26 Apr 2002 11:38:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20666 for seamoby-archive@odin.ietf.org; Fri, 26 Apr 2002 11:38:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19139; Fri, 26 Apr 2002 11:13:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19110 for ; Fri, 26 Apr 2002 11:13:03 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07260 for ; Fri, 26 Apr 2002 11:12:59 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA10256 for ; Fri, 26 Apr 2002 08:13:02 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA12788 for ; Fri, 26 Apr 2002 08:13:02 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 26 Apr 2002 10:13:01 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Behcet Sarikaya'" , seamoby@ietf.org Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 Date: Fri, 26 Apr 2002 10:12:57 -0500 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 Bachet, I did not mean that Mobile/IP handover occurs at BTS. But some inter-BTS handover causes Mobile/IP handover. Suppose you have BTS 1 to 5 mapped to FA1 and BTS 5 to 10 mapped to FA2. When L2 trigger indicates that MN is moving from BTS 1 to BTS 5, the trigger handler knows that it has to initiate Mobile/IP handover. Similarly, when trigger indicates that MN is moving from BTS 1 to BTS 2, the trigger handler knows that there is no need to initiate Mobile/IP handover. Hope this helps. regards, ajoy -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, April 26, 2002 9:31 AM To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 Hello Ajoy, Do you mean to say that BTS is where Mobile IP handover occurs, i.e. BTS of 1xRTT was where FA was placed in your experiment? If yes then how do you reconcile this with the standard architecture? Can you please provide more details so that we can better understand what you did? Regards, Singh Ajoy-ASINGH1 wrote: >Eunsoo/James, > >We implemented both source as well as target trigger scenarios >of Low latency handoff draft. In case of source trigger, the >Pre-trigger indication at source FA provides the BTS id of the >target BTS to which MN is moving to. The L2 trigger >handler at the oFA resolves BTS-ID to obtain the IP address >of the nFA. We used static table to resolve IP address from the >given BTS-ID. Similarly, in case of target trigger, the >Pre-trigger indication at nFA provides the BTS-ID of >the source BTS from which the MN is moving from. The L2 trigger >handler at nFA resolves source BTS-ID to obtain the IP address >of the source FA. Pre-trigger indication is sent from >radio network controller to foreign agent as soon >as link layer handoff is detected based upon power >measurement. Hope this helps. > >regards, >ajoy > --behcet _______________________________________________ Seamoby mailing 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 Apr 26 11:41: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 KAA06543 for ; Fri, 26 Apr 2002 10:53:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17817 for seamoby-archive@odin.ietf.org; Fri, 26 Apr 2002 10:53:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15961; Fri, 26 Apr 2002 10:31:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15916 for ; Fri, 26 Apr 2002 10:31:37 -0400 (EDT) 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 KAA05853 for ; Fri, 26 Apr 2002 10:31:33 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3QEV5P01490 for ; Fri, 26 Apr 2002 09:31:05 -0500 (CDT) Message-ID: <3CC964C0.5000704@alcatel.com> Date: Fri, 26 Apr 2002 09:31:28 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: seamoby@ietf.org Subject: Re: [Seamoby] Minutes for Meeting at IETF 53 References: 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 Hello Ajoy, Do you mean to say that BTS is where Mobile IP handover occurs, i.e. BTS of 1xRTT was where FA was placed in your experiment? If yes then how do you reconcile this with the standard architecture? Can you please provide more details so that we can better understand what you did? Regards, Singh Ajoy-ASINGH1 wrote: >Eunsoo/James, > >We implemented both source as well as target trigger scenarios >of Low latency handoff draft. In case of source trigger, the >Pre-trigger indication at source FA provides the BTS id of the >target BTS to which MN is moving to. The L2 trigger >handler at the oFA resolves BTS-ID to obtain the IP address >of the nFA. We used static table to resolve IP address from the >given BTS-ID. Similarly, in case of target trigger, the >Pre-trigger indication at nFA provides the BTS-ID of >the source BTS from which the MN is moving from. The L2 trigger >handler at nFA resolves source BTS-ID to obtain the IP address >of the source FA. Pre-trigger indication is sent from >radio network controller to foreign agent as soon >as link layer handoff is detected based upon power >measurement. Hope this helps. > >regards, >ajoy > --behcet _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Apr 30 00: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 AAA29951 for ; Tue, 30 Apr 2002 00:54:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18352; Tue, 30 Apr 2002 00:45:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18322 for ; Tue, 30 Apr 2002 00:45:02 -0400 (EDT) Received: from smtp.cs.nthu.edu.tw (smtp.cs.nthu.edu.tw [140.114.87.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29823 for ; Tue, 30 Apr 2002 00:44:48 -0400 (EDT) Received: from scarab (scarab.cs.nthu.edu.tw [140.114.79.99]) by smtp.cs.nthu.edu.tw (8.9.3/8.9.3) with SMTP id MAA00766; Tue, 30 Apr 2002 12:44:42 +0800 (CST) Message-ID: <003401c1f001$bcea4db0$634f728c@cs.nthu.edu.tw> From: "mrbig" To: , References: <01cc01c1edbd$df020d20$dd0d48d2@peter> Date: Tue, 30 Apr 2002 12:44:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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] CFP Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit CALL FOR PAPERS The Third IEEE Pacific-Rim Conference on Multimedia Special Session on "Wireless Multimedia Networks" National Tsing Hua University, Hsinchu, Taiwan December 16 -- 18, 2002 Theme of Special Session ------------------------ As technologies evolve, high-speed transmission now is possible for both indoor and outdoor wireless systems. It is envisioned that novel services and applications such as graphic email, multimedia web browsing, video conferencing, etc. will become prevalent in our daily life anytime and anywhere. This session, as a constituent of PCM 2002, serves as a forum for academic and industrial researchers and practitioners to discuss the technologies of wireless multimedia systems. The organizer seeks contributions of high quality papers addressing various aspects of state-of-art research in wireless multimedia systems and networks for presentation at the conference and publication in the proceedings. We solicit papers covering a variety of topics including, but not limited to: o Systems and Architecture o Access Protocols o Resource Management o Mobility Management o Power Control and Management o QoS Provisioning o Security o Mobile Computing o Mobile VoIP o Video over wireless Internet o Network Performance Analysis o Internetworking o System Integration Paper Submissions ----------------- Papers must be written in English. Please prepare your paper according to the guideline of PCM 2002. All accepted papers will be published in the PCM 2002 proceedings. Send your paper for the special session to: Professor Jyh-Cheng Chen Department of Computer Science, and Institute of Communications Engineering National Tsing Hua University 101, Sec.2, Kuang Fu Rd. Hsinchu, Taiwan 300, R.O.C. e-mail: jcchen@cs.nthu.edu.tw fax: + 886 3 572 3694 phone: + 886 3 574 2961 Important Dates --------------- Paper submission due: May 30, 2002 Notification of Acceptance: July 15, 2002 Camera-ready version due: Aug. 15, 2002 FOR MORE INFORMATION: --------------------- Please visit the conference web site at http://www.ee.nthu.edu.tw/~PCM2002/ or send email to PCM2002@ee.nthu.edu.tw for any questions or for more information about the conference. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From daemon@optimus.ietf.org Tue Apr 30 00: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 AAA29963 for ; Tue, 30 Apr 2002 00:54:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA18704 for seamoby-archive@odin.ietf.org; Tue, 30 Apr 2002 00:54:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18352; Tue, 30 Apr 2002 00:45:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18322 for ; Tue, 30 Apr 2002 00:45:02 -0400 (EDT) Received: from smtp.cs.nthu.edu.tw (smtp.cs.nthu.edu.tw [140.114.87.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29823 for ; Tue, 30 Apr 2002 00:44:48 -0400 (EDT) Received: from scarab (scarab.cs.nthu.edu.tw [140.114.79.99]) by smtp.cs.nthu.edu.tw (8.9.3/8.9.3) with SMTP id MAA00766; Tue, 30 Apr 2002 12:44:42 +0800 (CST) Message-ID: <003401c1f001$bcea4db0$634f728c@cs.nthu.edu.tw> From: "mrbig" To: , References: <01cc01c1edbd$df020d20$dd0d48d2@peter> Date: Tue, 30 Apr 2002 12:44:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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] CFP Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org Content-Transfer-Encoding: 7bit CALL FOR PAPERS The Third IEEE Pacific-Rim Conference on Multimedia Special Session on "Wireless Multimedia Networks" National Tsing Hua University, Hsinchu, Taiwan December 16 -- 18, 2002 Theme of Special Session ------------------------ As technologies evolve, high-speed transmission now is possible for both indoor and outdoor wireless systems. It is envisioned that novel services and applications such as graphic email, multimedia web browsing, video conferencing, etc. will become prevalent in our daily life anytime and anywhere. This session, as a constituent of PCM 2002, serves as a forum for academic and industrial researchers and practitioners to discuss the technologies of wireless multimedia systems. The organizer seeks contributions of high quality papers addressing various aspects of state-of-art research in wireless multimedia systems and networks for presentation at the conference and publication in the proceedings. We solicit papers covering a variety of topics including, but not limited to: o Systems and Architecture o Access Protocols o Resource Management o Mobility Management o Power Control and Management o QoS Provisioning o Security o Mobile Computing o Mobile VoIP o Video over wireless Internet o Network Performance Analysis o Internetworking o System Integration Paper Submissions ----------------- Papers must be written in English. Please prepare your paper according to the guideline of PCM 2002. All accepted papers will be published in the PCM 2002 proceedings. Send your paper for the special session to: Professor Jyh-Cheng Chen Department of Computer Science, and Institute of Communications Engineering National Tsing Hua University 101, Sec.2, Kuang Fu Rd. Hsinchu, Taiwan 300, R.O.C. e-mail: jcchen@cs.nthu.edu.tw fax: + 886 3 572 3694 phone: + 886 3 574 2961 Important Dates --------------- Paper submission due: May 30, 2002 Notification of Acceptance: July 15, 2002 Camera-ready version due: Aug. 15, 2002 FOR MORE INFORMATION: --------------------- Please visit the conference web site at http://www.ee.nthu.edu.tw/~PCM2002/ or send email to PCM2002@ee.nthu.edu.tw for any questions or for more information about the conference. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby